Timeline for getopt, getopts or manual parsing - what to use when I want to support both short and long options?
Current License: CC BY-SA 4.0
20 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| S Jan 13, 2024 at 6:01 | history | suggested | qqqq | CC BY-SA 4.0 | Added missing word and removed a few other words |
| Jan 13, 2024 at 3:10 | review | Suggested edits | |||
| S Jan 13, 2024 at 6:01 | |||||
| Mar 8, 2023 at 20:57 | comment | added | ilkkachu | @leo, no, the "non-traditional", or "extended" getopt's (util-linux and Busybox, as far as I've found) support a mode where they produce shell-quoted output, which can and has to be read in with eval. But you also have to use them right, and test beforehand (with getopt -T) that you have one of those versions, because the "traditional" ones may run with the same syntax, but do things differently... Compare the output of e.g. getopt a: -- -a "foo bar" (trad.) and getopt -o a: -- -a "foo bar" (better) with different versions of getopt. | |
| Mar 8, 2023 at 20:50 | history | edited | ilkkachu | CC BY-SA 4.0 | Be a bit more realistic about which version of getopt works. Also it has nothing to do with Bash. |
| Jan 26, 2023 at 13:08 | comment | added | leo | Coming from a place of ignorance here, but that's also why I ask. The eval when setting the positional parameters, can that be exploited to inject code? | |
| Aug 21, 2018 at 20:40 | history | edited | l0b0 | CC BY-SA 4.0 | added 3 characters in body |
| Aug 21, 2018 at 16:51 | comment | added | mtalexan | OP's link that claims "Traditional versions of getopt cannot handle empty argument strings, or arguments with embedded whitespace." and that the util-linux version of getopt shouldn't be used has no evidence and is no longer accurate. A quick survey (5+ years later) shows that the default version of getopt available from ArchLinux, SUSE, Ubuntu, RedHat, Fedora, and CentOS (as well as most derivative variants) all support optional arguments and arguments with whitespace. | |
| May 18, 2017 at 15:15 | comment | added | n.caillou | Just to add to this discussion: this is not the traditional getopt. It is the linux-utils flavor as indicated by @StéphaneChazelas. It has legacy options that will disable the syntax described above, in particular the manpage states "GETOPT_COMPATIBLE forces getopt to use the first calling format as specified in the SYNOPSIS". However if you can expect target systems to have this package installed this is totally the way to go, as the original getopt is awful and Bash's getopt is very limited | |
| Oct 31, 2016 at 14:17 | comment | added | Alexej Magura | You specified b as having a required option. Two colons (e.g. ::) specify an optional argument. | |
| Jan 29, 2013 at 14:05 | comment | added | l0b0 | let us continue this discussion in chat | |
| Jan 29, 2013 at 13:08 | comment | added | Stéphane Chazelas | getopt is a traditional command that comes from System V long before Linux was ever released. getopt was never standardised. None of POSIX, Unix, or Linux (LSB) ever standardized the getopt command. getopts is specified in all three but without support for long options. | |
| Jan 29, 2013 at 12:57 | comment | added | l0b0 | @StephaneChazelas The original argument still stands: OP wouldn't be asking about pros and cons of a feature unless that feature is supported on the relevant platforms. It seems obvious that the choice is between a getopt which supports -l, getopts or something completely different. | |
| Jan 29, 2013 at 12:56 | comment | added | l0b0 | @StephaneChazelas Also, I thought it was clear that getopt is not part of Bash since it's got a separate man page. | |
| Jan 29, 2013 at 12:55 | comment | added | Stéphane Chazelas | Most platforms have getopt, only Linux AFAIK comes with one that supports long options or blanks in arguments. The other ones would only support the System V syntax. | |
| Jan 29, 2013 at 12:53 | comment | added | l0b0 | I don't think the OP would be asking this if getopt was not available. | |
| Jan 29, 2013 at 12:52 | history | edited | l0b0 | CC BY-SA 3.0 | added 330 characters in body |
| Jan 29, 2013 at 12:45 | comment | added | Stéphane Chazelas | The OP mentioned the need to be portable to many Unix platforms while the getopt you're quoting here is Linux-specific. Note that getopt is not part of bash, it's not even a GNU utility and on Linux is shipped with the util-linux package. | |
| Jan 29, 2013 at 12:44 | history | edited | l0b0 | CC BY-SA 3.0 | added 330 characters in body |
| Jan 29, 2013 at 12:38 | history | edited | l0b0 | CC BY-SA 3.0 | added 330 characters in body |
| Jan 29, 2013 at 12:25 | history | answered | l0b0 | CC BY-SA 3.0 |