perror - (was Re: redirecting output)

[2656-Daniel R. Levy00000000000]

henry at zoo.toronto.edu (Henry Spencer) writes:

>In article <JID4B=4 at ficc.ferranti.com> peter at ficc.ferranti.com (Peter da Silva) writes:
>>While picking nits, how about doing it right. There's really no excuse for
>>not calling perror...

>Yes there is:  it doesn't do what I want, which is a more informative
>message about the high-level nature of the problem.  A major reason why
>perror() doesn't get used is that it is simply too inflexible:  it takes
>too much extra work to put together a useful message, since that generally
>requires assembling an argument string out of pieces.  

Even worse, if it's done with what would seem the logical choice for
formatting strings, sprintf, depending on the stdio library (if it does
something silly like a write() to an illegal file descriptor) errno
might get altered before the call to perror().

>One often wants
>more information than just the filename and the error code.  Something
>like the Kernighan&Pike error() function is vastly more useful, but alas,
>not everyone has it.  If you're willing to rely on ANSI C facilities (or
>imitations of same, e.g. my old strings package), then strerror() can
>be used to get much the same effect.

Why lean on special functions?  It can be done simply and easily (at
least under UNIX environments) with a #define.

extern int errno;
extern int sys_nerr;
extern char *sys_errlist[];

#define sys_err		(errno < 0 || errno >= sys_nerr ? \
				"unknown error" : sys_errlist[errno])


	...
	if (stat(fname,&s) == -1) {
		(void) fprintf(stderr,"can't stat %s: %s\n",fname,sys_err);
		exit(1);
	}
	...
-- 
 Daniel R. Levy * Memorex Telex * Naperville IL * ..!uunet!tellab5!mtcchi!levy
So far as I can remember, there is not one      ... therefore be ye as shrewd
word in the Gospels in praise of intelligence.  as serpents and harmless as
-- Bertrand Russell [Berkeley UNIX fortune]     doves -- God [Matthew 10:16]