bug#19051: rm symboliclink/ # "Is a directory"

[Linda Walsh]

Eric Blake wrote:
> Still, my point remains when you use 'rm -r b/': on Linux, it fails
----
   (so does 'rm -r b@' as a symlink to a file). 

   The linux way to address the directory has been "rm -r b/." POSIX 
blocked the linux
way of addressing the directory in rm, though, for example, it still 
works in
'cp': "cp -rl b/. a/." correctly makes links in 'a/.' of 'b/.' files.  
But it doesn't see the "." in
a and fail to execute normally.  In fact, attempting that copy isn't 
even an error in 'cp'/,
even though.   "b/." is a symlink to "a/."

   This came up before with symlinked targets and 'rm' and supposedly 
core utils would
always attempt a dir-op with "/" appended, but try a symlink-op w/o it.

Linux is behaving consistently, in that "rm" applies to symlinks, not 
the targets.

On linux to address the content of a directory, "dir/." has generally 
been used, but
as you mention below, POSIX intentionally violated the linux behavior in 
its 2008 update.
I.e. the linux behavior was prsent long before POSIX was changed to 
prevent the linux
addressing strategy

  
> (cannot remove 'b/': Not a directory), on Solaris it succeeds at
> removing 'a' and leaving 'b' dangling.
>
> The fact that Linux intentionally violates POSIX on some of the corner
> cases related to symlinks to directories makes it harder to definitively
> state what coreutils should do.
>   
---
Posix semantics changing away from the original POSIX standard break the 
"portability"
aspect of the POSIX, and, are hard to take seriously as being a 
portability standard when it
can't even maintain standards between it's own versions.  Given the 
relative number of users
of the various *nix's, It sorta looks like POSIX is attempting to wag 
the dog.

I strongly question the logic in linux following some minority standard 
when the largest
user base is likely to be used to the linux behavior.