Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!munnari!otc!metro!basser!john
From: john@basser.oz (John Mackin)
Newsgroups: comp.sources.bugs
Subject: Re: Compress error message
Message-ID: <1005@basser.oz>
Date: Wed, 26-Aug-87 00:49:59 EDT
Article-I.D.: basser.1005
Posted: Wed Aug 26 00:49:59 1987
Date-Received: Fri, 28-Aug-87 02:07:45 EDT
References: <339@cbstr1.att.com> <209@ho7cad.ATT.COM>
Reply-To: john@basser.oz (John Mackin)
Organization: Dept of Comp Sci, Uni of Sydney, Australia
Lines: 59
Summary: why "Not a typewriter"

In article <209@ho7cad.ATT.COM> nuucp@ho7cad.ATT.COM (UUCP) writes:

> In article <339@cbstr1.att.com> Karl.Kleinpaste@cbstr1.att.com writes:
> 
> >>	   Not a typewriter
> 
> 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]. 

Consider this example code:

main()
{
	perror("foo");
}

On many UNIX systems (I'm sure there are many exceptions, please don't
send me mail (or worse, post!) pointing out that yours is one of them)
this will indeed print ``foo: Not a typewriter'', if its output has
been redirected onto a file.  Why?  It certainly isn't because there
hasn't been an error.  The reason is that the standard I/O library
(on many, but by no means all, systems) makes the buffering of stdout
behave differently if it is attached to a terminal.  On some systems,
it then becomes unbuffered by default; others (e.g., 4.3BSD) have
line-buffering, which is used by default on stdout if it is a terminal.

Now, to determine if the standard output is a terminal or not, the
stdio initialization typically uses isatty().  And isatty() works by
applying a system call that only works on terminals (typically, gtty())
to the supplied file descriptor and seeing whether it fails or not.
Hence, any time isatty() is applied to a file descriptor that is not
a terminal, it has the side-effect of setting errno to ENOTTY, "Not
a typewriter".

Mr. Kleinpaste is indeed entitled to blame compress.  The real problem
here is that perror() is being used in an inappropriate manner.  Seventh
Edition intro(2) clearly states:

    Errno is not cleared on successful calls, so it should
    be tested only after an error has occurred.

The only time errno is valid is immediately after a system call (or
library routine whose manual states that it sets errno on error) has
returned an error indication.  In this case it would seem that that
is not the case.  Many programs are quite cavalier about their use of
errno, both directly and indirectly (e.g. via perror()), and this
can sometimes lead to very subtle bugs, as well as annoying and
confusing inappropriate error messages.

John Mackin, Basser Department of Computer Science,
	     University of Sydney, Sydney, Australia

john@basser.oz.AU (john%basser.oz@SEISMO.CSS.GOV)
{seismo,hplabs,mcvax,ukc,nttlab}!munnari!basser.oz!john

Copyright 1987 John J. Mackin.  Restricted redistribution prohibited.