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
