Comments on: Command line arguments in bash scripts

By: chilicuil

chilicuil — Wed, 30 Jun 2010 00:02:16 +0000

Hey dude, thanks a lot for sharing this peace of goodness, I've been dealing with getopts and getopt and I still can't believe how bash has no proper built-in functions to deal with all kind of options. getopts is great, but I really wanna be able to use –long-options. There are a lot of libraries who try to fix this issue but so far this one is the most easy and easy to integrate (I don't wanna source any other file!) that I've found, I wanna focus in my code not in handling options.

Thanks again!

By: anonymous

anonymous — Sun, 25 Jan 2009 15:18:13 +0000

He's right, y'know.

getopt works quite marvelously, and re-inventing the wheel is pretty retarded.

Six levels of nesting, just to parse parameters looks like a maintainability nightmare, compared to a single, simple while/case loop.

By: Toki

Toki — Wed, 10 Dec 2008 13:29:06 +0000

Thank you:)

By: apokalyptik

apokalyptik — Tue, 18 Nov 2008 12:24:58 +0000

@Doug — Why thanks. I especially appreciate the retarded bit. Cheers!

By: fabricio

fabricio — Mon, 17 Nov 2008 07:41:26 +0000

Here's yet another take on it: http://codesnippets.joyent.com/posts/show/1697

By: Doug

Doug — Thu, 13 Nov 2008 09:55:48 +0000

This is a pretty retarded and feature-lacking re-invention of the wheel. Seriously:

help getopt;

It's a bash built-in (and mostly compatible binaries that the built-in was based off of exist on any sane system even without bash!).

Example usage:

# Parse commandline options.

GETOPT="$(getopt -o c:olhdfs –long children:,stdout,syslog,help,dry-run,force,status -n "$0" — "$@")"

if [ "$?" -gt '0' ]; then

echo "$USAGE"

exit 1

eval set — "$GETOPT"

while true; do

case "$1" in

-h|–help) echo "$USAGE"; exit 0 ;;

-c|–children) if [ "$2" -gt '0' ] >/dev/null 2>&1; then

MAXCHILDREN="$2";

shift;

else

echo "Number of children MUST be an integer.";

exit 1;

;;

-o|–stdout) TTYOUT=1; shift ;;

-l|–syslog) SYSLOGOUT=1; shift ;;

-d|–dry-run) TTYOUT=1; DRYRUN=1; shift ;;

-s|–status) TTYOUT=1; STATUSONLY=1; shift ;;

-f|–force) FORCE=1; shift ;;

–) shift; break ;;

*) echo "Invalid Option ${1}."; echo "$USAGE"; exit 1 ;;

esac

done

By: Bookmarks about Scripts

Bookmarks about Scripts — Sat, 27 Sep 2008 03:15:04 +0000

[...] – bookmarked by 1 members originally found by showwhat on 2008-09-09 Command line arguments in bash scripts http://blog.apokalyptik.com/2008/07/07/command-line-arguments-in-bash-scripts/ – bookmarked by 6 [...]

By: bothie

bothie — Fri, 22 Aug 2008 08:03:02 +0000

>>> For this reason the script should be updates to allow for arguments like “–arguments=–foo”

Watching closer on the script I discovered, that the script already support that style of arguments.

However, it doesn't support other things. Imagine

mv -i oldname newname

This would lead to i=oldname and newname -> ???

In short: This script helps in parsing command line options, but it isn't the non-plus-ultra yet.

Regards, Bodo

By: bothie

bothie — Thu, 21 Aug 2008 06:33:07 +0000

Oh, and another thing.

@Milian Wolff:

It doesn't make a difference if you write

run.sh –file "foobar" –arguments "–foo"

or if you write

run.sh –file "foobar" –arguments –foo

For this reason the script should be updates to allow for arguments like "–arguments=–foo"

Regards, Bodo

By: bothie

bothie — Thu, 21 Aug 2008 06:30:35 +0000

Two comments:

1. Instead of

OIFS=$IFS; IFS=$(echo -e "n"); getopt $@; IFS=$OIFS

you could also just write

getopt "$@"

2. It may be a security problem if the getopt function may write any variable in the normal namespace of the script. So, it's better to prefix each variable by e.g. "arg_". So –name bothie won't get name="bothie" but arg_name="bothie".

Regards, Bodo