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]

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.

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?