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?
In reply to Re^5: Issues w/ getOptions parsing options with pass_through enabled
by ikegami
in thread Issues w/ getOptions parsing options with pass_through enabled
by Brawny1
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |