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

How do you expect to know what any of the options means — or that they even exist — without reading the program's docs?

Scenario 1

You, as a reader of the command line, are making the *assumption* that -a is an option. The crafter of the command line should have avoided that confusion by using -cell=-a, but that doesn't excuse the negligence of the reader.

Scenario 2

You, as the crafter of the command line, don't know that -cell requires a parameter. The problem could be:

You read the program's docs, but they were incomplete.
You read the program's docs, but they were unclear.
You didn't read the program's docs, and you made the *assumption* that -cell didn't require a parameter.

That's why it's important for the programmer to validate the input from the user. In all three cases, having something like the following would have helped:

usage("Bad value $opt_cell for option -cell")
   unless is_valid_cell($opt_cell);
[download]

Comment on Re^3: Issues w/ getOptions parsing options with pass_through enabled Select or Download Code

Replies are listed 'Best First'.
Re^4: Issues w/ getOptions parsing options with pass_through enabled by Crackers2 (Parson) on May 24, 2006 at 03:54 UTC
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.	[reply]
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]