Path: utzoo!utgpu!watmath!clyde!ima!minya!jc
From: jc@minya.UUCP (John Chambers)
Newsgroups: comp.unix.wizards
Subject: Re: Weird Problem with cat
Message-ID: <134@minya.UUCP>
Date: 20 Nov 88 16:18:53 GMT
References: <41@eplrx7.UUCP>
Organization: (none)
Lines: 34

In article <41@eplrx7.UUCP>, mcneill@eplrx7.UUCP (mcneill) writes:
> 
> As superuser on one of our machines I have this problem sometimes:
> 
> eplrx7 {root} % cat ~mcneill/.login
> cat: write error bad file number
> 
Hey, an excuse to post one of my favorite flames:  Once again, some
turkey programmer wrote an application that produced an error message,
and didn't say what caused the error.  The program could have given
more details, and perhaps the info would have helped track down the
problem.  For instance, suppose the error had been:
>	cat: write error bad file number 65537="/tmp/fubar"
telling us that the program had thought it was accessing /tmp/fubar,
and the variable containing the file number got garbaged.  When passed
on to the vendor's support people, it would give some hints as to where 
the problem lies.  Just saying "bad file number" isn't very helpful.

It's especially annoying to be told that a program failed because of
"Permission denied", and not be told what the problem is.  Knowing the
name of a file it was trying to open (or exec) will usually, after a 
quick "ls -l" or "ls -ld", lead to an explanation.  Without the file
name, it's often hopeless.

How can we get programmers to do this right?  It isn't difficult.
Or perhaps we should be hitting on the QA people, and let them know
how shoddy we think their product is if it won't even tell us why
it is failing.  Any ideas?

-- 
John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)

[Any errors in the above are due to failures in the logic of the keyboard,
not in the fingers that did the typing.]