GNU bug report logs - #49287
sed -i disrespects read-only

Previous Next

To reply to this bug, email your comments to 49287 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Leonid Mironov <lvm <at> royal.net>
To: bug-sed <at> gnu.org
Subject: sed -i disrespects read-only
Date: Wed, 30 Jun 2021 08:01:13 +0200

[Message part 1 (text/html, inline)]

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Davide Brini <dave_br <at> gmx.com>
To: bug-sed <at> gnu.org
Subject: Re: bug#49287: sed -i disrespects read-only
Date: Thu, 1 Jul 2021 15:22:07 +0200

On Wed, 30 Jun 2021 08:01:13 +0200, Leonid Mironov <lvm <at> royal.net> wrote:

>    Hello,
>
>    sed disrespects read-only file attributes when editing in place.
>
>    $ ls -l testfile*
>    -r--r--r-- 1 lvm lvm 50 Jun 30 08:32 testfile
>    $ sed 's/test/bug/g' -i~ testfile
>    $ diff testfile testfile~
>    2c2
>    < this is a bug
>    ---
>    > this is a test
>    $ sed --version
>    sed (GNU sed) 4.4

Well tecnically this is correct since sed never writes to the
original file, instead it creates a new file, writes to it and finally
renames it to the old name, so the original file permissions never come
into play (in case you're wondering: it's not really "in-place").

I agree it could be surprising, but once you know how it works behind
the scenes it should make a bit more sense.

--
D.

Message #11 received at 49287 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Davide Brini <dave_br <at> gmx.com>, 49287 <at> debbugs.gnu.org,
 Leonid Mironov <lvm <at> royal.net>
Subject: Re: bug#49287: sed -i disrespects read-only
Date: Wed, 4 Aug 2021 15:17:50 -0600

tag 49287 notabug
close 49287
stop

Hello,

On 2021-07-01 7:22 a.m., Davide Brini wrote:
> On Wed, 30 Jun 2021 08:01:13 +0200, Leonid Mironov <lvm <at> royal.net> wrote:
> 
>>     sed disrespects read-only file attributes when editing in place.
>>
> 
> Well tecnically this is correct since sed never writes to the
> original file, instead it creates a new file, writes to it and finally
> renames it to the old name, so the original file permissions never come
> into play (in case you're wondering: it's not really "in-place").
> 
> I agree it could be surprising, but once you know how it works behind
> the scenes it should make a bit more sense.
> 

Thank you Davide for answering.

I would like to emphasize that this should *not* be surprising,
as it the way UNIX file and directory permissions have always worked -
this has nothing to do with sed.

Please see similar (and more detailed) discussion about it here:
  https://lists.gnu.org/archive/html/bug-sed/2017-06/msg00000.html

Please see here for in-depth examples of how "in-place" is not so trivial:
  http://www.pixelbeat.org/docs/unix_file_replacement.html



regards,
 -assaf

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.