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

[Linda Walsh]

On 19/11/2013 04:15, Pádraig Brady wrote:
> tag 15926 notabug
> close 15926
> stop
>
> On 11/19/2013 11:56 AM, Linda Walsh wrote:
> > Since there is already an unlink command that corresponds to unlinking a file,
> > but there seems to be no command corresponding to the POSIX
> > remove command, it seems upgrading 'rm' to use the 'remove'
> > POSIX call would be a beneficial move of all the recent POSIX
> > changes.
> >
> > So how about upgrading 'rm' to use the remove function so
> > it would work on empty directories as well.
>
> Well we have the -d option to rm to explicitly do that.
---
Does the posix "remove" call require a -d?

I thought it made more sense to have rm correspond to remove
than create another command called remove that called remove.

Are you saying that you think it would be better to have a remove command
that does this?

As for the posix document you pointed at, I'm suggesting doing step 4
after step 1... same thing posix does, just reordering things a bit.

This came up, BTW, because a useless error message was added to find
such that if you used find dir/. -type d -empty -delete, it now exits with
an error status telling you nothing. other than it didn't delete the "."
entry from inside the dir (which most people know can't be done anyway).
But now there is no way to determine if the find command failed, or if it
is just making noise over things it never has done.

Alternatively, I suggested adding a -f flag that would occur, positionally
before any path arguments (like the -H/-L/-P opts now), that would silence
such fails and return a 0 status for delete failures that the OS cannot
do.

No useful purpose is served by the new error message, and creating it breaks
compatibility with scripts.