Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #11386 > unrolled thread

Re: -e does not take effects in subshell

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: -e does not take effects in subshell Linda Walsh <bash@tlinx.org> - 2015-08-18 15:31 -0700

#11386 — Re: -e does not take effects in subshell

Andreas Schwab wrote:
> Linda Walsh <bash@tlinx.org> 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.

[toc] | [standalone]

Back to top | Article view | gnu.bash.bug

csiph-web