Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001808 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Editorial Clarification Requested 2024-02-03 01:44 2024-04-23 13:57
Reporter cquike View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Resolved  
Name Enrique Garcia
Organization
User Reference
Section getconf
Page Number (page or range of pages)
Line Number (Line or range of lines)
Interp Status ---
Final Accepted Text Note: 0006747
Summary 0001808: Add option -a to getconf utility
Description Option -a of getconf is widely available in different UNIX systems and is used to display all the configuration values. Adding that to the standard would add a portable way to retrieve all the values, since right now it is not possible to know using only the POSIX getconf options which values the implementation defines in addition to the standard.

It seems that all major UNIX-like OS hve that option:

Freebsd (https://man.freebsd.org/cgi/man.cgi?query=getconf) [^]
Linux (glibc, https://manpages.debian.org/bullseye/libc-bin/getconf.1.en.html) [^]
Solaris (https://docs.oracle.com/cd/E88353_01/html/E37839/getconf-1.html) [^]
AIX (https://www.ibm.com/docs/en/aix/7.1?topic=g-getconf-command) [^]
macos (https://manrocks.org/macosx/1/getconf) [^]
Desired Action In the SYNOPSIS section of getconf add at the end:

       getconf -a [file]

In the DESCRIPTION section of getconf add:

       In the third synopsis form, the getconf utility shall write to the standard output the value of all the system variables defined by sysconf(), confstr() as well as the constnats listed under the headings ``Maximum Values'' and ``Minimum Values'' in the description of the <limits.h> header in the Base Definitions volume of POSIX.1-2017. If file is provided, all path configuration variables are reported for file using pathconf() function defined in the System Interfaces volume of POSIX.1-2017. In both cases, the implementation may add other local values.

Tags issue9
Attached Files

- Relationships

-  Notes
(0006674)
kre (reporter)
2024-02-25 05:48

I don't think I'd have readers manually counting sysopsis forms,
just say "When used with -a ..."
(0006705)
cquike (reporter)
2024-03-06 10:40

New proposed change after above feedback:

"
In the SYNOPSIS section of getconf add at the end:

       getconf -a [file]

In the DESCRIPTION section of getconf add:

       When used with -a, the getconf utility shall write to the standard output the value of all the system variables defined by sysconf(), confstr() as well as the constants listed under the headings ``Maximum Values'' and ``Minimum Values'' in the description of the <limits.h> header in the Base Definitions volume of POSIX.1-2017. If file is provided, all path configuration variables are reported for file using pathconf() function defined in the System Interfaces volume of POSIX.1-2017. In both cases, the implementation may add other local values.
"
(0006747)
geoffclare (manager)
2024-04-11 15:19
edited on: 2024-04-11 15:21

After page 2831 line 93192 section getconf SYNOPSIS, add:
getconf -a [-v specification] [pathname]


After page 2831 line 93197 section getconf DESCRIPTION, add:
If the -a option is specified, the getconf utility shall write to the standard output the names and values of all valid configuration variables; that is, every system_var operand and every path_var operand that the utility accepts, together with the values of the variables specified by those operands. For path_var operands the value written shall be the value of the variable for the path specified by the pathname operand, if present; if no pathname is provided, it is implementation-defined whether the value is for the current working directory (.) or the root directory (/).


On page 2831 line 93204 section getconf OPTIONS, change:
The following option shall be supported:

to:
The following options shall be supported:

-a
Write the names and values of all valid configuration variables.


After page 2833 line 93307 section getconf STDOUT, add these new paragraphs:
If the -a option is specified, the name of each valid configuration variable and information about the variable shall be written in the following format:

"%s: %s\n", <name>, <info_string>


where <info_string> is the information string that would be written (without the terminating <newline>) for the variable if specified as an operand, as described below.

The remainder of this section describes the behavior if the -a option is not specified.


On page 2834 line 93327 section getconf EXIT STATUS, change:
The specified variable is valid and information about its current state was written successfully.

to:
The -a option was specified and the names of all valid configuration variables were written successfully together with information about each variable's current state, or the -a option was not specified, the specified variable is valid, and information about its current state was written successfully.


On page 2834 line 93333 section getconf APPLICATION USAGE, change:
None.

to:
Since the value of a configuration variable obtained from confstr() may include <newline> characters, the output when the -a option is specified cannot be assumed to contain one name and value per line. Applications can use the presence of a <colon> at the end of the variable name as a means to distinguish names from parts of values that follow a <newline>; however, it is possible (although unlikely) for a multi-line value to match this and it is recommended that applications needing to extract a list of valid variable names should confirm their validity by checking whether getconf accepts them as either a system_var or path_var operand.


After page 2835 line 93364 section getconf RATIONALE, add a new paragraph:
Historically the GNU implementation of getconf -a did not output a <colon> after each variable name, whereas other implementations did. The standard developers decided to require the <colon> in order to help applications and users distinguish variable names from parts of values that follow a <newline>. In some implementations the use of -v with -a was undocumented but supported; in others it was not supported, but it was felt to be a useful feature that would be simple to provide.


(0006764)
eblake (manager)
2024-04-17 19:27

In https://sourceware.org/bugzilla/show_bug.cgi?id=22099, [^] the glibc developers were worried that the use of a colon is ambiguous because some confstr options might be related to PATH which itself uses a colon. We may be better off trying to standardize 'getopt -l' as a means of listing just the query names, and leave 'getopt -a' unstandardized.
(0006765)
philip-guenther (reporter)
2024-04-18 01:04

To agree with https://austingroupbugs.net/view.php?id=1808#c6764, [^] that (the ambiguities) were part of why on OpenBSD we did -l and -L, documented currently as:

     -L List the system variables that can be used with the getconf
             utility that require a pathname argument.

     -l List the system variables that can be used with the getconf
             utility without a pathname argument.

So, there's existing practice for that.
(0006766)
geoffclare (manager)
2024-04-18 09:36

> the glibc developers were worried that the use of a colon is ambiguous because some confstr options might be related to PATH which itself uses a colon

This came up in the teleconference. The colon would only be ambiguous if a value contains a newline followed by something that could be a variable name, followed by a colon. In the case of PATH, although a user's PATH could contain a newline, confstr() returns the implementation's standard PATH, so the value will not contain any newlines, and therefore there is no ambiguity. On the line of output for the PATH value, the first colon is the separator and any remaining colons are part of the PATH value.
(0006768)
kre (reporter)
2024-04-19 12:28
edited on: 2024-04-19 15:33

wrt Note: 0006766

   confstr() returns the implementation's standard PATH,

that's fine, but:

   so the value will not contain any newlines,

How does that follow? What if the implementation's standard PATH
contains the directory whose name is obtained from

   printf '%s\n%s' "/usr/" "POSIX"

as a directory no-one would normally include in PATH, which contains versions
of various standard utilities to replace the ones the implementation normally
uses which differ from the standard in some way.

Is there something somewhere which prohibits an implementation like that?
If not, your conclusion doesn't follow.

(0006769)
geoffclare (manager)
2024-04-19 13:40

Re Note: 0006768 I said "will not", not "is not allowed to". Although a Weirdnix system could do what you say, no real system would ever do that.

The fact the output is not 100% guaranteed to be unambiguous is the reason the resolution includes APPLICATION USAGE text about checking whether the extracted variable names are valid. Having the colon there makes it extremely unlikely to be ambiguous in practice; without the colon it is already ambiguous in practice in the GNU implementation because of POSIX_V7_WIDTH_RESTRICTED_ENVS.
(0006770)
kre (reporter)
2024-04-19 15:37

While what you say in Note: 0006769 is probably right, and real
systems wouldn't do that, systems looking for holes in the spec,
and/or applications would - it is the kind of thing that santitzers
do all the time. Garbage, but legal, input, generated for the whole
purpose of defeating the system.

Since it is known now (and also as nothing about what is resolved
in this issue is going to see the light of day for years) it would
make sense to me to defer this, and look for a good solution, and
eventually specify that, rather than specify something which is
just "extremely unlikely" to fail, when we already know how to make
that happen.
(0006772)
geoffclare (manager)
2024-04-23 09:59

Re Note: 0006770 The specified format is existing practice on macOS, FreeBSD, Solaris and its derivatives (anything built from Illumos), and AIX. The only other existing practice we know of is the GNU output that is much much worse from the ambiguity point of view.

As you yourself have mentioned often elsewhere, POSIX can only standardise existing practice, we cannot invent a new format.
(0006773)
kre (reporter)
2024-04-23 13:57

Re: Note: 0006772

   POSIX can only standardise existing practice, we cannot invent a new format

I agree, pity the people who invented all of those posix_abcdefg() interfaces
(and a whole bunch more) apparently do not.

That's why I suggested doing nothing right now. This issue is already
tagged as issue9 (which seems correct to me) - which means it isn't going
to appear in a standard for a decade or more (just consider the time between
when issue7 was published, and whenever it eventually happens, issue8).

Now the issues are known, there is plenty of time for the implementers
to implement something better (safer) that what now exists. If that
doesn't happen, then what is proposed can be accepted sometime much closer
to the issue9 deadline.

Note, I am not suggesting this for everything - in general there's a benefit
to knowing (being able to find out) what the next standard will say about
something - allows new implementers to match the existing (appropriate)
behaviour, which just happens to not yet be standardised.

But here, existing behaviour seems to be unsafe, and not good to specify,
however unlikely you believe it to be that it will actually cause problems.

Just wait. Change the status back to just "open".

- Issue History
Date Modified Username Field Change
2024-02-03 01:44 cquike New Issue
2024-02-03 01:44 cquike Name => Enrique Garcia
2024-02-03 01:44 cquike Section => getconf
2024-02-03 01:44 cquike Page Number => (page or range of pages)
2024-02-03 01:44 cquike Line Number => (Line or range of lines)
2024-02-25 05:48 kre Note Added: 0006674
2024-03-06 10:40 cquike Note Added: 0006705
2024-04-11 15:19 geoffclare Note Added: 0006747
2024-04-11 15:21 geoffclare Note Edited: 0006747
2024-04-11 15:21 geoffclare Interp Status => ---
2024-04-11 15:21 geoffclare Final Accepted Text => Note: 0006747
2024-04-11 15:21 geoffclare Status New => Resolved
2024-04-11 15:21 geoffclare Resolution Open => Accepted As Marked
2024-04-11 15:22 geoffclare Tag Attached: issue9
2024-04-17 19:27 eblake Note Added: 0006764
2024-04-18 01:04 philip-guenther Note Added: 0006765
2024-04-18 09:36 geoffclare Note Added: 0006766
2024-04-19 12:28 kre Note Added: 0006768
2024-04-19 13:40 geoffclare Note Added: 0006769
2024-04-19 15:33 kre Note Edited: 0006768
2024-04-19 15:37 kre Note Added: 0006770
2024-04-23 09:59 geoffclare Note Added: 0006772
2024-04-23 13:57 kre Note Added: 0006773
2024-08-15 20:02 salewski Issue Monitored: salewski


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker