* [Bug libc/22099] getconf help info
[not found] <bug-22099-131@http.sourceware.org/bugzilla/>
@ 2024-04-08 15:30 ` eblake at redhat dot com
2024-04-11 15:14 ` eblake at redhat dot com
` (5 subsequent siblings)
6 siblings, 0 replies; 7+ messages in thread
From: eblake at redhat dot com @ 2024-04-08 15:30 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libc/22099] getconf help info
[not found] <bug-22099-131@http.sourceware.org/bugzilla/>
2024-04-08 15:30 ` [Bug libc/22099] getconf help info eblake at redhat dot com
@ 2024-04-11 15:14 ` eblake at redhat dot com
2024-04-13 18:35 ` fweimer at redhat dot com
` (4 subsequent siblings)
6 siblings, 0 replies; 7+ messages in thread
From: eblake at redhat dot com @ 2024-04-11 15:14 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libc/22099] getconf help info
[not found] <bug-22099-131@http.sourceware.org/bugzilla/>
2024-04-08 15:30 ` [Bug libc/22099] getconf help info eblake at redhat dot com
2024-04-11 15:14 ` eblake at redhat dot com
@ 2024-04-13 18:35 ` fweimer at redhat dot com
2024-04-15 12:34 ` eblake at redhat dot com
` (3 subsequent siblings)
6 siblings, 0 replies; 7+ messages in thread
From: fweimer at redhat dot com @ 2024-04-13 18:35 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libc/22099] getconf help info
[not found] <bug-22099-131@http.sourceware.org/bugzilla/>
` (2 preceding siblings ...)
2024-04-13 18:35 ` fweimer at redhat dot com
@ 2024-04-15 12:34 ` eblake at redhat dot com
2024-04-15 12:46 ` eblake at redhat dot com
` (2 subsequent siblings)
6 siblings, 0 replies; 7+ messages in thread
From: eblake at redhat dot com @ 2024-04-15 12:34 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libc/22099] getconf help info
[not found] <bug-22099-131@http.sourceware.org/bugzilla/>
` (3 preceding siblings ...)
2024-04-15 12:34 ` eblake at redhat dot com
@ 2024-04-15 12:46 ` eblake at redhat dot com
2024-04-17 17:11 ` fweimer at redhat dot com
2024-04-17 19:25 ` eblake at redhat dot com
6 siblings, 0 replies; 7+ messages in thread
From: eblake at redhat dot com @ 2024-04-15 12:46 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libc/22099] getconf help info
[not found] <bug-22099-131@http.sourceware.org/bugzilla/>
` (4 preceding siblings ...)
2024-04-15 12:46 ` eblake at redhat dot com
@ 2024-04-17 17:11 ` fweimer at redhat dot com
2024-04-17 19:25 ` eblake at redhat dot com
6 siblings, 0 replies; 7+ messages in thread
From: fweimer at redhat dot com @ 2024-04-17 17:11 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug libc/22099] getconf help info
[not found] <bug-22099-131@http.sourceware.org/bugzilla/>
` (5 preceding siblings ...)
2024-04-17 17:11 ` fweimer at redhat dot com
@ 2024-04-17 19:25 ` eblake at redhat dot com
6 siblings, 0 replies; 7+ messages in thread
From: eblake at redhat dot com @ 2024-04-17 19:25 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread