[Bug libc/22099] getconf help info

[Bug libc/22099] getconf help info

[eblake at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22099

Eric Blake <eblake at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eblake at redhat dot com

--- Comment #1 from Eric Blake <eblake at redhat dot com> ---
This came up in the Austin Group meeting today:
https://austingroupbugs.net/view.php?id=1808

POSIX is considering standardizing 'getconf -a'; so the inconsistency  between
'getconf' stating that -a is supported, and 'getconf --help' not mentioning it,
should be fixed.

It was also uncertain whether 'getconf -a /some/file' can ever have output
different than 'getconf -a'.  The former should list values specific to
fpathconf for /some/file, that may have different values depending on the file
system underlying that file, while the latter should list values specific to
getconf; however, the Austin Group noted that at least 'getconf -a | grep
NAME_MAX' vs. 'getconf -a . | grep NAME_MAX' gave the same input, but I'm not
sure if there is an easy way to trigger a given file name that would
demonstrate a path-specific result from fpathconf.

BSD also has 'getconf -l' which lists the names (but not results) of the
various getconf/fpathconf constants (useful since some of the results can be
strings that might include a newline, rendering the output of -a ambiguous).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/22099] getconf help info

[eblake at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22099

--- Comment #2 from Eric Blake <eblake at redhat dot com> ---
The Austin Group pointed out one of the ambiguities of the GNU output when
encountering multi-line confstr() output:

$ getconf POSIX_V7_WIDTH_RESTRICTED_ENVS 
POSIX_V7_ILP32_OFF32
POSIX_V7_ILP32_OFFBIG
POSIX_V7_LP64_OFF64
$ getconf -a | grep -A2 V7_WIDTH
_POSIX_V7_WIDTH_RESTRICTED_ENVS    POSIX_V7_ILP32_OFF32
POSIX_V7_ILP32_OFFBIG
POSIX_V7_LP64_OFF64
POSIX_V7_WIDTH_RESTRICTED_ENVS     POSIX_V7_ILP32_OFF32
POSIX_V7_ILP32_OFFBIG
POSIX_V7_LP64_OFF64

and recommends that GNU consider changing the output to be more like BSD
output, using a colon between the item name and its value (as it is less likely
for a confstr() output to also contain a colon)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/22099] getconf help info

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22099

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com

--- Comment #3 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Eric Blake from comment #2)
> The Austin Group pointed out one of the ambiguities of the GNU output when
> encountering multi-line confstr() output:
> 
> $ getconf POSIX_V7_WIDTH_RESTRICTED_ENVS 
> POSIX_V7_ILP32_OFF32
> POSIX_V7_ILP32_OFFBIG
> POSIX_V7_LP64_OFF64
> $ getconf -a | grep -A2 V7_WIDTH
> _POSIX_V7_WIDTH_RESTRICTED_ENVS    POSIX_V7_ILP32_OFF32
> POSIX_V7_ILP32_OFFBIG
> POSIX_V7_LP64_OFF64
> POSIX_V7_WIDTH_RESTRICTED_ENVS     POSIX_V7_ILP32_OFF32
> POSIX_V7_ILP32_OFFBIG
> POSIX_V7_LP64_OFF64
> 
> and recommends that GNU consider changing the output to be more like BSD
> output, using a colon between the item name and its value (as it is less
> likely for a confstr() output to also contain a colon)

Colon between name and value, or colon between multiple values (instead of
newlines)?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/22099] getconf help info

[eblake at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22099

--- Comment #4 from Eric Blake <eblake at redhat dot com> ---
Output according to the POSIX recommendation would be:

$ getconf -a | head -n2
LINK_MAX:                           127
_POSIX_LINK_MAX:                    127

the whitespace can be arbitrary, but as none of the category names can include
a colon, and since a colon is unlikely in the contents of a confstr value
(although some values are blank), it would make it more obvious that the
following subset of the output represents exactly 8 of the many known keys:

$ getconf -a | grep -C4 POSIX_V7_WIDTH
POSIX_V7_ILP32_OFF32_CFLAGS:        -m32
POSIX_V7_ILP32_OFF32_LDFLAGS:       -m32
POSIX_V7_ILP32_OFF32_LIBS:          
POSIX_V7_ILP32_OFF32_LINTFLAGS:     
_POSIX_V7_WIDTH_RESTRICTED_ENVS:    POSIX_V7_ILP32_OFF32
POSIX_V7_ILP32_OFFBIG
POSIX_V7_LP64_OFF64
POSIX_V7_WIDTH_RESTRICTED_ENVS:     POSIX_V7_ILP32_OFF32
POSIX_V7_ILP32_OFFBIG
POSIX_V7_LP64_OFF64
_POSIX_V7_ILP32_OFFBIG:             1
POSIX_V7_ILP32_OFFBIG_CFLAGS:       -m32 -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/22099] getconf help info

[eblake at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22099

--- Comment #5 from Eric Blake <eblake at redhat dot com> ---
POSIX also wants to ensure that if:

$ getconf -v POSIX_V7_ILP32_OFF32 POSIX_V7_ILP32_OFF32_CFLAGS
-m32

has output other than -1 or undefined (because the spec name was recognized),
then the following two command lines must have identical behavior (right now,
they do not):

$ getconf -v POSIX_V7_ILP32_OFF32 -a
$ getconf -a -v POSIX_V7_ILP32_OFF32

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/22099] getconf help info

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22099

--- Comment #6 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Eric Blake from comment #4)
> Output according to the POSIX recommendation would be:
> 
> $ getconf -a | head -n2
> LINK_MAX:                           127
> _POSIX_LINK_MAX:                    127
> 
> the whitespace can be arbitrary, but as none of the category names can
> include a colon, and since a colon is unlikely in the contents of a confstr
> value (although some values are blank), it would make it more obvious that
> the following subset of the output represents exactly 8 of the many known
> keys:
> 
> $ getconf -a | grep -C4 POSIX_V7_WIDTH
> POSIX_V7_ILP32_OFF32_CFLAGS:        -m32
> POSIX_V7_ILP32_OFF32_LDFLAGS:       -m32
> POSIX_V7_ILP32_OFF32_LIBS:          
> POSIX_V7_ILP32_OFF32_LINTFLAGS:     
> _POSIX_V7_WIDTH_RESTRICTED_ENVS:    POSIX_V7_ILP32_OFF32
> POSIX_V7_ILP32_OFFBIG
> POSIX_V7_LP64_OFF64
[…]

I must say that this is pretty wild as a means to disambiguate the output. Why
not add proper string quoting if we change the output format? Or at least use :
as a separator instead of newline if the value contains newlines.

Note that on many systems, the *values* for PATH already contain colons.

We can restrict whatever POSIX mandates to POSIXLY_CORRECT mode, I suppose, so
I don't have a strong opinion about this. To fix this without quoting, we can
add a new output mode that lists all variables, one per line, but not their
values.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/22099] getconf help info

[eblake at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22099

--- Comment #7 from Eric Blake <eblake at redhat dot com> ---
The POSIX wording is not set in stone; if we have a better proposal (possibly
under the guise of a different option) than the current difference in output
between BSD getopt and glibc getopt, right now is our chance to propose that to
the Austin Group.

BSD does have 'getopt -l' which lists the known names (but not values) that can
be queried; the Austin Group did discuss that as being one possibility, but at
the time said that it has fewer implementations than 'getopt -a'.  But if we
can argue back to the Austin Group that 'getopt -l' is the better interface
from the get-go, and implement it such that the output is equivalent to BSD's
output, then it stands a better chance of the Austin Group standardizing
'getopt -l' and leaving 'getopt -a' as an unspecified extension option.

-- 
You are receiving this mail because:
You are on the CC list for the bug.