Intuitively (i.e. without looking at any documentation), I'd expect the -a to be seen as an unrecognized parameter, and thus the code to error out because -cell didn't get a parameter.
| [reply]
[d/l]
[select] |
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);
| [reply]
[d/l]
[select] |
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] |