Xref: utzoo comp.unix.shell:2345 comp.protocols.nfs:2421
Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!seismo!dimacs.rutgers.edu!rutgers!modus!otello!gear!am!alex
From: alex@am.sublink.org (Alex Martelli)
Newsgroups: comp.unix.shell,comp.protocols.nfs
Subject: reading an unlinked file (was: cat, pipes, and filters)
Message-ID: <1991Jun04.224044.1971@am.sublink.org>
Date: 4 Jun 91 22:40:44 GMT
References: <1991May31.165446.1530@progress.com> <10918@chorus.fr>
Organization: Premiata Famiglia Martelli & Figli
Lines: 26

bp@chorus.fr (Bruno Pillard) writes:
	...
:What about:
:  ( /bin/rm $FILE ; sed  s/"$ENTRY"/"$NEWENTRY"/ > $FILE ) < $FILE
:I understand that this may look harmful at first glance because of the
:/bin/rm of your precious file but it  works perfectly for  me under sh
:and (t)csh.
:
:Is there any problem using that construction ?

Normal Unix semantics, when a file is opened for reading (from the
outer shell, via the '<' redirection) and then unlinked (by the rm),
is that the file's directory entry is removed, but its contents are
still available to the process reading it; when it's finally closed,
assuming the link removed was the last one, its space will be reused.

If, however, $FILE stands in for a file remotely mounted in such a
way that usual semantics are not necessarily preserved (I'm thinking
of NFS), then I'm afraid you might lose it, if it's large enough not
to have been entirely read at the moment it's rm'ed.  I can't test
here at home, and I hope somebody will show why this is wrong, but...
-- 
Alex Martelli - (home snailmail:) v. Barontini 27, 40138 Bologna, ITALIA
Email: (work:) martelli@cadlab.sublink.org, (home:) alex@am.sublink.org
Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434; 
Fax: ++39 (51) 366964 (work only), Fidonet: 2:332/407.314 (home only).