Jim Meyering wrote:
> [EMAIL PROTECTED] (James Youngman) wrote:
> > On Thu, Jun 23, 2005 at 08:45:05PM +, Eric Blake wrote:
> >> This puts the invocation of rm without arguments in the
> >> implementation's realm, where currently, coreutils is not consistent
> >> on what it returns:
Without be
[EMAIL PROTECTED] (Eric Blake) writes:
> is it worth bringing this up with the austin group?
Probably not; I doubt whether they'd change the spec.
> Is it worth changing rm to be consistent in its status regardless of
> options
No. I kind of like it the way that it is.
> Furthermore, it is al
[EMAIL PROTECTED] (James Youngman) wrote:
> On Thu, Jun 23, 2005 at 08:45:05PM +, Eric Blake wrote:
>> This puts the invocation of rm without arguments in the
>> implementation's realm, where currently, coreutils is not consistent
>> on what it returns:
>>
>> $ rm
>> rm: missing operand
>> Try
On Thu, Jun 23, 2005 at 08:45:05PM +, Eric Blake wrote:
> This puts the invocation of rm without arguments in the
> implementation's realm, where currently, coreutils is not consistent
> on what it returns:
>
> $ rm
> rm: missing operand
> Try `rm --help' for more information.
> $ echo $? #
POSIX requires that rm have an argument, but also that it exit with 0 status
if "All of the named directory entries for which rm performed actions
equivalent to the rmdir() or unlink() functions were removed." This puts the
invocation of rm without arguments in the implementation's realm, where
cu
