Re^4: Issues w/ getOptions parsing options with pass

When I said "without reading the docs", I meant the GetOpt docs, not the program's docs.

Personally, for any program that uses a dash to start its options, I would assume that any parameter starting with a dash would be treated as an option, whether or not that option is actually valid for the program or not. So the error code I'd expect to get back in the above scenario is "No value of option -cell", regardless of whether -a is a valid option or not, not "Bad vaue for option -cell".

I'm not saying that this is the only way options can be handled, I'm just saying that I believe that's the most intuitive way.

And how your program parses its command line is unrelated to whether it needs to validate its input or not.

Comment on Re^4: Issues w/ getOptions parsing options with pass_through enabled

Replies are listed 'Best First'.
Re^5: Issues w/ getOptions parsing options with pass_through enabled by ikegami (Patriarch) on May 24, 2006 at 04:43 UTC
When I said "without reading the docs", I meant the GetOpt docs, not the program's docs. There's absolutely no need for the user to read Getopt::Long's docs. The command's docs you should say that `-cell` requires a value, and that's all the info the user needs to know. Personally, for any program that uses a dash to start its options, I would assume that any parameter starting with a dash would be treated as an option I've never seen that. Even `perl` isn't like that. For example. `perl -e -1` executes `-1`. Any time I've seen a program accept spaces between the option name and the option value, the following parameter is treated as the value, even if it starts with the option prefix. I'm not saying that this is the only way options can be handled, I'm just saying that I believe that's the most intuitive way. So what would you do when you need to specify `-a` to be the value of `-cell`? If you make strings starting with a dash exceptional, you need to provide an escape mechanism to make the exception non-execptional. You call your way of thinking intuitive, but I don't see how more intuitive you can get than "the parameter that follows `-cell` is the value for cell". Period. Anything else is more complicated. And how your program parses its command line is unrelated to whether it needs to validate its input or not. True. What's your point?	[reply] [d/l] [select]
Re^6: Issues w/ getOptions parsing options with pass_through enabled by Brawny1 (Initiate) on May 24, 2006 at 13:41 UTC
Sorry, I'm a newbie and didn't read the whole thread. Why can't there a be a mode that options are exclusive to - && -- and if you wanted to specify an option as the value for another option you do it in single/double quotes? For example, testscript -arg1 "-arg" -arg2 I would think most programs when requiring a string for an option are NOT expecting another option. This would be a typo in the program invocation.	[reply]