On Tue, Oct 22, 2013 at 08:37:06PM +0300, loth...@iki.fi wrote:
> >Synopsis: ps(1) does not support -A, -o comm=foo
> >Category: user
> >Environment:
> System : OpenBSD 5.3
> Details : OpenBSD 5.3 (GENERIC) #50: Tue Mar 12 18:35:23 MDT 2013
>
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
>
> Architecture: OpenBSD.i386
> Machine : i386
> >Description:
> ps(1) manual claims that the implementation is compliant to POSIX 2008,
> but:
> * -A is not supported (see below)
> * '-o comm=foo' gives an error (see below; interestingly '-o
> ucomm=foo' and '-o comm' work as expected)
>
> POSIX specifies both -A and the 'comm' field name; see
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ps.html
> >How-To-Repeat:
> $ ps -A
> ps: unknown option -- A
> usage: ps [-aCceHhjkLlmrSTuvwx] [-M core] [-N system] [-O fmt] [-o fmt]
> [-p pid]
> [-t tty] [-U username] [-W swap]
>
> $ ps -o comm=foo >/dev/null
> ps: comm: illegal keyword specification
> >Fix:
> Add support for these options.
>
i suspect you'd make a better case if you supplied a diff, and your
reasoning for wanting their inclusion.
anyway, i'll address your gripe with the manual, which i agree has some
basis. basically we do not currently document, at least in general,
options which posix say should exist, but we do not have. and we still
claim posix compatibility.
i agree that's not perfect, but:
- believe me, the number of apps this applies to is small. i can
mail you a list in private if you want.
- in general, we tend not to document things that are not
supported. yes there are exceptions, but for one it's an
unrealistic goal, and two there's the danger that if we add
support, we forget to update the doc.
- my hope for the posix compat claim is more that readers will
know that a specific app is specified by posix, that they
can safely use any of the options except those documented
as being extensions, and they can go read the spec
themselves if they want fine detail. i reasoned that if
people reported differences in behaviour we could document
them (and we do), but i simply did not document non-supported
options.
i guess we could document where posix mandates an option but we don;t
support it. there are very few, so it wouldn;t be a great deal of work.
not sure if i feel it's worth it though.
jmc
