connectivity

[jc at trillian.mit.edu (John Chambers)]

kb wrote:
| John Chambers <jc at trillian.mit.edu> wrote:
| >: chkconfig telnet on
| >error reading information on service telnet: No such file or directory
| >
| >Doesn't seem to have worked on this 2.2.13-0.7 (Red Hat) box.  I also
| >note it commits one of the traditional sins of bad software: It tells
| >me that it can't open something, but it doesn't deign to tell me what
| >the file name was.
|
| When I plunged into Linux, I left behind the idea that I was running
| my Macintosh.  What are you trying to do to me?  And Apple is no
| better, they released the new Ibook which looks very nice, and I can
| even run a Unix on such a box.
|
| Seriously, I used to think Unix should be more friendly, but haven't
| had the energy to open that subject of late.

Hmmm ...  I hadn't thought this could be taken as a comment  on  unix
software. I've found that, common as such unfriendliness is with unix
software, it's even worse on any other sort of system that I have  to
use.   With  Mac  software,  I've  found the error messages supremely
worthless, because they seem to have used the  philosophy  that  they
shouldn't  trouble my little mind with any technical information that
might lead to a solution.  I wouldn't understand anyway, you know, so
its  best  if  they tell me something that is vaguely comforting.  MS
software, of course,  just  says  something  that  sounds  like  it's
informative, but in fact isn't, because there's no way that I can use
the "information" to fix anything.  Sorta like  the  old  joke  about
"Where am I?" "You're in a helicopter."

Complaining about unix software is very often  more  useful,  because
there's  a fair chance that someone will listen, and will know enough
about the particular program(s) to either suggest something useful or
go  in  and  hack  a solution.  In any number of cases, I've done the
hacking myself, hunting down the error message and adding  a  %s  and
file  name  to  it  and recompiling.  But this can take an inordinate
amount of time, and it doesn't affect the reaction when hit with  yet
another program that gives a clueless message like the above.

Actually, the cause of the above message is something that  I've  had
many occasions to go on tirades about: It was almost certainly from a
call of perror().  This routine was a major mistake, because it  only
allows  the  errno message to be combined with a constant string, and
has no provision for passing along useful information like  the  file
name that got the error.  I almost never use it. It doesn't take many
more characters to type fprintf(stderr,...), and then  you  can  give
useful information.  But I've seen far too many cases where perror is
used because "it's standard".  Maybe, but anyone interested in making
their  software user friendly would ban its use.  Most of my fixes to
problems like this have been to replace perror() with fprintf(). Then
I  rerun the command, it tells me the name of the file, and I stand a
chance of fixing the problem.

-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).