Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!seismo!mcvax!ukc!stc!root44!aegl From: aegl@root44.UUCP Newsgroups: comp.unix.questions Subject: Re: File descriptors Message-ID: <349@root44.co.uk> Date: Wed, 27-May-87 08:46:46 EDT Article-I.D.: root44.349 Posted: Wed May 27 08:46:46 1987 Date-Received: Fri, 29-May-87 05:10:18 EDT References: <2532@ncoast.UUCP> <5875@brl-smoke.ARPA> <1673@tekcrl.TEK.COM> <5881@brl-smoke.ARPA> Reply-To: aegl@root44.UUCP (Tony Luck) Organization: Root Computers Ltd, London, England Lines: 35 In article <5881@brl-smoke.ARPA> gwyn@brl-smoke.ARPA (Doug Gwyn) writes: >The only reason there are two such tables rather than one is to permit >the sharing of the file position pointer across a fork. I don't see >the necessity for this particular characteristic (I can't recall >ever having made use of it), so as far as I'm concerned there might >as well be only one open-file table. You *must* have used this ... consider about what happens when you have a shell script like this: $ cat hello.sh /bin/echo "Hello" /bin/echo "world" and you run it with output redirected to a file. $ ./hello.sh >outputfile Your shell opens/creates "outputfile", truncates it, does tricks with dup() to make sure it is file descriptor 1. The file pointer for stdout is now 0. The shell forks and execs the first "echo" this outputs "Hello" - and the file pointer for stdout is set to 6 (5 chars in "Hello" + newline). Then echo exits and the shell wakes up and execs the next echo. If the file pointer hadn't been shared across the fork/exec then the shell would still have it set at 0 - so the "world" would get written on top of the "Hello". Luckily (for every shell script that ever ran more than one program that produced any output) the pointer was shared so the "world" starts at byte offset 6 in "outputfile". $ cat outputfile Hello world Tony Luck - Technical Manager, Root Computers Ltd.