Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!amdahl!vohra
From: vohra@uts.amdahl.com (Pavan Vohra)
Newsgroups: comp.unix.wizards
Subject: GNU wish list
Keywords: gnu
Message-ID: <649Q02pt31vt01@amdahl.uts.amdahl.com>
Date: 3 Jun 89 08:18:13 GMT
Organization: Amdahl Corporation, Sunnyvale CA
Lines: 45

In article <15810@vail.ICO.ISC.COM> you write:
>In article <2501@gandalf.UUCP>, ml@gandalf.UUCP (Marcus Leech) writes:
>
>>...Options that perform the same function in different commands should
>> have the same names...
>
>In principle, a good idea, but this depends on the (very loosely coupled)
>command authors to get together and agree a priori.  It's a "system issue"

The lack of standards on options encourages creativity and choice among
schemes.  With constant refinement in the form of periodic overhaul
(how about we clean up UNIX once every few years?) the good ones survive
and the bad ones die off.  Eventually we might achieve homeostasis; the
schemes that survive are de facto standards.  If not, tastes differ.

Note that compatibility concerns and the above are only slightly
antithetical; we can sort of phase things out if necessary (but
start anew with GNU).

Nevertheless, note that errno (/usr/include/sys/errno.h) has been
moderately successful; there are some problems with it, but it is
often useful and both system calls and library functions do use it.
That is an example of standardization.

While I am on the subject of errno, why not have a perrorf(3C)?  It is
like printf(3C) exactly except that it prints "cmdname:" as the first
characters of the line and it has a format character for the error
message.  (e.g.

    perrorf("could not read %s: %@.\n",filename);

to print something like

    myprog: could not read /usr/you/.myprogrc: No permission.

.)

I am KC, not Pavan.

-- 
---
Pavan Vohra             {..hplabs|ames|ihnp4|decwrl}!amdahl!vohra
Amdahl Corporation
Sunnyvale, CA 94086-3470
---