From owner-freebsd-hackers Thu May 2 21:14:20 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA21979 for hackers-outgoing; Thu, 2 May 1996 21:14:20 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA21965 for ; Thu, 2 May 1996 21:14:11 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id NAA14153; Fri, 3 May 1996 13:59:26 +1000 Date: Fri, 3 May 1996 13:59:26 +1000 From: Bruce Evans Message-Id: <199605030359.NAA14153@godzilla.zeta.org.au> To: freebsd-hackers@freebsd.org, jmacd@deceit.xcf.berkeley.edu Subject: Re: stdio problem Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > close(0); > if(!freopen(argv[1], "r", stdin)) { This fails because freopen() gets its plumbing tangled in an attempt to support freopen()ing /dev/stdin. It's not clear if this is required to work. ANSI doesn't apply since close() isn't in ANSI, and POSIX has about 4 pages of rules that I don't completely understand (the rules are mostly about unavoidable interactions, e.g., for i/o done on the fd's by a child process, and not about abusing close() when fclose() would work). >is "wrong". The pracical application here is that if you close 0 >and then exec GNU diff3 you'll encounter this problem. This is a completely different situation. The stdio streams before exec are only related to the stdio streams after exec by the implicit fdopen()s of the first 3 file descriptors. FreeBSD's stdio apparently gets these fdopen()s wrong by statically initializing the FILE structs. This fails if any of the descriptors is closed or has abnormal access flags. If STDIN_FILENO is closed, then the state is similar to the one for closing STDIN_FILENO without telling stdio, and freopen() fails for the same reason. >Is it legal >to close your standard input and then fork/exec other programs? Yes. Of course, many programs won't be able to handle this. Bruce