bug-sed
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#27200: sed happily modifies read-only files.


From: Bob Proulx
Subject: bug#27200: sed happily modifies read-only files.
Date: Sun, 11 Jun 2017 20:40:50 -0600
User-agent: NeoMutt/20170306 (1.8.0)

Péter wrote:
> sed happily modifies read-only files.
> *Modifying* *write-protected* files sound me contradicting..
...
> I would like sed to protect the user agains accidental modifications.
> You say, as already more-or-less stated, that sed never will.
> (If you are the only person who decides this), then sed most probably never 
> will indeed.

Let me take a completely different approach.  You may want this new
safety net.  And if 30+ years ago you were the person who was setting
up the -i option for perl way back in the day when perl created that
behavior then you could have programmed in this extra code for perl at
that time to be careful around read-only files.  I don't remember
exactly when but I know -i appeared in perl 4 in 1992 and so probably
existed much earlier.  And then many years later when sed and ruby
added the same feature that had previously been in perl then in those
programs it would have added the same behavior too.  But you weren't
there for it.  So it didn't happen that way.  Instead it went the
other way.  Instead it became an atomic update process of writing a
new file off to the side and then renaming it into place.

But that all happened literally *decades* ago.  For better or for
worse it is a terrible idea to change the behavior of programs when
that behavior has been that way for decades.  Whether you like it or
not after something has been in the foundation for decades then it
should remain that way.  Changes of that type are extremely
disruptive.

Also GNU sed isn't the only implementation.  There is also BSD sed and
others.  Plus perl.  Plus ruby.  Plus any other program that has
incorporated that same feature.  It is bad when the different
implementations have fundamentally different behavior.  And it is very
difficult to coordinate changes in behavior across such a large set of
programs so that they will all behave the same.

> I take cognizance of that, (will use sed less, and) we should close this 
> tread.

I simply suggest that if you don't like the perl, ruby and sed -i
option (I would mention other langauges here but those are off the top
of my head ) that you don't use the -i option.  Instead you can use a
temporary file and copy the output back to the original source.  Here
is a compact example.

#!/bin/sh
unset tmpfile
cleanup() {
  test -n "$tmpfile" && rm -f "$tmpfile" && unset tmpfile
}
trap "cleanup" EXIT
trap "cleanup; trap - HUP; kill -HUP $$" HUP
trap "cleanup; trap - INT; kill -INT $$" INT
trap "cleanup; trap - QUIT; kill -QUIT $$" QUIT
trap "cleanup; trap - TERM; kill -TERM $$" TERM
tmpfile=$(mktemp) || exit 1
sed s/foo/bar/g file1 >"$tmpfile"
cp "$tmpfile" file1 || exit 1
exit 0

This suffers from not being an atomic update of the file.  But if that
isn't a problem for you then this is a perfectly fine solution.  And
it will not change the inode of the original file.  It will not
overwrite files that are read-only.  This would seem to meet all of
your criteria.

Bob





reply via email to

[Prev in Thread] Current Thread [Next in Thread]