Anonymous | Login | 2024-10-09 04:26 UTC |
Main | My View | View Issues | Change Log | Docs |
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 | |||||||||||||
|
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: 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: 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 |