6 ms·

Argbash: Bash argument parsing code generator

59 points by ducktective 5y ago

smbv 5y ago
Is this project still maintained?
- pajamanaut 5y ago
  The maintainer has not had any activity on this project in over a year, but it looks like he account is still active
0xbadcafebee 5y ago
If you really really want long options, it's not that hard to just write your own argument parsing function. Certainly it would save you a couple thousand lines of complexity over this. (personally I just use getopts) #!/usr/bin/env sh while [ $# -gt 0 ] ; do x="$1"; shift case "$x" in -v|--verbose) echo "verbose mode" ;; -o|--output) OUTFILE="$1" ; shift ; echo "Output file is '$OUTFILE'" ;; esac done $ ./foo here is -v an option --output foo.txt command here verbose mode Output file is 'foo.txt'
- egberts1 5y ago
  Don’t forget the end option notation `-—`. As in: --) break ;; :-D
- faho 5y ago
  Okay, now do grouped short options - `yourscript -vo /path/to/file`. Note that getopt(3) (what CLI tools written in e.g. C would use) allows this - `grep -qf /path/to/file` works the same as `grep --quiet --file /path/to/file`. Come to think of that, you also don't allow `--output=/path/to/file` with the "=". Argument parsing is one of those things where doing an approximation is easy, doing it correctly is hard.
  - 0xbadcafebee 5y ago
    Agreed! That's why I just use getopts :) Long options are nice but I never seem to need them.
  - ramses0 5y ago
    IMHO, we've reached the point where shortopts for "non-superstar" commands are considered harmful (especially when the command args are used in scripting). Basically, of course, all your posix commands should keep shortopts and keep the "smush together shortopts", but 99.999% of simple scripts and commands that you as a person / developer write should be 100% longopts (and long-opts only!). Bash is a near-dead/dying language in the sense that OSX is pushing zsh, and there are some fundamental flaws in bash that are difficult to consistently work around (eg: see bash-pitfalls and shellcheck). CLI usage is trending towards more "bundle and standardize" (ie: make, npm run, Dockerfile, etc...) and for those purpose I _really_ prefer committing explicit long-opts instead of shortopts (eg: `rm --interactive --recursive --force` v. `rm -irf`), as it's moderately self-documenting and harder to make preventable mistakes. For your whatever internal scripts that parse options, I guarantee you it's better that you explicitly call out `foo.sh --force || foo.sh --file` instead of `foo.sh -f` after you've left it and are coming back to it a year from now. For "superstar" commands like "docker run -i -t ..." then let there be 100k's of users before you start cluttering with shortopts, and only then add them judiciously for truly time-saving interactive uses.
    - tsujp 5y ago
      Apple swapped to zsh as the default shell because Bash moved to GPLv3 from GPLv2.
    - twofornone 5y ago
      >Bash is a near-dead/dying language in the sense that OSX is pushing zsh, and there are some fundamental flaws in bash that are difficult to consistently work around (eg: see bash-pitfalls and shellcheck). Recently tried my hand at some bash on osx and was frustrated to find that the osx version of getopt does not support long options, so it looks like there's no portable way to conveniently handle long options on osx, and forcing users to install GNU getopt kind of defeats the purpose of bash (portability)? I guess I don't know the standard, is it reasonable to bundle in a dependency download with a simple bash script (e.g. download the correct version of getopt before parsing args)? I imagine not. How does one properly support long and short options in bash on osx without rolling your own parser?
- mbrock 5y ago
  If you're okay with depending on Git, you can use `git rev-parse --parseopt`. https://git-scm.com/docs/git-rev-parse#_parseopt https://git-scm.com/docs/git-rev-parse#_parseopt > In --parseopt mode, git rev-parse helps massaging options to bring to shell scripts the same facilities C builtins have. It works as an option normalizer (e.g. splits single switches aggregate values), a bit like getopt(1) does. > It takes on the standard input the specification of the options to parse and understand, and echoes on the standard output a string suitable for sh(1) eval to replace the arguments with normalized ones. In case of error, it outputs usage on the standard error stream, and exits with code 129.
  - unixhero 5y ago
    This is really brilliant and I have never heard of this method before. Noting it down thank you.
chasil 5y ago
Why would getopts be discouraged? Where does the POSIX standard say that getopts is discouraged? https://pubs.opengroup.org/onlinepubs/9699919799/utilities/getopts.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/g... https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
- 0xbadcafebee 5y ago
  getopt is discouraged, not getopts
eterps 5y ago
Some thoughts how future shells might tackle this: https://github.com/oilshell/oil/issues/469 https://github.com/oilshell/oil/issues/469
kps 5y ago
ksh's declarative getopts is easy to use and automatically provides help messages, and is one major reason I use it for day-to-day scripts. It's too bad bash didn't embrace and extend that before they extinguished it.
q3k 5y ago
Or, even better: don't use shell scripts to express the kind of complex logic which requires parsing arguments in multiple forms/modes.

59 points by ducktective 5y ago

smbv 5y ago

Is this project still maintained?

pajamanaut 5y ago
The maintainer has not had any activity on this project in over a year, but it looks like he account is still active

0xbadcafebee 5y ago

If you really really want long options, it's not that hard to just write your own argument parsing function. Certainly it would save you a couple thousand lines of complexity over this. (personally I just use getopts) #!/usr/bin/env sh while [ $# -gt 0 ] ; do x="$1"; shift case "$x" in -v|--verbose) echo "verbose mode" ;; -o|--output) OUTFILE="$1" ; shift ; echo "Output file is '$OUTFILE'" ;; esac done $ ./foo here is -v an option --output foo.txt command here verbose mode Output file is 'foo.txt'

egberts1 5y ago
Don’t forget the end option notation `-—`. As in: --) break ;; :-D
faho 5y ago
Okay, now do grouped short options - `yourscript -vo /path/to/file`. Note that getopt(3) (what CLI tools written in e.g. C would use) allows this - `grep -qf /path/to/file` works the same as `grep --quiet --file /path/to/file`. Come to think of that, you also don't allow `--output=/path/to/file` with the "=". Argument parsing is one of those things where doing an approximation is easy, doing it correctly is hard.
- 0xbadcafebee 5y ago
  Agreed! That's why I just use getopts :) Long options are nice but I never seem to need them.
- ramses0 5y ago
  IMHO, we've reached the point where shortopts for "non-superstar" commands are considered harmful (especially when the command args are used in scripting). Basically, of course, all your posix commands should keep shortopts and keep the "smush together shortopts", but 99.999% of simple scripts and commands that you as a person / developer write should be 100% longopts (and long-opts only!). Bash is a near-dead/dying language in the sense that OSX is pushing zsh, and there are some fundamental flaws in bash that are difficult to consistently work around (eg: see bash-pitfalls and shellcheck). CLI usage is trending towards more "bundle and standardize" (ie: make, npm run, Dockerfile, etc...) and for those purpose I _really_ prefer committing explicit long-opts instead of shortopts (eg: `rm --interactive --recursive --force` v. `rm -irf`), as it's moderately self-documenting and harder to make preventable mistakes. For your whatever internal scripts that parse options, I guarantee you it's better that you explicitly call out `foo.sh --force || foo.sh --file` instead of `foo.sh -f` after you've left it and are coming back to it a year from now. For "superstar" commands like "docker run -i -t ..." then let there be 100k's of users before you start cluttering with shortopts, and only then add them judiciously for truly time-saving interactive uses.
  - tsujp 5y ago
    Apple swapped to zsh as the default shell because Bash moved to GPLv3 from GPLv2.
  - twofornone 5y ago
    >Bash is a near-dead/dying language in the sense that OSX is pushing zsh, and there are some fundamental flaws in bash that are difficult to consistently work around (eg: see bash-pitfalls and shellcheck). Recently tried my hand at some bash on osx and was frustrated to find that the osx version of getopt does not support long options, so it looks like there's no portable way to conveniently handle long options on osx, and forcing users to install GNU getopt kind of defeats the purpose of bash (portability)? I guess I don't know the standard, is it reasonable to bundle in a dependency download with a simple bash script (e.g. download the correct version of getopt before parsing args)? I imagine not. How does one properly support long and short options in bash on osx without rolling your own parser?
mbrock 5y ago
If you're okay with depending on Git, you can use `git rev-parse --parseopt`. https://git-scm.com/docs/git-rev-parse#_parseopt https://git-scm.com/docs/git-rev-parse#_parseopt > In --parseopt mode, git rev-parse helps massaging options to bring to shell scripts the same facilities C builtins have. It works as an option normalizer (e.g. splits single switches aggregate values), a bit like getopt(1) does. > It takes on the standard input the specification of the options to parse and understand, and echoes on the standard output a string suitable for sh(1) eval to replace the arguments with normalized ones. In case of error, it outputs usage on the standard error stream, and exits with code 129.
- unixhero 5y ago
  This is really brilliant and I have never heard of this method before. Noting it down thank you.

chasil 5y ago

Why would getopts be discouraged? Where does the POSIX standard say that getopts is discouraged? https://pubs.opengroup.org/onlinepubs/9699919799/utilities/getopts.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/g... https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...

0xbadcafebee 5y ago
getopt is discouraged, not getopts

eterps 5y ago

Some thoughts how future shells might tackle this: https://github.com/oilshell/oil/issues/469 https://github.com/oilshell/oil/issues/469

kps 5y ago

ksh's declarative getopts is easy to use and automatically provides help messages, and is one major reason I use it for day-to-day scripts. It's too bad bash didn't embrace and extend that before they extinguished it.

q3k 5y ago

Or, even better: don't use shell scripts to express the kind of complex logic which requires parsing arguments in multiple forms/modes.