bug-gnulib
[Top][All Lists]
Advanced

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

Re: ensure that generated files are read-only


From: Simon Josefsson
Subject: Re: ensure that generated files are read-only
Date: Thu, 07 Sep 2006 16:24:57 +0200
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux)

Bruno Haible <address@hidden> writes:

> 1) For the user who unpacks and builds a package.
>    When he wants to remove the package, he will do "rm -r coreutils-6.2".
>    This will start asking questions. So he types Ctrl-C, and does
>    "rm -rf coreutils-6.2". And next time he will possibly use "rm -rf"
>    to avoid the problem.
>
>    But "rm -rf" removes anything, without safety measures. If he makes
>    a typo, he is hosed!
>
>    So by declaring some files read-only, you are degrading the safety
>    of users because they get accustomed to "rm -rf".
>
>    In other words, IMO, the read-only status should be reserved to
>    precious files.

A further rant on that theme: I've been annoyed more than once that
automake 'distcheck' chmod parts of the FOOPKG-x.y.z/ directory as
read-only.

Further, it even chmod directories as read-only as well, so that not
even 'rm -rf' works!

address@hidden:~/src/libidn$ make distcheck
...
^C
address@hidden:~/src/libidn$ rm -rf libidn-0.6.6
rm: cannot remove `libidn-0.6.6/contrib/doxygen/Doxyfile.in': Permission denied
rm: cannot remove `libidn-0.6.6/contrib/doxygen/Doxyfile.orig': Permission 
denied
rm: cannot remove `libidn-0.6.6/contrib/doxygen/gdoc2doxygen': Permission denied
rm: cannot remove `libidn-0.6.6/contrib/idn-python/README': Permission denied
rm: cannot remove `libidn-0.6.6/contrib/idn-python/Makefile': Permission denied
rm: cannot remove `libidn-0.6.6/contrib/idn-python/idn.c': Permission denied
rm: cannot remove `libidn-0.6.6/contrib/idn-python/test.py': Permission denied
rm: cannot remove `libidn-0.6.6/contrib/java/README': Permission denied

That is time-consuming to restore; I usually do 'sudo rm -rf
libidn-0.6.6', which is an even worse habit than 'rm -rf'...

Sigh.

/Simon




reply via email to

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