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

[Bob Proulx]

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.)

> 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.

> OTOH ..
> $ backup -vvv
> ... "very verbose"

Sure.  Trigger an action to increase the verbosity every time -v is
seen in the option list.  Works okay.

> Not sure if the latter conforms with GNU coding standards?

I am not going to look but I think that is okay.  I don't think anyone
would complain there.

> > Here is a quick example of the way that I normally do these types of
> > Hope this helps,
> 
> Priceless .. since it would have taken me forever to (?) come up with
> something clean like the above.

Glad to have been able to help.

> Actually answers other -- more crucial, questions than the one I
> initially asked.
> 
> .. i.e. coding tactics, strategy, & style.

There is a lot of personal style that goes into a program.
Unfortunately it seems that whenever things become "standardized" into
a library or some such the design by committee aspect usually doesn't
help the code.  :-) What you saw reflects my own personal tastes.  If
you asked ten programmers for an example such as that you would get
twelve different examples total from eight of them who responded.

> To better memorize the teachings of your sample, I used it as a template
> for a rough wrapper/frontend of a self-imposed exercise that tries to
> work around the "long options" limitation of the getopts bash builtin.

Fun!

> I have half-tested it and it appears to work as long as you don't try
> anything too crazy ... still needs adding some input validity checks!
> ...
> One thing that the script (getopts?) does not handle is the duplication
> of a flag such as in:
> 
> myscript -bbbb
> 
> But the way flags are handled in your script -e.g. makes this a moot point
> anyway - it just sets the internal 'true/false' flag to 'true' several
> times instead of once.

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.

> 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'.

> Anyway, here goes:

A nits.

> echo "Written by Your Name <yours@truly.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

Bob