|
From: | Linda Walsh |
Subject: | bug#21084: rm appears to no longer be POSIX compliant (as of 2013 edition) re: deleting empty dirs and files under <path>/. |
Date: | Fri, 31 Jul 2015 16:56:54 -0700 |
User-agent: | Thunderbird |
Linda Walsh wrote:
Andreas Schwab wrote:"If either of the files dot or dot-dot are specified as the basename portion of an operand (that is, the final pathname component) or if an operand resolves to the root directory, rm shall write a diagnostic message to standard error and do nothing more with such operands."---- I'll grant it also says you can't remove "/",So a special flag "--use_depth_first_inspection" that says not to look at a "basename" until it's children have been processed wouldn't be any more out of place than special flags to handle "/" processing, right?The fact that they put the ".", ".." and "/" together, outside ofthe 1-4 processing leads one to the idea that they should be treated similarly,no?
--- Since there is no opposition to this, I presume, all you need now is a patch?I.e. - POSIX now demands that "/", "." and ".." all be ignored in a basename,
yet the some smart gnu folks decided that leaving in a non-default optional behavior to override the new dumb-down restrictions would best serve the community. So I might reason that they would be equally smart and/or use similar logic to allow a non-default option to remove the dumb-down on the "." path. NOTE: I have no issue with NOT _attempting_ a delete on "." after doing the designed depth-first traversal. Applying the POSIX restriction on not attempting to delete "." makes perfect sense to me, since I know that doing so can give inconsistent and "undefined" behavior depending on the OS, but using "." as a semantic place holder to allow one to reference a starting point for some action (imagine using 'find' if '.' was banned as starting point: > find '' -type f find: ‘’: No such file or directory *cheers*
[Prev in Thread] | Current Thread | [Next in Thread] |