jsq@ut-sally.UUCP (John Quarterman) (07/18/85)
From: Mike Trachtman <wizard%wisdom.bitnet@WISCVM.ARPA>
Date: Thu, 18 Jul 85 13:03:51 -0200
To: std-unix@ut-sally.arpa
Subject: standardized error messages
Is any thought being given to having the compilers, grep, etc.
give error messages in a standard form, so
that programs will be able to parse them.
This is good for many things, in particular emacs make error parsing,
but other uses are also possible.
Mike
Mike Trachtman
My address:
wizard@wisdom (BITNET)
wizard%wisdom.bitnet@wiscvm.ARPA (ARPA/CSNET)
wizard%wisdom.bitnet@berkley (ARPA/CSNET)
and if all else fails (ONLY for VERY short items)
...!decvax!humus!wisdom!wizard (UUCP)
----------------------------------------------------------------------
This moderated newsgroup, mod.std.unix, is for discussions of UNIX standards,
in particular of the draft standard in progress by the IEEE P1003 Committee.
The newsgroup is also gatewayed to an ARPA Internet mailing list.
Submissions to: ut-sally!std-unix or std-unix@ut-sally.ARPA
Comments to: ut-sally!std-unix-request or std-unix-request@ut-sally.ARPA
Permission to post to the newsgroup is assumed for mail to std-unix,
but not for mail to std-unix-request, nor for mail to my personal addresses.
--
John Quarterman, UUCP: {ihnp4,seismo,harvard,gatech}!ut-sally!jsq
ARPA Internet and CSNET: jsq@ut-sally.ARPA, soon to be jsq@sally.UTEXAS.EDUjsq@ut-sally.UUCP (John Quarterman) (07/21/85)
se enough to keep in the same discussion. ---------------------------------------------------------------------- Date: Sat, 20 Jul 85 16:52:04 PDT From: seismo!sun!guy (Guy Harris) To: ut-sally!std-unix Subject: Standardizing exit codes There is currently no universal standard for the meaning of exit codes, except that 0 means "true" or "success" and non-zero means "false" or "failure". Some System V programs use 2 for syntax errors, failure to open files, and the like, and 1 for "the command was run properly but gives a result of 'false'". "delivermail" and "sendmail" expect programs they run to exit with an error code from the include file <sysexits.h> which has a number of exit codes which further break down "failure to execute properly" (like exit code 2 in those System V commands) into "incorrect usage", "input data incorrect", "input file could not be opened", etc.. It might be useful to adopt some convention like that of <sysexits.h>. Exit code 0 would mean "the command executed without problems and returns a 'true' result; exit codes from 1 to some number N1 - 1 would mean "the command executed without problems and returns a 'false' result" - the exit code could be used to further specify the type of "false" result, if desired; exit codes from N1 to 254 could mean "the command did not execute successfully" and the exit codes from <sysexits.h> could break this down further; and exit code 255 would be reserved for forked-off child processes which were supposed to "exec" something but the "exec" failed. (In <sysexits.h>, N1 has the value 64.) Guy Harris ------------------------------
jsq@ut-sally.UUCP (John Quarterman) (07/23/85)
From: John Quarterman (moderator) <std-unix-request@ut-sally>
Topic: standardizing exit codes
It's not quite the same as standardized error messages,
but close enough to keep in the same discussion.
----------------------------------------------------------------------
Date: Sat, 20 Jul 85 16:52:04 PDT
From: seismo!sun!guy (Guy Harris)
To: ut-sally!std-unix
Subject: Standardizing exit codes
There is currently no universal standard for the meaning of exit codes,
except that 0 means "true" or "success" and non-zero means "false" or
"failure". Some System V programs use 2 for syntax errors, failure to open
files, and the like, and 1 for "the command was run properly but gives a
result of 'false'". "delivermail" and "sendmail" expect programs they run
to exit with an error code from the include file <sysexits.h> which has a
number of exit codes which further break down "failure to execute properly"
(like exit code 2 in those System V commands) into "incorrect usage", "input
data incorrect", "input file could not be opened", etc..
It might be useful to adopt some convention like that of <sysexits.h>. Exit
code 0 would mean "the command executed without problems and returns a
'true' result; exit codes from 1 to some number N1 - 1 would mean "the
command executed without problems and returns a 'false' result" - the exit
code could be used to further specify the type of "false" result, if
desired; exit codes from N1 to 254 could mean "the command did not execute
successfully" and the exit codes from <sysexits.h> could break this down
further; and exit code 255 would be reserved for forked-off child processes
which were supposed to "exec" something but the "exec" failed. (In
<sysexits.h>, N1 has the value 64.)
Guy Harris
------------------------------
Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
Submissions-To: ut-sally!std-unix or std-unix@ut-sally.ARPA
Comments-To: ut-sally!std-unix-request or std-unix-request@ut-sally.ARPA
UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)jsq@ut-sally.UUCP (John Quarterman) (07/24/85)
From: John Quarterman (moderator) <std-unix-request@ut-sally> Topic: Re: standardized error messages ---------------------------------------------------------------------- From: oliveb!jerry@fortune.uucp (Jerry Aguirre) Date: Mon, 22 Jul 85 21:42:10 pdt Subject: Re: standardized error messages References: <2391@ut-sally.UUCP> > From: Mike Trachtman <wizard%wisdom.bitnet@WISCVM.ARPA> > Is any thought being given to having the compilers, grep, etc. > give error messages in a standard form, so > that programs will be able to parse them. The sys V announcment that I attended included discussion not only of getopt but of an error library routine. I don't have the syntax handy but it included the severity of the error (warning vs. error vs. fatal), a user supplied message, and optionally the errno determined system error message. I have seen several postings of source which use a similar routine. Does anyone at ATT care to comment on whether an error routine will be included and what the syntax is? Jerry Aguirre @ Olivetti ATC {hplabs|fortune|idi|ihnp4|tolerant|allegra|tymix}!oliveb!jerry ------------------------------ Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard. Submissions-To: ut-sally!std-unix or std-unix@ut-sally.ARPA Comments-To: ut-sally!std-unix-request or std-unix-request@ut-sally.ARPA UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)
jsq@ut-sally.UUCP (John Quarterman) (07/25/85)
From: John Quarterman (moderator) <std-unix-request@ut-sally>
Topic: Re: standardized error messages
----------------------------------------------------------------------
Date: Sun, 21 Jul 85 05:19:11 pdt
From: seismo!nsc!daisy!david (David Schachter)
To: ut-sally!jsq
Subject: Re: standardized error messages
In-Reply-To: <2391@ut-sally.UUCP>
Daisy's version of the UNIX(tm) operating system has a standard
way of handling error reporting. You call a system routine,
passing it an error file number and an error status. You also
pass a flag saying how to handle the error and substitution var-
iables. The system looks up the error file number in a table to
get the names of the error file. It then looks up in the file the
appropriate error message, using a simple transformation of the
error status as the key. The strings in the error file are sim-
ilar in format to the 'printf' function thus allowing you to
substitute variables into the error message.
The flag you pass tells the system whether to display the message,
add it to the stack, display the entire stack (clearing it), or
jump to the machine monitor with a fatal error. Obviously, the
latter case is used only when the error is on the order of "system
corrupt."
You can also pass an error port id if you do not wish the message
to go to std_err.
A subtle advantage of this is that all error messages reside in
external text files, not compiled into the code of the programs.
This results in faster loading, less memory usage, and makes it
easy to change error messages and to enforce consistent style.
[This does not represent official policy by Daisy Systems. The
author speaks only for himself.] {"Where there's a will, there's
a won't."}
------------------------------
Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
Submissions-To: ut-sally!std-unix or std-unix@ut-sally.ARPA
Comments-To: ut-sally!std-unix-request or std-unix-request@ut-sally.ARPA
UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)jsq@ut-sally.UUCP (John Quarterman) (08/01/85)
From: John Quarterman (moderator) <std-unix-request@ut-sally>
Topic: standardized error messages
----------------------------------------------------------------------
From: oakhill!mot!fred (Fred Christiansen)
Date: Fri, 26 Jul 85 16:19:00 cdt
To: oakhill!ut-sally!jsq@tzec.UTEXAS.ARPA
Subject: Re: standardized error messages
the SVID has specifics in Appendix BASE 5.6 (p. 341), which i shall attempt
to summarize:
the std error msg has 5 parts:
Label who's issuing this msg
Severity 4 possible codes (halt, error, warning, fyi)
Problem what went wrong
Action "TO FIX" do such and such
Tag unique error msg id which can be used to
track down more info
Fred Christiansen ("Canajun, eh?") @ Motorola Microsystems, Tempe, AZ
UUCP: ihnp4!{attunix, btlunix, drivax, sftig, ut-sally!oakhill}!mot!fred
ARPA: oakhill!mot!fred@ut-sally.ARPA AT&T: 602-438-3472
------------------------------
From: Mike Trachtman <wizard%wisdom.bitnet@WISCVM.ARPA>
Date: Sun, 28 Jul 85 14:59:04 -0200
To: std-unix@ut-sally.arpa
Subject: standard error messages.
A standard for error messages should be very strict about punctuation,
and where line numbers go.
somthing like
command: filename (linenumber) - severity - message
this is getting kind of IBMsh, but programs should be able
to parse errors, and thus errors should be in a standard form.
errors should definitely include the following
1) the filename where the error was
2) the line number
3) the error, (or in greps case, the line that contained the word
optionally, but in a set format
1) the command or routine that found the error
2) the Unix errno
3) some program generated error number
4) an indication of the severity
Of course, these are only opinions, and they are only my opinions.
Mike
wizard@wisdom (BITNET)
wizard%wisdom.bitnet@wiscvm.ARPA (ARPA/CSNET)
wizard%wisdom.bitnet@berkley (ARPA/CSNET)
and if all else fails (ONLY for VERY short items)
...!decvax!humus!wisdom!wizard (UUCP)
------------------------------
Date: Wed, 24 Jul 85 16:18:22 edt
From: Chris Torek <chris@maryland>
To: std-unix@ut-sally
Subject: Re: standardized error messages
Hm. It's probably too late, but I would suggest that any standard
library routine for printing error message use printf-style
conversions (preferably it should be exactly like printf once you
get past severity stuff and whatnot).
In case anyone wants it, here's the routine I installed in our C
library on our "experimental" machine (it wants a bit of support
in the startup code to set _argv0 to argv[0], so that the program
name is included in error messages, but will work without it). It
is not (alas!) portable, but can be made to work on any of the
popular Unix machines. (I have a manual entry, if anyone cares.)
Chris
#include <stdio.h>
char *_argv0; /* argv[0], set by C startup code */
/*
* error - University of Maryland specific (sigh)
*
* Useful for printing error messages. Will print the program name
* and (optionally) the system error associated with the values in
* <errno.h>.
*
* Note that the type (and even the existence!) of ``arg'' is undefined.
*/
error(quit, e, fmt, arg)
int quit;
register int e;
char *fmt;
{
extern char *sys_errlist[];
extern int sys_nerr;
register char *p = _argv0;
if (p != NULL) {
#ifdef optional
char *s, *rindex();
if ((s = rindex(p, '/')) != NULL)
p = s + 1;
#endif
(void) fprintf(stderr, "%s: ", p);
}
_doprnt(fmt, &arg, stderr); /* magic */
if (e > 0) {
p = e < sys_nerr ? sys_errlist[e] : "unknown error";
(void) fprintf(stderr, ": %s", p);
}
(void) putc('\n', stderr);
(void) fflush(stderr);
if (quit)
exit(quit);
}
------------------------------
Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
Submissions-To: ut-sally!std-unix or std-unix@ut-sally.ARPA
Comments-To: ut-sally!std-unix-request or std-unix-request@ut-sally.ARPA
UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)jsq@ut-sally.UUCP (John Quarterman) (08/04/85)
----------------------------------------------------------------------
Date: Wed, 31 Jul 85 00:34:17 mdt
From: seismo!cmcl2!lanl!unmvax!unmc!galway (Denis McKeon)
To: ut-sally!std-unix
Subject: Re: getopt standard reference
I don't have machine readable version of Hemenway & Armitage
presentation, but their article in UNIX/World Vol. 1 No. 3
covers the choices, tradeoffs, & arguments well, and should be widely
available in the community. Perhaps U/w could post the copy?
dm
Denis McKeon, P.O. Box 4925, Albuquerque, NM 87196
~{convex,ucbvax,gatech,csu-cs,anl-mcs}!unmvax!unmc!galway
~{pur-ee!purdue,ucbvax!lbl-csam,philabs!cmcl2}!lanl!unmc!galway
------------------------------
Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
Submissions-To: ut-sally!std-unix or std-unix@ut-sally.ARPA
Comments-To: ut-sally!std-unix-request or std-unix-request@ut-sally.ARPA
UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)jsq@ut-sally.UUCP (John Quarterman) (08/06/85)
----------------------------------------------------------------------
From: Steve Glaser <steveg%hammer.TEK%tektronix.csnet@csnet-relay.arpa>
To: tektronix!ut-sally!std-unix@tektronix.CSNET,
tektronix!std-unix%ut-sally.arpa@tektronix.CSNET
Date: Mon, 5 Aug 85 17:58:33 PDT
Subject: Re: standardized error messages
in Chris Torek's error example, please change:
> if (e > 0) {
> p = e < sys_nerr ? sys_errlist[e] : "unknown error";
> (void) fprintf(stderr, ": %s", p);
> }
to:
> if (e > 0) {
> if (e < sys_nerr)
> (void) fprintf(stderr, ": %s", sys_errlist[e]);
> else
> (void) fprintf(stderr, ": unknown error number %d", e);
> }
It's most annoying when an error message printing routine throws away
information. Especially when you have new error codes cropping up and
programs that don't get recompiled (or at least relinked).
At least Chris checked against sys_nerr. I've seen may programs that
don't bother and end up printing gibberish when a new error comes along.
Steve Glaser
tektronix!steveg
------------------------------
Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
Submissions-To: ut-sally!std-unix or std-unix@ut-sally.ARPA
Comments-To: ut-sally!std-unix-request or std-unix-request@ut-sally.ARPA
UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)jsq@ut-sally.UUCP (John Quarterman) (08/07/85)
From: John Quarterman (moderator) <std-unix-request@ut-sally> Topic: standardized error messages The idea proposed in this message has been proposed before in this newsgroup. I am letting it through anyway, since this is a more complete description of the idea. After the flurry of rebuttals which will no doubt ensue, I would prefer we not rehash it yet a third time. If the discussion devolves into a TOPS-20 vs. UNIX flaming match, I will at some point (soon) arbitrarily cut it off. ---------------------------------------------------------------------- Date: Fri, 5 Jul 85 12:25:33 est From: Stephen Uitti <seismo!pur-ee!pucc-h!ach> Subject: Re: standardized error messages To: ecn.ARPA!cbosgd!seismo!ut-sally!std-unix >From: Douglas Spencer <seismo!mcvax!daisy!maugg> >> some commands take arguments as >> command -abcdefg filename >> and some as >> command -a -b -c -d -e -f -g filename >> It would be great if this was standardised. The result being getopt, based on these rules: > - Command names must be between 2 and 9 characters ("kermit" is 6). > - Command names must include lower case letters and digits only. > - An option name is a single character. > - Options are delimited by '-'. > - Options with no arguments may be grouped (bundled) behind one > delimiter. > - Option-arguments cannot be optional. > - Arguments immediately follow options, separated by whitespace. > - The order of options does not matter. > - '-' preceded and followed by whitespace means standard input. >A group of bundled options may end with an option that has an argument. I prefer to make a forward sighted change, rather than a backwords compatibility of the problem. Going from no standard to a bad one is no gain. At least with no standard, people had the option of doing it "right". Once a standard is invented, it can't really be changed: the only recourse is to reinvent a new universe. Rules I use for new programs are: 1) Command names must be real words or concatenations of words, max 9 characters (for V7 systems, for now). They must not be one letter. They should be more than 4. Abreviations for parts of the command are acceptible, such as "mk" for "make" and "ck" for "check". Especially if a real word can be used - "mkdepend". Suffixes are better - "filesysck" (might be a better name for "fsck"). Siffixes allow the same abbreviation, but allow someone to write a command-completion or least-ambiguous command recognition shell. 2) Command names should be lower case. 3) Option names are real words. Single letters are too difficult to remember. They are to be parsed in a least ambiguous fashion. 4) "-help" IS an option. This gives a usage message and a one-line description of each option. The manual page should be nearly superflous. In interactive mode "?" gives a quick list of command names. 5) Options start with a "-", on the command line. 6) Options with arguments are of the form -foo=bar,foobar. 7) Options do not get bundled together. This is bogus. 8) Option-argumets are optional. The default is useful. 9) If no options are given, something reasonable will happen. If nothing reasonable can be done, a usage message will be printed. 10) Having an interactive mode is not an unreasonable thing for a program to have. The interactive mode HAS a prompt (which may be turned off/changed). 11) Non-options are usually file names. 12) Options and file names may be interspersed. The order of options often matters. If this is the case, left to right parsing is used. So, if two options (such as -optimize and -nooptimize) conflict, the rightmost will be used. Note that "pascal -opt file2 -noopt file3" will optimize file2, but not file3. To this end, I have written a least ambiguous command parser subroutine library which can be used from the command line and/or interactively. It works well. I like to have billions of options in my programs, but can never remember them. Some of them are seldom used. Often, new options are added. Shell scripts won't break if they always used the whole option name. Shell scripts are more readable if they use the whole option name. Usually one need only type one or two letters of an option name. There are some programs out there that do least ambiguous command parsing: "lpc", "ftp" and "kermit" are some. There's a whole operating system too: "twenex". The reason I vote for such change is that UNIX is no longer V6, with 50 commands, each with 5 options. It's now 400 commands, each with 10 options. V6 ran on an 11/40 that had a single RK05 (2.5 Megabytes), full sources, with 300+ blocks left for the user (150 K bytes of disk). RK05's are now little bigger than floppys (and little faster). Now if you only have 100 Meg devoted to /usr, you might not be able to have quite everything on it. News or sources might have to be put elsewhere. Certainly your users will be elsewhere. The systems are bigger, and harder to maintain. That's progress. Steve Uitti, PUCC, ...pur-ee!pucc-h!ach (ach@purdue-asc.ARPA). (The opions expressed...) ------------------------------ Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard. Submissions-To: ut-sally!std-unix or std-unix@ut-sally.ARPA Comments-To: ut-sally!std-unix-request or std-unix-request@ut-sally.ARPA UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)
jsq@ut-sally.UUCP (John Quarterman) (08/14/85)
----------------------------------------------------------------------
Date: Sun, 11 Aug 85 23:20:34 edt
From: Ian! D. Allen <ihnp4!watmath!idallen>
To: ut-sally!std-unix
Subject: On interspersing options in command lines.
At Waterloo, we've used full-word options on our Honeywell/GCOS system
for years. Gosh it makes reading the "man" pages easier! We're bringing
an automated full-word-options parser to our UNIX systems now, and our
parser will have the "+help" self-documentation feature. (At Waterloo
we use "+" and "-" for ON and OFF, rather than '-opt' and '-noopt'.)
Consider how the following syntax might be interpreted:
$ commandname +optimize file1 -optimize file2 file3
1) Options are only recognized at the beginning of a command line.
- file1 is optimized; file named '-optimize' is not found
2) Options are recognized where they are found, and apply to all
following objects.
- file1 is optimized; file2 and file3 are not optimized
3) Options apply to the entire command line, no matter where they are found.
- option '+optimize' conflicts with '-optimize' and nothing is done
Waterloo is currently using the Type 3 interpretation. If options
apply to the entire command line, no matter where they are typed, I can
enter the words on my command lines in the order I think of them. I
find the most common way I enter command lines is to type in all the
file names first, then follow them with the modifying options I want.
In the rare (very rare) cases where I want to apply the same command
with different options to some files, I use separate command lines.
I claim that the convenience of letting users type in the words in the
order they want more than compensates for the resulting need to use
multiple commands every now and then. (I'd love to have some survey data
to back this claim up.)
------------------------------
Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
Submissions-To: ut-sally!std-unix or std-unix@ut-sally.ARPA
Comments-To: ut-sally!std-unix-request or std-unix-request@ut-sally.ARPA
UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)