[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#27200: sed happily modifies read-only files.
From: |
Péter |
Subject: |
bug#27200: sed happily modifies read-only files. |
Date: |
Thu, 8 Jun 2017 21:04:58 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 |
You (how many of you?) are stating that the file's write permission bits are meaningless (purpose-less) in case the
enclosing directory's write permission bits are on.
This does *not* seem to be the case, as it is a *fact* that (with only sed and perl as exceptions when using them for
"in-place" editing) all programs do respect that bit. In case of vim: "When the 'cpoptions' option contains 'W', Vim
will refuse to overwrite a readonly file." So even the "!" is not available.
You argue with the unix-like files system permission system.
I have nothing to do with that. I know it perfercly (enough, regarding the
write-enable bits).
Whether programs use backup files, swap files, temporary files, and only when writing out, gets the file written out, is
an internal detail, which is only the program's business. Even the inode number seems to be "does not matter". For
example, my vi changes the inode of the file, at each writing-out.
It seems that you do not understand (do you have the will?) the difference between "protect against accidental
modification" and "protect against any modification".
Accidental change means "in just 1 line", "via just a call":
prg myfile
If the user issues a chmod before, then (if the file changes) it was not
accidental change:
chmod u+w myfile
prg myfile
If the user issues creating new file, copying contents, copying permissions, deleting, renaming, then it definitely was
*not* an accidental change:
cat >...
unlink ...
mv ...
prg myfile
(optionally) chmod ...
Protecting agains accidental changes means that the *user* has to issue at least one (plus) (enabling) command (or
"--force" option, or "!" in some cases in vi) before/when calling the prg.
I would like sed to protect the user agains accidental modifications.
You say, as already more-or-less stated, that sed never will.
(If you are the only person who decides this), then sed most probably never
will indeed.
I take cognizance of that, (will use sed less, and) we should close this tread.
Bye.
- bug#27200: sed happily modifies read-only files., Péter, 2017/06/02
- bug#27200: sed happily modifies read-only files., Assaf Gordon, 2017/06/02
- bug#27200: sed happily modifies read-only files., Péter, 2017/06/06
- bug#27200: sed happily modifies read-only files., Bob Proulx, 2017/06/06
- bug#27200: sed happily modifies read-only files., Péter, 2017/06/07
- bug#27200: sed happily modifies read-only files., Assaf Gordon, 2017/06/07
- bug#27200: sed happily modifies read-only files., Davide Brini, 2017/06/07
- bug#27200: sed happily modifies read-only files.,
Péter <=
- bug#27200: sed happily modifies read-only files., Bob Proulx, 2017/06/11