Re: Interesting handling of command line arguments

|--==> "SJT" == Stephen J Turnbull <stephen(a)xemacs.org&gt; writes: SY> How about '\' to be used in front of a filename that starts SY> with '-'. SJT> You mean, escape that with "\\"? Ah, yeah. SJT> Shell escaping/quoting is very inconsistent. Anything that involves SJT> single or double quotes or backlashes is just not going to make sense SJT> to people on some shell or other. The --option=-value (or --option SJT> -value) solution, on the other hand, should make it clear what is SJT> intended, and is moderately consistent with the -f or -e options used SJT> by many stream processors to escape regexps and the like. I see your point, fair enough. Damn that portability. :-) SJT> O Starts with a dash, it's an option. If it isn't a legal SJT> option, XEmacs should quit SJT> Why should XEmacs quit? Consistency. A large proportion of the software that I use (all open source, predominately GNU) seem to do things this way. SJT> By the time it gets to parsing the options, it has done almost SJT> all of the startup work. Why waste that user time? OK, this might sound like a really silly question, but why wouldn't parsing the command line args be one of the first things that XEmacs does on startup? SY> should result in an unknown option error: '-something' (+ SY> appropriate usage help, perhaps with a tip about escaping SY> filenames). SJT> xemacs --help produces 43 lines of text. Isn't that better displayed SJT> in a buffer, if we're already to the point where we can display SJT> buffers? Yes it is[1]. So '--help' wouldn't be appropriate here. But a very terse "Illegal option: '-something'; if '-something' is a filename please use '--file=-something'" would be enough. Footnotes: [1] Incidently, M-! xemacs --help RET produced an output buffer of 104 lines here. -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|