[Top][All Lists]

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

sed "in-place" behavior and file permissions

From: James Walker
Subject: sed "in-place" behavior and file permissions
Date: Thu, 5 Sep 2013 18:05:14 -0400

I have read the info pages, and in particular the section about the `-i'

> `-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
>     on a temporary file that is finally renamed to the original name:
>     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. The
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

`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

$ 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
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: <address@hidden>.
Be sure to include the word ``sed'' somewhere in the ``Subject:'' field.

reply via email to

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