Eric Blake wrote:
the discussion here is about an early exit
on an attempt to remove '.', which, contrary to your claim, appears to
always have been in POSIX as far as I can tell (and even if it has not
always been in POSIX, the fact that I can quote a 20-year-old document
that describes curre
On 02/21/2017 05:42 AM, Eric Blake 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), rm will
write a diagnostic message to standard error and do nothing more with
such operands."
The same wording is in the
On 02/21/2017 07:42 AM, Eric Blake wrote:
> On 02/21/2017 02:41 AM, L A Walsh wrote:
>>
>> Do you really need me to find the older version
>> of 'rm' in your source tree?
>
> It wouldn't hurt to point out which commit id changed behavior, if you
> indeed want to call that commit a regression.
On 02/21/2017 02:41 AM, L A Walsh wrote:
>
> Do you really need me to find the older version
> of 'rm' in your source tree?
It wouldn't hurt to point out which commit id changed behavior, if you
indeed want to call that commit a regression. Being able to read the
commit itself, as well as ma
Or are you arguing that contents within the directory should be removed,
even though the directory itself cannot be?
---
That's the way a recursive descent algorithm
works: it processes the contents, before the parents.
When it gets to the parent, it couldn't remove it, but
due to th
Eric Blake wrote:
tag 25817 needinfo
thanks
On 02/20/2017 01:41 PM, L A Walsh wrote:
So... why should 'rm' not be able to start it's deletion
from the inside of a directory? (@ "." )?
Please give more details as to what you think is broken. Instead of
describing the problem in vague prose
tag 25817 needinfo
thanks
On 02/20/2017 01:41 PM, L A Walsh wrote:
> So... why should 'rm' not be able to start it's deletion
> from the inside of a directory? (@ "." )?
Please give more details as to what you think is broken. Instead of
describing the problem in vague prose, please show a shel
In reading Gnu's Coding Standards (
https://www.gnu.org/prep/standards/standards.html#Non_002dGNU-Standards),
Under non-Gnu-Standards -- it is specifically talking about POSIX
compatibility when it says:
In particular, don’t reject a new feature, or remove an old one,
merely because a stand
