chris@mimsy.UUCP (Chris Torek) (09/23/88)
>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