Re: getopts & long options - [was: getopts - mutually exclusive flags]

[Chris Jones]

On Sun, Nov 09, 2008 at 04:42:58PM EST, Bob Proulx wrote:
> Chris Jones wrote:
> > Bob Proulx wrote:
> > > As far as I know with all of the option parsing routines available you
> > > would need to code this type of validation in yourself.  The
> > > combinatorial explosion of combinations of valid and invalid options
> > > are not something that option parsing libraries can handle.  Therefore
> > > you need to check for validity after the options have been read.
> > 
> > Sounds like a limitation (?) ..

> It hasn't seemed limiting to me so far.  The problem is that the
> question of what is valid is uniquely different to almost every
> program in existence.  Worse is when library writers assume a behavior
> which violates other standards or incompletely implements it.  (I have
> been having difficulty with Ruby's optparse library due to this and so
> have been using Ruby's getopt library intead.)

Interesting. I don't know Ruby at all but since I have a superficial
knowledge of Python, I am currently looking at their optparse module..
and one thing I like about it is that one of the very first things that
the author does is to define the scope of the syntax/semantics he
supports:

http://www.python.org/doc/2.5.2/lib/optparse-terminology.html

Not sure if they conform to any particular standards but it looks
sensible to me.

So what I was vaguely hoping getopts would help me do was not only parse
the command but also check the validity of the input. Which would be a
misnomer of course .. since the builtin is called getopts and not
"checkopts" or "verifyopts".

> > Even worse would be: $ backup -mm .. which if unchecked might cause
> > the script to run a full backup twice :-)

> Of course that depends upon how you are processing the options.  If
> you trigger an action whenever an option is seen then that action
> would be triggered twice.  But most people would consider that to be a
> feature and/or would consider it a bug if it did not do this.

[..]

> That is the way I wanted to do it.  But you could easily have
> verbosity be a number.
> 
>   verbose=0
>   while [ $# -gt 0 ]; do
>       case $1 in
>           -v|--verbose)
>               verbose=$((verbose + 1))
>               shift
>               ;;
> 
> Then you could easily support multiple levels of verbosity by
> specifying multiple -v options.

Good point! I'll have to check how I can do this when using getopts.

> > Oh .. more importantly, I've just realized that it does not handle
> > quoted arguments correctly!  myscript -a "what a slip" bigfatfile ..
> > will end up with a file named "a slip bigfatfile" Oh bugger ..
> 
> :-)

> I also find this humorous since apparently the entire reason for
> 'getopts' over 'getopt' is that 'getopts' is supposed to handle
> arguments with spaces better than 'getopt'.

:-)

er.. fixed that.. it was just a case of my $FL needing double quotes.

Thanks, bash..

> > Anyway, here goes:
> 
> A nits.
> 
> > echo "Written by Your Name <yours-[at sign]-truly-[dot]-org>."
> 
> Please don't victimize domains that may actually exist.  Use
> example.com which is designed for this purpose.  You will enjoy
> reading this reference as to why this is a problem.
> 
>   
> http://voices.washingtonpost.com/securityfix/2008/03/they_told_you_not_to_reply.html

Sorry I let this one slip by.. I ususally try to make sure my posts are
netiquette-compliant .. but I should have remembered this also applies
to whatever is pasted/attached .. Worst of it is I found this in no less
that three different scripts and I have no recollection of ever writing
this in the first place. I guess it's best to be careful even when
fooling around in the supposed privacy of one's ~/bin backyard.. 

> Bob

Thanks!

As alway, much appreciated

CJ