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