Re: bash vs perl

in reply to bash vs perl

Actually it's very easy to use getopts from bash the way you're asking. This example would handle myscript.sh -a -b testval -c anotherval with the options a, b, and c.

while getopts ab:c: FOO
do
    case ${FOO} in
        a)  BAR="somevalue"
            ;;
        b)  BAR="${OPTARG}"
            ;;
        c)  BAZ="${OPTARG}"
            ;;
       \?)
            echo "<some help text>"
            exit 1
            ;;
    esac
done
[download]

The getopts ab:c: means that it's looking for -a, -b, -c and the colon after the b and the c means it expects a value to be specified for those params.

So, while it's obviously not that difficult, it's also very, very limited and is vastly outstripped by perl modules like Getopt::Long. For example, you can only use single letters for your options. Sure, that's 24 available options which is plenty for most scripts, but what if you wanted to specify something like -min and -max. Suddenly you have to remember what letter you've assigned to what functions and it quickly becomes unwieldly.

Check out my brief Getopt::Long example I posted over here recently.

--
naChoZ

Therapy is expensive. Popping bubble wrap is cheap. You choose.

Comment on Re: bash vs perl Select or Download Code

Replies are listed 'Best First'.
Re^2: bash vs perl by leocharre (Priest) on Jan 11, 2008 at 16:00 UTC
Thank you for the example. Indeed when I saw these kinds of scripts to read three options, that's what made me gag. That's a lot of typing for three options. As I'm sure you know, compared to perl's 3 (three, tres) lines: `use Getopt::Std; my $o={}; getopts('ab:c:defghijklmnop',$o); # map { printf "%s %s\n", $_, $o->{$_} } keys %$o;` [download] I disagree that single letter options are limited, in fact I throw a tantrum about that. '--min' in one cli app may be '--minimum' in another, we know that. So long notation doesn't really improve anything more then legibility, at least for the occasional user. Yes, yes.. then there are monsters like imagemagick convert.. good point, those need long. The only thing we can ever really be sure of is that hopefully us who code actually reserve -h for help, and that the documentation exists. The documentation is the authority for an interface. Some basic rules alway, yes.. options before file lists.. -h for help, -v for version, etc.. The user should never have to remember anything. Ever. -h, man, and info will tell them whatever they need to know. By the way, it's not 24, it's 52 or so, caps ! And I use them. And I document them. :-)	[reply] [d/l]

Replies are listed 'Best First'.

Re^2: bash vs perl
by leocharre (Priest) on Jan 11, 2008 at 16:00 UTC

Thank you for the example. Indeed when I saw these kinds of scripts to read three options, that's what made me gag.

That's a *lot* of typing for three options. As I'm sure you know, compared to perl's 3 (three, tres) lines:

use Getopt::Std;
my $o={};
getopts('ab:c:defghijklmnop',$o);

# map { printf "%s %s\n", $_, $o->{$_} } keys %$o;
[download]

I disagree that single letter options are limited, in fact I throw a tantrum about that.
'--min' in one cli app may be '--minimum' in another, we *know* that. So long notation doesn't really improve anything more then legibility, at least for the occasional user. Yes, yes.. then there are monsters like imagemagick convert.. good point, those need long.

The only thing we can ever really be sure of is that hopefully us who code actually reserve -h for help, and that the documentation exists.

The documentation is the authority for an interface. Some basic rules alway, yes.. options before file lists.. -h for help, -v for version, etc.. The user should *never* have to remember anything. Ever. -h, man, and info will tell them whatever they need to know.
By the way, it's not 24, it's 52 or so, caps ! And I use them. And I document them. :-)

[reply]
[d/l]

In Section Seekers of Perl Wisdom