RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (11/06/87)
Date: Mon, 2 Nov 87 15:21:44 PST
From: bilbo.geoff@CS.UCLA.EDU ( Geoff Kuenning)
Subject: Bug report -- problems with toolkit arg processing/philosophy
VERSION:
X11 release 1
SYNOPSIS:
Argument processing buggy, nonstandard, and problematic
DESCRIPTION:
The argument processing in XrmParseCommand is both buggy and
poorly designed. The bugs are in the handling of special
characters: any argument that contains a colon, or that
begins with an equals sign, will be taken as a display name
or geometry specification, respectively. This is done
without regard to whether or not such an argument has
already been seen, so that in a command such as:
xedit athena:0 /usr/src/cmd/sys5:mk
will fail because it can't connect to machine "/usr/src/cmd".
This bug brings up a much larger issue, which is the X
project's approach to argument design. The standard for
command-line arguments, adopted by AT&T, Sun, and the Posix
groups, calls for single-character flags only, with
arguments accepted either concatenated or separate. The
ONLY acceptable leadin character is "-"; negating flags
with "+" or using special characters such as "=" to indicate
certain types of arguments are not allowed.
Note that there is very little to be gained from the special
treatment of the equals sign and colon. The programs I have
written use getopt-style parsing, and accept "-d" for the
display name and "-g" for geometry. I do not find it
especially onerous to type these two extra characters,
especially because it frees me up to use colons and equals
signs in my file names and other arguments.
A related issue is the approach to resource setting in the
toolkit. The current approach requires the main() routine
to support a wide variety of switches, several per widget
used. If there are several similar widgets, it can be
difficult to come up with switch names for their many
resources (e.g., horizscrollthumbcolor...). Furthermore,
the table in the main() routine must be aware of all of the
command-line-settable resources supported by every widget it
uses. (This is in contrast to the parsing of the .Xdefaults
file, where the information table comes from the widget
itself.)
A possible solution to the latter issue is to use a generic
"-R" switch to specify resources, for example:
xterm -d athena:0 -g =-0-0 \
-R 'scroll.background: green,scroll.thumb: blue'
The -R switch could be repeated to specify multiple
resources, or a comma can be used as in the example above.
(This should be a user option). Newline should also be
supported as a separator.
This supports complete flexibility without forcing a whole
incompatible switch scheme on the programmer. For a cost of
three switches, I can set any resource of any widget ever
invented, and the rest of the single-character switch space
is still available for my application.
One minor detail is in the implementation: XtInitialize,
which needs to know the display name, should be separate
from resource initialization. This is so the user can
write:
XrmInitialize ();
while ((optch = getopt (argc, argv, "d:g:R:")) != EOF)
{
switch (optch)
{
case 'd':
displayname = optarg;
break;
case 'g':
geometry = optarg;
break;
case 'R':
XrmAddCommandResources (optarg);
break;
}
}
XtInitialize (displayname, ...);
REPEAT-BY:
Eyeball the code
FIX:
Nontrivial, though not difficult. See the suggestions
above.
Geoff Kuenning geoff@lcc.ucla.edu geoff@ITcorp.comkarlton@decwrl.dec.com (Philip Karlton) (11/07/87)
>Date: Mon, 2 Nov 87 15:21:44 PST >From: bilbo.geoff@CS.UCLA.EDU ( Geoff Kuenning) ... > This bug brings up a much larger issue, which is the X > project's approach to argument design. The standard for > command-line arguments, adopted by AT&T, Sun, and the Posix > groups, calls for single-character flags only, with > arguments accepted either concatenated or separate. The > ONLY acceptable leadin character is "-"; negating flags > with "+" or using special characters such as "=" to indicate > certain types of arguments are not allowed. ... It is not intended that X only be available on a single operating system. There is no single convention that will make everybody happy. The X community has to decide if it wants to pick a single method convention or leave that up to the vender/OS. Note that if the user interface is going to be different on each platform, not only will the code have to be changed, but the documentation as well. In the future this may become less of an issues. One would expect that as more applications move from having teletype oriented user interfaces to having full screen interfaces, the need for parsing "command lines" would be reduced. PK
guy@gorodish.Sun.COM (Guy Harris) (11/07/87)
> > The standard for command-line arguments, adopted by AT&T, Sun, and > > the Posix groups, calls for single-character flags only ... > > It is not intended that X only be available on a single operating system. > There is no single convention that will make everybody happy. There's not even a single convention on UNIX systems; the "standard" in question is honored as much in the breach as in the observance. Neither AT&T nor Sun have converted every command on their systems to agree with that convention, and frankly I suspect neither AT&T nor Sun will ever do so - there's too much history in old commands (care to guess how many shell files will break if "ed -" stops working?). The standard in question is more of a convention than a standard. Nobody will shoot you if you write code that doesn't adhere to it; some people may curse you for it, and some may praise you for it. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
bilbo.geoff@CS.UCLA.EDU (Geoff Kuenning) (11/10/87)
Guy Harris writes: > There's not even a single convention on UNIX systems; the "standard" in > question is honored as much in the breach as in the observance. Neither AT&T > nor Sun have converted every command on their systems to agree with that > convention, and frankly I suspect neither AT&T nor Sun will ever do so - > there's too much history in old commands (care to guess how many shell files > will break if "ed -" stops working?). > The standard in question is more of a convention than a standard. Nobody will > shoot you if you write code that doesn't adhere to it; some people may curse > you for it, and some may praise you for it. This shows a rather severe misunderstanding of what a standard is and is for. Let me point out that NFS is a standard, even though not everyone follows it. Despite Guy's misunderstanding, and despite the fact that AT&T will never completely rewrite history to conform to the standard, the standard *does* exist, and those who choose to ignore it risk being ignored themselves. As to the person who said that X is intended to run on many different systems, please give me a break. Do you really think DEC intends to force its VMS users to accept UNIX-style switches on their VMS X utilities? DEC, like any professional organization, is going to have separate command-line interfaces for separate operating systems. Geoff Kuenning geoff@lcc.ucla.edu geoff@ITcorp.com
shaddock@RTI.RTI.ORG (Mike Shaddock) (11/10/87)
I personally dislike the "standard" of single character flags. There is nothing wrong with having an option like "-help", or "-name" (cutting down on typing is not a particularly worthwhile argument). One of the things that people complain about Unix is "It's too obscure. All those funny little non-mnemonic single character options." It should also be possible to only have to enter the unique initial part of the option. In other words, if a program has the "-name" option, and that is the only option that begins 'n', then "-n", "-na", "-nam", and "-name" should work. This would allow experienced users to abbreviate things, while inexperienced users would be able to figure things out more quickly. I do agree that all options should begin with a a '-', but I do not think that you should be able to group multiple arguments behind a single '-' (this would obviously break the verbose commands). I do think that the -g (geometry) and -d (display) arguments would be a good idea; I also dislike using '+' for an argument delimeter.
daveb@geac.UUCP (11/18/87)
In article <127@bacchus.DEC.COM> karlton@decwrl.UUCP (Philip Karlton) writes: ||Date: Mon, 2 Nov 87 15:21:44 PST ||From: bilbo.geoff@CS.UCLA.EDU ( Geoff Kuenning) |... || This bug brings up a much larger issue, which is the X || project's approach to argument design. ... || acceptable leadin character is "-"; negating flags || with "+" or using special characters such as "=" to indicate || certain types of arguments are not allowed. |... | |It is not intended that X only be available on a single operating system. |There is no single convention that will make everybody happy. The X community |has to decide if it wants to pick a single method convention or leave that up |to the vender/OS. Hey people, why not push the problem out of the X world by saying that client programs are advised to use getopt, and be prepared to have different implementations of getopt for different convention-sets selected in their linkage directives. After all, this is a POSIX/VMS/whatever issue, not an X issue. --dave (mix not the metaphors) c-b -- David Collier-Brown. {mnetor|yetti|utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
barmar@think.COM (Barry Margolin) (11/24/87)
In article <1852@geac.UUCP> daveb@geac.UUCP (Dave Collier-Brown) writes: > Hey people, why not push the problem out of the X world by saying >that client programs are advised to use getopt, and be prepared to >have different implementations of getopt for different >convention-sets selected in their linkage directives. After all, >this is a POSIX/VMS/whatever issue, not an X issue. The purpose of the argument-processing routine in the toolkit is to make it easy for all client applications to have a consistent command interface. I agree with those who said that the implementation on a particular OS should be consistent with other commands on that OS, rather than making the argument processing consistent across all X implementations. However, this should be done by having a different version of the toolkit routine (or appropriate #ifdef's in a single implementation), NOT by pushing the burden of writing the argument processing onto the application programmer. For one thing, if a future revision of X has use for a new command option, it can be added to the toolkit and all clients will pick it up automatically the next time they are relinked. --- Barry Margolin Thinking Machines Corp. barmar@think.com seismo!think!barmar
haynes@DECWRL.DEC.COM (11/25/87)
... this should be done by having a different version of the toolkit routine (or appropriate #ifdef's in a single implementation), NOT by pushing the burden of writing the argument processing onto the application programmer ... Barry Margolin Thinking Machines Corp. We are in complete agreement. This is *exactly* the intent of the toolkit argument parsing module. Thank you, -- Charles