Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!spool.mu.edu!agate!dog.ee.lbl.gov!elf.ee.lbl.gov!torek
From: torek@elf.ee.lbl.gov (Chris Torek)
Newsgroups: comp.unix.shell
Subject: Re: cat, pipes, and filters
Keywords: cat pipe filter
Message-ID: <13798@dog.ee.lbl.gov>
Date: 1 Jun 91 13:40:15 GMT
References: <1991May31.165446.1530@progress.com> <16438@darkstar.ucsc.edu>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 27
X-Local-Date: Sat, 1 Jun 91 06:40:15 PDT

>In article <1991May31.165446.1530@progress.com> root@progress.COM
>(Root of all Evil) writes:
>>    cat $FILE | sed s/"$ENTRY"/"$NEWENTRY"/ | tee $FILE 1>/dev/null

In article <16438@darkstar.ucsc.edu> jik@cats.ucsc.edu [ucsc?!]
(Jonathan I Kamens) writes:
>In this case, cat gets started and opens the file in order to read it, and
>*then* tee gets started, sees that it's supposed to send output to $FILE, and
>opens the file and truncates it in preparation for sending output to it.  Once
>cat has opened the file for read, it gets to read it, because the file that
>tee is sending output to is (in effect) a "different file" from the kernel's
>point of view.

Although the two processes hold different file table entries, they use
the same vnode and hence this is not a reliable way of doing things.
Depending on O/S vagaries, cat might read some, all, or none of $FILE
before tee truncates it; when tee truncates $FILE, anything cat has not
yet read will vanish forever.

As it happens, on most Unix boxes cat will run long enough to get the
first `block' (however big a block is, typically 8K under 4BSD-
derivative file systems) before sed will run, and sed will run long
enough to wait for cat before tee will run.  It is unwise to depend
on this.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov