nerd@percival.UUCP (Michael Galassi) (08/28/87)
In article <209@ho7cad.ATT.COM> nuucp@ho7cad.ATT.COM (UUCP) writes: >Well, I agree. This is pretty funny. But don't blame compress. A >lot of programs give you this. Seems to be what you get on some >machines when you call "perror()" when there ain't been no error (of >its genre) [or maybe when the error number is bigger than the secret >message array]. Most of the time I see this message seems to be the case where someone tries to port a program to something like microport system 5 which has no "sysexits.h". They then run off to the closest vax runing BSD and swipe the file from there. All well and file except that the maping of the error messages to the numeric codes passed as arguments to perror() are not the same in BSD as they are in microport. Hence the bizare messages (fine debuging aid they make). All of this is a theory based on having seen many an error message apear out of context on microport in programs that like compress and RCS were written originaly on BSD systems. Also, my home machine is a BSD 4.2 and between it and the vax (BSD 4.3) I have never seen these messages and these are the machines where I spend most of my time. -michael
guy%gorodish@Sun.COM (Guy Harris) (08/29/87)
> Most of the time I see this message seems to be the case where someone > tries to port a program to something like microport system 5 which has > no "sysexits.h". They then run off to the closest vax runing BSD and > swipe the file from there. All well and file except that the maping of > the error messages to the numeric codes passed as arguments to perror() > are not the same in BSD as they are in microport. Hence the bizare > messages (fine debuging aid they make). > > All of this is a theory based on having seen many an error message apear > out of context on microport in programs that like compress and RCS were > written originaly on BSD systems. This theory requires a pretty impressive deductive leap to get from "I see these messages on Microport systems but not BSD systems" to "it must be "sysexits.h". Unfortunately, that leap will drop you in a canyon; it's bogus as hell. The error codes in <sysexits.h> have NOTHING WHATSOEVER to do with the system call error codes in <errno.h>. <errno.h> is present on Microport System V and any other system that 1) supports program development and 2) can justifiably claim to be UNIX or derived therefrom. Furthermore, most of those numeric codes are generated from *system library routines*; this means that the values in the include files on *your* machine are totally irrelevant - the only values that are relevant there are the ones defined on the machine on which the system was built, and the chances are good that this value did not change between the time "perror" was compiled and the time the routine returning the error code was compiled. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
gwyn@brl-smoke.ARPA (Doug Gwyn ) (08/30/87)
In article <865@percival.UUCP> nerd@percival.UUCP (Michael N. Galassi) writes: >...no "sysexits.h"... <sysexits.h> has nothing to do with error messages. As others have already explained, the "not a typewriter" syndrome is due to an inappropriate call to perror() when errno just contains the dregs of a much earlier test isatty() by the stdio package.
nerd@percival.UUCP (08/31/87)
> ... The error codes in <sysexits.h> have NOTHING WHATSOEVER to do with >the system call error codes in <errno.h>. <errno.h> is present on Microport >System V and any other system that 1) supports program development and 2) can >justifiably claim to be UNIX or derived therefrom. You are right indeed, I fell into the canyon. I don't know what I was thinking of when I posted (that may be my problem). I have used (corectly) both errno.h and sysexits.h in the past and should have had that info in mind. In any case, apologies to any who may have been misled by my garbage and many thanks to all those who took the time to corect me, either by mail or by posting here. very embarasedly, -michael