vohra@uts.amdahl.com (Pavan Vohra) (06/03/89)
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 ---
guy@auspex.auspex.com (Guy Harris) (06/04/89)
>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. Why not just implement "strerror", as per the proposed ANSI C standard, which takes an error number as argument and returns a pointer to an appropriate message for that error, and construct the message yourself? This has the advantage that if you *don't* want to just blat the error out to the standard error, you don't have to do so....