Weird Problem with cat

[Michael "Ford" Ditto]

In article <360 at stca77.stc.oz> peter at stca77.stc.oz (Peter Jeremy) writes:
>In article <134 at minya.UUCP> jc at minya.UUCP (John Chambers) writes:
>>It's especially annoying to be told that a program failed because of
>>"Permission denied", and not be told what the problem is.
>
>This leads one into the area of whether you want a secure system or
>a friendly/usable one.  If you want a really secure system, you don't
>want to tell the users what went wrong, because if they were permitted
>to do it, they wouldn't have gotten the message.  If they are violating
>security, any information you give them might help them to get around
>the security system.

Although you are right in the particular example of "Permission denied",
I think the original complaint was about error reporting in general,
not reporting of security violations.

This is a particular pet peeve of mine, and I always make it a point
to call perror() with the name of the program, and a description of
the operation that failed.  A *minimal* error message should be
something like:

	$ cat foo
	cat: can't open "foo": Permission denied

yet, on many systems, the above command would print out

	foo: Permission denied
or
	cat: can't open input.
or
	cat: Permission denied,

none of which is very useful, and some of them can be quite misleading.
The first message, for example, seems to be from a program called "foo",
and the last one makes it appear that the user doesn't have permission
to run the cat program.
-- 
					-=] Ford [=-

"The number of Unix installations	(In Real Life:  Mike Ditto)
has grown to 10, with more expected."	ford at kenobi.cts.com
- The Unix Programmer's Manual,		...!sdcsvax!crash!elgar!ford
  2nd Edition, June, 1972.		ditto at cbmvax.commodore.com