--- Begin Message ---
|
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
--- End Message ---
--- Begin Message ---
|
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.
--- End Message ---