[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: [PATCH] Add coreutils/unlink.c
From:       Rich Felker <dalias () libc ! org>
Date:       2014-06-23 19:05:06
Message-ID: 20140623190506.GN179 () brightrain ! aerifal ! cx
[Download RAW message or body]

On Mon, Jun 23, 2014 at 07:36:50PM +0100, Laurent Bercot wrote:
> >Well, unlink takes '--version' and '--help' as options. I think
> >there's a conflict between open standard and coreutils' oddity to
> >bring command syntax and version information with command line
> >switches.
> 
>  unlink is not the only nonconforming executable in GNU coreutils.
> true and false, for instance, also accept GNU options. (Because
> being able to perform "true --help" and "true --version" is vital.)
> It's just a symptom of GNU's tendency to think itself as better than
> the standard while pretending to conform to it.
> 
>  Busybox has to make a choice: either be conformant or mimic GNU
> coreutils' behaviour. Both paths are valid, but Busybox has to be
> consistent with it: all utilities have to make the same choice.
> 
>  I vote for a general compile-time option BB_MIMIC_GNU, if there
> isn't anything similar already.

If this is the path taken, I think the config option should be clearly
name and documented to explain that it is not adding useful features
but rather compatibility with gratuitous GNU brokenness. For example
in the case of unlink, the coreutils brokenness defeats the whole
purpose of having the utility.

Of course having the utility is rather useless anyway since "rm --
filename" is just as good. I would argue that unlink is useless and
could just be replaced by such a script if needed.

Rich
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]