ndd@romeo.cs.duke.edu (Ned D. Danieley) (02/02/89)
In section 10.11.3, Parsing Command Line Options (X11R2 manual), it says (very last line): "When parsing the command line, any unique unambiguous abbreviation for an option name in the table is considered a match for the option." Which means if you have a program that wants to use -d as an option, you have to tell Xtinitialize about it, or X will assume that it is the -display option. I would like to argue that X should only match the literal name of the option: I have a basic set of routines that are used by several different programs, each of which have different options. Obviously, I can handle this problem, but I'm not sure that the convenience of substring matching is worth the extra effort. I would be interested in people's comments, pro and con, email or posted. Now, if we are going to keep this method of argument parsing, I would like to suggest that it be extended. Currently, XrmParseCommand can handle at most one argument after an option, and, of course, I have some options that take two or more arguments. I realize that dealing with an arbitrary number of arguments will be messy, but I'm really going to resent having to tell X about my options AND change them to fit its preconceived notions. Any comments about this 'feature'? Ned Danieley (ndd@sunbar.mc.duke.edu) Basic Arrhythmia Laboratory Box 3140, Duke University Medical Center Durham, NC 27710 (919) 684-6807 or 684-6942
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (02/02/89)
I like the prefix recognition, and wouldn't want to see it go away. I have no problem with the notion that if you want to use the toolkit parsing routines, you do it their way. You are always free to parse the command line yourself, and bypass the Xt mechanism entirely. But even so, extending the options for multiple arguments does not sound unreasonable.
swick@ATHENA.MIT.EDU (Ralph R. Swick) (02/02/89)
> Now, if we are going to keep this method of argument parsing, I > would like to suggest that it be extended. Currently, XrmParseCommand > can handle at most one argument after an option, and, of course, > I have some options that take two or more arguments. I would be amenable to a proposal to extend XrmOptionKind to include a type XrmoptionSkipNArgs which uses the value field as a count of args to be skipped. Since XrmOptionKind is an enum with only 6 values, it seems likely that this could be extended by 1 more without loosing binary compatibility on most compilers. Anyone know of any pitfalls? (Yes, it's not truly safe, but... :-)
guido@cwi.nl (Guido van Rossum) (02/03/89)
My strategy in such cases is to tell X or Xt about 'nearly impossible' options starting with -a, -b, -c, etc.; e.g., "-a\377". In this way at least two-character abbreviations for any options Xt knows about are required, and I can use getopt() or a similar parser for my own options. -- Guido van Rossum, Centre for Mathematics and Computer Science (CWI), Amsterdam guido@cwi.nl or mcvax!guido or guido%cwi.nl@uunet.uu.net Hackers' motto: "If all else fails, read the Unix kernel source."
chac@aratar.UUCP (Chuck Clanton) (02/05/89)
in reply to: Danieley re: command line parsing under X11 there is a generic problem with any selection process that allows abbreviation to the shortest unambiguous prefix. i discovered this more than a decade ago under tenex. the addition of new options will break an unpredictable number of currently working scripts and habits. to be safe you must always use the full name (assuming that the old name for an option will almost always be provided for backward compatibility). it usually seems desirable to just not allow those small apparent luxuries (the ability to type a slightly shorter string) whose cost for a large number of less knowledgable or careful users will occasionally be quite high. the minor savings in keystrokes has to be eventually invested in fixing the problems caused by the side effects of such luxuries.