GNU bug report logs - #20083
--follow-symlink shouldn't exists

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Nicolas Michel <be.nicolas.michel <at> gmail.com>
Subject: bug#20083: closed (Re: --follow-symlink shouldn't exists)
Date: Tue, 05 May 2015 04:54:02 +0000

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

Your bug report

#20083: --follow-symlink shouldn't exists

which was filed against the sed package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 20083 <at> debbugs.gnu.org.

-- 
20083: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20083
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Jim Meyering <jim <at> meyering.net>
To: 20083-done <at> debbugs.gnu.org, Nicolas Michel <be.nicolas.michel <at> gmail.com>
Subject: Re: --follow-symlink shouldn't exists
Date: Mon, 4 May 2015 21:52:57 -0700

tag 20083 notabug
thanks

> I'm a senior sysadmin. I realized recently that newest version of sed
> used with "-i" on a symlink would wipe the symlink and replace it by a
> plain file. Searching the net, I found some bug reports on some
> distros (bug 820149 on RedHat). And the bug has been "fixed" adding a
> --follow-symlink option. And the world seems to agree with it. I don't
> and I'll try to explain my point of view.
>
> sed is used to alter the __content__ of a file. I don't expect it to
> alter the permissions or the nature of the file itself (wich is not
> related to content but to file system). At best it can be harmless to
> the system. At worst, it can provokes system malfunction (try to "sed
> -i" /etc/grub.conf which is supposed to be a symlink of
> /boot/grub/grub.conf on a RHEL6).
>
> Adding --follow-symlink is:
> - only interesting when you know that sed -i replace a symlink by a
> file in the first place
> - only interesting if you know that this option exists
> - only interesting if you know in advance that the file you're suppose
> to change __is__ a symlink
> - is a lot of characters to type down
>
> It is a lot of conditions. The reality is that peoples usually don't
> realize it before a malfunction, and as I said.
>
> The last reason (and not the less) is that sed used not to alter a
> symlink in older releases!!!
>
> So:
> 1) because it is not the expected behavior of sed to change the nature of a file
> 2) because if can cause malfunction to the system
> 3) because --follow-symlink is a bad workaround
> 4) because it was not the behavior of sed in older releases
> I'm asking to suppress --follow-symlink (or keep it for compatibility
> purpose) and makes sed safe with the metadata and/or nature of a file
> (and keep a symlink a symlink).
>
> I hope you'll agree with my point of view ;)

Thanks for writing, but this is not a bug.
sed's --in-place (-i) option has always operated that way,
replacing a symlink with a regular file. GNU sed began providing
that option in October of 2002. The option was modeled after perl's
-i option, which also works that way.

You mention that typing the long option name, --follow-symlink,
is burdensome.  Fortunately, you can abbreviate it as "--fo".

I'm marking this auto-created "issue" as closed, but you're
welcome to continue the discussion.

[Message part 3 (message/rfc822, inline)]

From: Nicolas Michel <be.nicolas.michel <at> gmail.com>
To: bug-sed <at> gnu.org
Subject: --follow-symlink shouldn't exists
Date: Wed, 11 Mar 2015 14:54:25 +0100

Hello,

I'm a senior sysadmin. I realized recently that newest version of sed
used with "-i" on a symlink would wipe the symlink and replace it by a
plain file. Searching the net, I found some bug reports on some
distros (bug 820149 on RedHat). And the bug has been "fixed" adding a
--follow-symlink option. And the world seems to agree with it. I don't
and I'll try to explain my point of view.

sed is used to alter the __content__ of a file. I don't expect it to
alter the permissions or the nature of the file itself (wich is not
related to content but to file system). At best it can be harmless to
the system. At worst, it can provokes system malfunction (try to "sed
-i" /etc/grub.conf which is supposed to be a symlink of
/boot/grub/grub.conf on a RHEL6).

Adding --follow-symlink is:
- only interesting when you know that sed -i replace a symlink by a
file in the first place
- only interesting if you know that this option exists
- only interesting if you know in advance that the file you're suppose
to change __is__ a symlink
- is a lot of characters to type down

It is a lot of conditions. The reality is that peoples usually don't
realize it before a malfunction, and as I said.

The last reason (and not the less) is that sed used not to alter a
symlink in older releases!!!

So:
1) because it is not the expected behavior of sed to change the nature of a file
2) because if can cause malfunction to the system
3) because --follow-symlink is a bad workaround
4) because it was not the behavior of sed in older releases
I'm asking to suppress --follow-symlink (or keep it for compatibility
purpose) and makes sed safe with the metadata and/or nature of a file
(and keep a symlink a symlink).

I hope you'll agree with my point of view ;)

-- 
Nicolas MICHEL

Previous Next

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