James Walker
2013-09-05 22:05:14 UTC
I have read the info pages, and in particular the section about the `-i'
quoted has convinced me of why it is not an operating system bug; it
is a `sed' bug. I understand why it is possible for it to behave the
way it does. But just because `sed' can do something does not mean it
should.
`sed' should examine the file's permissions and if it is not writable
and there is no backup suffix specified, `sed' should fail. This
behavior would be more reasonable than the current behavior. It is
irrelevant that the current behavior is a natural consequence of the
Unix filesystem rules. It is unexpected that an operation purported to
be `in place' can affect a read-only file. `sed' should take the extra
steps to avoid surprising users in this case.
At least update the man page, please!
Thank you for your time
-James
$ sed --version
GNU sed version 4.2.1
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE,
to the extent permitted by law.
GNU sed home page: <http://www.gnu.org/software/sed/>.
General help using GNU software: <http://www.gnu.org/gethelp/>.
E-mail bug reports to: <bug-gnu-***@gnu.org>.
Be sure to include the word ``sed'' somewhere in the ``Subject:'' field.
`-i' clobbers read-only files
In short, `sed -i' will let you delete the contents of a read-only
file, and in general the `-i' option (*note Invocation: Invoking
sed.) lets you clobber protected files. This is not a bug, but
rather a consequence of how the Unix filesystem works.
The permissions on a file say what can happen to the data in that
file, while the permissions on a directory say what can happen to
the list of files in that directory. `sed -i' will not ever open
for writing a file that is already on disk. Rather, it will work
if you rename or delete files, you're actually modifying the
contents of the directory, so the operation depends on the
permissions of the directory, not of the file. For this same
reason, `sed' does not let you use `-i' on a writeable file in a
read-only directory, and will break hard or symbolic links when
`-i' is used on such a file.
I'm curious if you have considered that this is still a bug. TheIn short, `sed -i' will let you delete the contents of a read-only
file, and in general the `-i' option (*note Invocation: Invoking
sed.) lets you clobber protected files. This is not a bug, but
rather a consequence of how the Unix filesystem works.
The permissions on a file say what can happen to the data in that
file, while the permissions on a directory say what can happen to
the list of files in that directory. `sed -i' will not ever open
for writing a file that is already on disk. Rather, it will work
if you rename or delete files, you're actually modifying the
contents of the directory, so the operation depends on the
permissions of the directory, not of the file. For this same
reason, `sed' does not let you use `-i' on a writeable file in a
read-only directory, and will break hard or symbolic links when
`-i' is used on such a file.
quoted has convinced me of why it is not an operating system bug; it
is a `sed' bug. I understand why it is possible for it to behave the
way it does. But just because `sed' can do something does not mean it
should.
`sed' should examine the file's permissions and if it is not writable
and there is no backup suffix specified, `sed' should fail. This
behavior would be more reasonable than the current behavior. It is
irrelevant that the current behavior is a natural consequence of the
Unix filesystem rules. It is unexpected that an operation purported to
be `in place' can affect a read-only file. `sed' should take the extra
steps to avoid surprising users in this case.
At least update the man page, please!
Thank you for your time
-James
$ sed --version
GNU sed version 4.2.1
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE,
to the extent permitted by law.
GNU sed home page: <http://www.gnu.org/software/sed/>.
General help using GNU software: <http://www.gnu.org/gethelp/>.
E-mail bug reports to: <bug-gnu-***@gnu.org>.
Be sure to include the word ``sed'' somewhere in the ``Subject:'' field.