Re: Command line help options
- Posted by nanochip Nov 29, 2010
- 1458 views
Just done a little with the example, and if you copy and paste, it doesn't work, as is.
Even without the bug, it doesn't works "as is" as it doesn't even include the required included files. Imagine a newcomer to Euphoria (or, worse, to programming) going round and round until he/she figures out which include files command used in the example belongs to.
Also, is there a way to get rid of those annoying square brackets around command line options? Yes, I know they stand for optionals options but... still annoying for my taste.
And what would you like to see instead?
When needed, an option to include them or not.
With standards come instant usability. It shouldn't be removed w/o a very good reason, IMHO. Making your program different than every other program does not provide any benefit, only downfall. Jeremy
Anyone who works with Unix/Linux systems knows that, for example, almost none of Unix built-in commands uses brackets embracing any option when help is invoked, unlesss, of course, you are suggesting that Unix/Linux authors don't adhere to standards.
May be there only two exceptions:
- The "Usage: cmd [OPTION...] [BLA...]... [BLA...]" line, usually at the top of the help screen. Interestingly, this is the only standard Euphoria interpreter doesn't display when help is invoked.
- Optional (or different) options for options: --with-mysql[=PATH], --include[=FILE], --color[=COLOR]
So... which standards are you talking about?
If you want your command line parsing to be non-standard, I would recommend implementing your own command line parser. Jeremy
It was the first thing to come to my mind but before re-inventing the wheel, I prefer to ask.
A word of caution for English centric adepts. It's true that programming languages are English centric, but bear in mind that those adepts took too long to realize the very simple fact that English is not the only language on the Earth and not all letters/symbols from other languages can be represented with only one byte (not even written from left to right) and that caused and is still causing too much confusion in standards.
