cc: [EMAIL PROTECTED]
Subject: Re: Re: [ast-users] In-place file modification
--------
> The operator might act somewhat like &&> (although this already
> has another meaning). On the left of it, there is an implicit set -o
> pipefail, and on the right, the file is only created on success, and
> is guaranteed to have a different inum. That means a temporary file
> must be created first, and then on success, the old one gets unliked
> (possibly implicitly by rename).
>
>
> While my initial idea was to type less, I think similar mechanisms
> are also used to replace files that are potentially actively used: pages
> on a web server, binaries and shared libraries (although they probably
> do an additional backup step first -- but still, the file is replaced in
> one operation instantly). So the whole thing is like a transaction,
> and if the pipe failed, nothing happened (the old file is still there),
> it's "rolled back". And I could also easily check that by comparing
> the inum (say, if another process doesn't know the exit status).
> And I wouldn't have to worry about file locking, etc. -- that would
> be done without my knowing, if necessary.
>
>
The operator isn't the problem; I could choose >; which currently
would cause a syntax error. The problem is that there are several
issues that must be resolved in order for it to make sense consistently.
For example,
1. Should it work with device files and fifo's as well as
regular files.
2. What happens when it is used with exec, for example
exec 3>; foobar? When does foobar get replaced.
When I exit the script? When I close the file?
What exit status would decide whether to discard or save?
3. What happens if two redirections refer to the same file,
>; file 2>; file
4. Currently, the shell will just exec a command rather than
fork/exec when it is the last command. This is important
for case such as sh -c command was invoked by system(3).
However, something as simple as
foobar >; file
cannot be exec'd because it needs to either discard the
temporary file or replace it after foobar completes.
5. A similar problem exists with foobar >; file & because
the background process must do the cleanup at the end.
6. There might be timing problems in case such as
command1 file | command2 2>;file | command3 file
Which version of file does command 3 use?
I suspect that these are solvable problems. I just
want to point out some of the complexities that are involved.
If adding it aids users by simplifying programs, it might well be worth it.
I would like to hear more from users on whether they would
find this useful.
David Korn
[EMAIL PROTECTED]
_______________________________________________
ast-users mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-users
