bug-bash
[Top][All Lists]
Advanced

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

Re: -e does not take effects in subshell


From: Linda Walsh
Subject: Re: -e does not take effects in subshell
Date: Tue, 18 Aug 2015 15:31:10 -0700
User-agent: Thunderbird



Andreas Schwab wrote:
Linda Walsh <address@hidden> writes:

Ex: rmx -fr (alias to rm --one-file-system -fr, since rm lacks the
-x switch like 'find, cp, mv, et al.) no longer works to clean
out a directory && stay on *one* file system.

Now rm will delete things on any number of file systems, as long
as they correspond to a cmdline argument.

That's the only sensible way to implement it.  Which, incidentally,
works exactly like find -xdev.
---
with 'find', you can specify -xdev with a starting path of "."

with 'rm' functionality to remove '/' '.' and '..' was prohibited
by POSIX, though the coreutils version still allows the choice of the more dangerous removal of '/' with with the --[no-]preserve-root.

But the more useful "rm -fr ." or the variant "rm -fr dir/." so you know you are removing the contents of "dir", no matter where or what
"dir" is... with find, that doesn't work -- if 'dir' is a symlink
to /tmp/dir/.., find won't remove anything. Any other solution from POSIX added complication. I was told by a BSD fanatic that 'rm'
was changed because after the SysV companies left POSIX (as most of
them had disappeared), BSD'ers gained a majority and could redirect
the standard as they pleased.  Disallowing students playing around with
"rm -fr {/,dir/,}{.,..}" apparently was a big thing @Berkeley.  Being
able to force the removal of such options from everyone's "rm" was
an huge win, they considered (this is from a discussion w/one fanatic, but boy, was it memorable). Disallowing any option or ENV(POSIX_CORRECTLY)
option to "re-allow" the feature has been continuously shot down by
'rm' maintainers (even though they keep in their own alias-able switches
to all removal of '/').
Now please explain what this has anything to do with POSIX.


 It apparently was the POSIX 2008 standard that prohibited the historical
behavior (on linux -- removed dir contents, and failed on current-dir
because it made no sense -- but did so *quietly* and after following
the depth first design.



reply via email to

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