[PATCH] posix conformance listing

[David Krakov]

Hi,

Sorry for the late response, I didn't notice the "if you could post a
Signed-off-by tag" phrase until seeing it is not in git.

I have no idea how to get git to include this tag automatically, so,
manually (same patch):

Signed-off-by: David Krakov <krakov at gmail.org>
---



On Sun, May 17, 2009 at 3:53 AM, Mike Frysinger <vapier at gentoo.org> wrote:
> On Saturday 16 May 2009 18:34:13 David Krakov wrote:
>> Attached a start for POSIX conformance documentation for busybox (see
>> TODO file and discussion last week ).
>> A table of all options as defined by POSIX and as implemented by
>> busybox (see for a FreeBSD example
>> http://people.freebsd.org/~schweikh/posix-utilities.html).
>
> that was fast :).  if you could post a Signed-off-by tag, i can merge the
> diff.
>
>> Only the tools that are stand-alone applets are documented (not ash
>> built-ins as 'read'), as there are multiple shells.
>> When there are two versions (echo) the stand-alone version was
>> checked. I think this may be the wrong way to go, as most users will
>> probably use the built-in version - but which shell?
>
> we should strive to keep implementations across shells and standalone merged.
> this should be somewhat easy to do if the shells simply called the standalone
> applet.
>
>> The table was auto-generated by running, for each POSIX utility,
>> latest git allyesconfig* "busybox <tool> --help" and parsing the
>> output, and comparing that to tool options extracted from its man page
>> at http://www.opengroup.org/onlinepubs/9699919799/.
>> This means that it the usage string is not correct, the table is also
>> wrong. I noticed that for 'kill', for example, the usage string does
>> not mention the -s, -q, -o options.
>
> yeah, quite possible the usage string falls out of sync with the actual
> applet.  unfortunately, the process of optimizing getopt usage means that it's
> hard to keep the usage output merged with the actual getopt calls.  add to the
> fact that we need the complete usage string available on the build host (for
> compression/documentation purposes), and it makes it near impossible currently
> to merge these two locations.
>
>> For each option is set whether it exists in busybox and if it is, is
>> it compliant to the standard. Of course, checking compliance can only
>> be done manually - a process which will probably take some time (see
>> 'cat' for example).
>
> some of the options you documented as "busybox specific" are actually GNU
> specific which busybox mimics.  ar's -o option for example.
>
>> As for the tools not implemented by busybox at all, I think most of
>> them are indeed fairly esotetic. Some I was suprised to see missing
>> are link, file, newgrp, unlink.
>
> link/unlink should be pretty trivial to implement, but no one uses these
> things which is why people havent noticed/cared.  people use `ln`, not `link`,
> and `rm`, not `unlink` because the link utils lack pretty much any sort of
> option set.  at any rate, someone who wanted to a quick dive into how to
> implement a busybox applet could probably tackle these :).
>
> `file` is unlikely to happen due to the database of types.  it's very hard to
> identify a wide variety of files let alone due it correctly without false
> positives.  ive seen people type documents in certain ISO char sets whose
> first few characters happened to match magic signatures for random data files.
> plus, it'd be a maintenance nightmare as people dont care about these
> intricacies.  they expect `file` to work exactly right all the time.
>
> as for newgrp, ive never seen anyone use that before.  but seems like it
> shouldnt be too hard to implement.
> -mike
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: conf.diff
Type: text/x-diff
Size: 24163 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20090527/e3deed3c/attachment-0001.bin>