Xref: utzoo comp.unix.questions:9352 comp.bugs.4bsd:1014
Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uflorida!haven!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.questions,comp.bugs.4bsd
Subject: command >&-, and writing on closed descriptors
Message-ID: <13693@mimsy.UUCP>
Date: 22 Sep 88 18:01:58 GMT
References: <8488@smoke.ARPA> <26090@ucbvax.BERKELEY.EDU> <1049@sybase.sybase.com> <813@philmds.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 33

>In article <8541@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn) writes:
[command >&-, run from sh or ksh, but not csh]
>>... In particular, an error will occur when output is attempted to fd#1.

In article <813@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes:
>Yes, that would be the result to be expected, wouldn't it? ... [but]
>the following program behaved OK (look Ma, no core!):

>      printf("stdout: %d\n",i); fflush(stdout);
>      fprintf(stderr,"stderr: %d\n",i); fflush(stderr); /* not really needed */
[leading and end deleted, but these are the major `working lines']

And, if you had added error checking:

	if (ferror(stdout))

or

	if (printf("stdout: %d\n", i) < 0)

it would have triggered, since the output did in fact fail (with
EBADF).  Note the error will not occur until after an attempt to flush
stdio's buffer.  For line-buffered or unbuffered output files, that
would be after printing a newline or immediately; for others, after
printing enough text, or after an fflush (which will also return an
error).

As lint would say:

	fflush returns value which is always ignored
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris