bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use (original) (raw)

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

From: Linda Walsh
Subject: bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call
Date: Tue, 19 Nov 2013 10:17:02 -0800
User-agent: Thunderbird

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.