bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call

[Linda Walsh]

On 19/11/2013 10:34, Eric Blake wrote:
> On 11/19/2013 11:17 AM, Linda Walsh wrote:
>
> >> Well we have the -d option to rm to explicitly do that.
> > ---
> > Does the posix "remove" call require a -d?
>
> Huh? There is no POSIX remove(1),
----
Since when do you think of a "call" as being a command?
> Sorry, but to change that, you'd have to go back in time 30 or 40 years
> to when rm(1) was first written.  People have grown to rely on 'rm(1)'
> being a wrapper around unlink(2), 'rmdir(1)' being a wrapper around
> rumdir(2), and 'rm(1) -R' being a wrapper around rmdir(2) or unlink(2)
> as needed.
----
   People relied on rm removing files in a depth first search order for 30-40 
years.

Posix changed that requiring special checks for ".".  Scripts relied on that 
behavior
for 30-40 years as well...  If you want to use that reasoning, rm should go back
to doing depth first deletion and reporting an error with deleting "." when it
is finished.


> Sorry, but doing things in rm(1) in a different order than POSIX
> describes would lead to subtle breakage to lots of existing scripts.
----
   I claim not.  Come up with 1 case where scripts rely on the current
behavior -- to "die" before doing anything useful, vs. the pre-existing
behavior which was to issue an error (suppressible with "-f") on the
final deletion failing.

   I am calling your bluff -- show me the scripts (other than a posix
conformance test script), that would fail -- subtly or otherwise.

   I assert they don't exist for 2 reasons.  The foremost being
that working scripts cannot rely on upon the deletion failure
stopping any useful work being done by the command.  The 2nd
being it was a new change in posix  that appeared in gnu utils
in only the past few years.  The previous 25-35 years of scripts
would have relied on it working as *documented* (depth first).

Checking pathnames before you start depth first traversal is not
strictly depth first. 

By your own standards for not changing something, "rm" should
be fixed to be the way it was for 30-40 years, as.

The problem is, is that by implementing that change, functionality
was lost and removed in "rm".   The earlier version had more
functionality.  So you can't come up with scripts that rely on
missing functionality to get things done.  It's like relying on
missing water to water your plants or missing food to feed yourself.

You can't rely on the absence of a feature to do something positive
with it.