vyw@stc06.ctd.ornl.gov (WHITE V L) (01/09/90)
From: WHITE V L <vyw@stc06.ctd.ornl.gov> To: isaak@decvax.dec.com Cc: std-unix Jim Isaak, Chairperson, IEEE/CS P1003 I am very concerned about the reports from the 1003.2 subcommittee that the names of many commands are being changed for the standard; I am led to believe that "lint" is being renamed "lint89" and that the C compiler is now "c89". I, for one, don't want the inconvenience of learning to type new names for such common commands. I don't want to revise all my makefiles or scripts solely to change a command name and I can't believe anyone who had to support an entire operating system would like it any better. And finally, this particular name change hints that every time any command is modified, its name will change to reflect its version number, which could generate quite a number of command name changes per year. I assume that the new versions of these programs are sufficiently similar to the old versions so that they accept most of the same options and arguments and respond with most of the same behavior (if not, they should be considered entirely new programs). If this is the case, most scripts would not need to be rewritten to accomodate them unless the command name changed. I agree with editor Jeffrey Haemer that if the old command is still needed, IT should be renamed. I understand from the regular summary of standards groups posted on comp.std.unix that Hall Jespersen and Don Crayun chair and co-chair 1003.2, but their addresses were not included in the summary, which stated that comments on subcommittees should be addressed to the 1003 chair. If I should address these comments elsewhere, please let me know. Thank you. Vicky White Oak Ridge National Laboratory Oak Ridge, Tennessee vyw@ornl.gov Volume-Number: Volume 18, Number 11
gwyn@smoke.brl.mil (Doug Gwyn) (01/31/90)
From: Doug Gwyn <gwyn@smoke.brl.mil> In article <514@longway.TIC.COM> Donn Terry <donn@hpfcrn.hp.com> writes: >I have been trying, so-far unsuccessfully, to get 1003.2 to reserve a >namespace to the vendors for options for these commands (at least) ... My recommendation for years has been that vendor additions be confined to upper case, leaving lower case options for the (gradually growing) standard environment. Volume-Number: Volume 18, Number 32
kingdon@ai.mit.edu (Jim Kingdon) (02/04/90)
From: kingdon@ai.mit.edu (Jim Kingdon)
My recommendation for years has been that vendor additions be confined
to upper case, leaving lower case options for the (gradually growing)
standard environment.
But this way every time an option gets standardized, all
implementations and users have to change. This does not accord with
"minimal changes to existing practice". Long options (e.g. "ls +all
+format long" (or "ls +all +fo l" if those abbreviations are
unambigous) instead of "ls -al"), however, are less likely to conflict
with each other, so this is the way to go particularly for options
not used interactively or options rarely used.
Volume-Number: Volume 18, Number 40donn@hpfcrn.hp.com (Donn Terry) (02/06/90)
>From: kingdon@ai.mit.edu (Jim Kingdon) > > My recommendation for years has been that vendor additions be confined > to upper case, leaving lower case options for the (gradually growing) > standard environment. > >But this way every time an option gets standardized, all >implementations and users have to change. This does not accord with >"minimal changes to existing practice". Long options (e.g. "ls +all >+format long" (or "ls +all +fo l" if those abbreviations are >unambigous) instead of "ls -al"), however, are less likely to conflict >with each other, so this is the way to go particularly for options >not used interactively or options rarely used. If there is a reserved namespace for vendors, then they can freely add symbols in that namespace. If/when a feature becomes standardized, it is standardized into the namespace reserved for the standard. As long as the vendor has sense enough to accept the old flag as a synonym (at least for a while) nothing breaks. The breaks occur when the vendor didn't use the reserved namespace (possibly because there was none) and the standard usurps that symbol for something else. (Probably because some other vendor had used it for something else which was valuable. The usual compromise here is to use a new letter (with no mnemonic value!) that no-one is using.) Again, one man's existing practice is another's gratuitous change. Donn Terry (again, speaking only for myself) Volume-Number: Volume 18, Number 49