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
0001807 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Comment Clarification Requested 2024-02-03 01:20 2024-03-28 16:23
Reporter cquike View Status public  
Assigned To
Priority normal Resolution Rejected  
Status Closed  
Name Enrique Garcia
Organization
User Reference
Section 2.7 Redirection
Page Number (page or range of pages)
Line Number (Line or range of lines)
Interp Status ---
Final Accepted Text
Summary 0001807: Allow number of redirection open files to be up to OPEN_MAX / 2 - 1
Description The redirection description states that numbers are used to represent the file descriptors and that "all implementations shall support at least 0 to 9, inclusive, for use by the application".

The restriction to have "at least 9" seems a bit low to me, given that the implementation can support up to OPEN_MAX file descriptors. There are many pages in Internet that include examples like "exec 200<lock.file" that will fail in POSIX shells that don't allow more than 9 in the file descriptor.

Some shells, like dash (which by the way has a limit of strictly 9), duplicates the original file descriptor (https://git.kernel.org/pub/scm/utils/dash/dash.git/tree/src/TOUR), [^] so in order to avoid issues with those implementations the file descriptor number shouldn't not be larger than OPEN_MAX / 2 - 1.
Desired Action On section "2.7 Redirection" of "Shell Command Language" change:

      ...The largest possible value is implementation-defined; however, all implementations shall support at least 0 to 9, inclusive, for use by the application....

to:

      ...The largest possible value shall be OPEN_MAX / 2 - 1, inclusive, for use by the application, where OPEN_MAX is defined in sysconf....
Tags No tags attached.
Attached Files

- Relationships

-  Notes
(0006673)
kre (reporter)
2024-02-25 05:45

Limiting the largest value to OPEN_MAX/2 -1, just to support dash, seems
like the wrong thing to do.

I suspect maybe the intent was to require at least that many, rather than
at most that many, in which case the correct change would be to alter the
"however all implentations shall support" clause, and change that from 0 to 9
into something bigger. (That is, to limit applications to use values
less than OPEN_MAX/2 as more cannot be guaranteed to work - with the intent
being that anything up to that must be OK - rather than to make non-conforming
some other shell which allows even bigger values.)

Personally I see no reason for the limit to be less than OPEN_MAX - this
limit applies to the fd used, not to the number of open files that a shell
can support, I can't see how dash would be bothered (if it supported it)
by a script which did 1999>/dev/null (if on an implementation where OPEN_MAX
was 2000 - just as an example). When it does its dup (why I wonder?) so
it apparently has 2 fds internally, the other one (the internal only one) would
just be 20 or something.

On the other hand, and while the shell I maintain does allow fds to be much
bigger than 9 (anything the kernel will allow is OK), I'm not sure I see
a lot of reason for changing the standard to require it.
(0006704)
cquike (reporter)
2024-03-06 10:37

Yes, good point. Indeed the intention was to support "at least OPEN_MAX/2", so that POSIX-conforming applications can rely on using up to OPEN_MAX/2 in a portable way.

I rephrase the proposed change with feedback above:


 On section "2.7 Redirection" of "Shell Command Language" change:

      ...The largest possible value is implementation-defined; however, all implementations shall support at least 0 to 9, inclusive, for use by the application....

to:

      ...The largest possible value is implementation-defined; however, all implementations shall support at least OPEN_MAX / 2 - 1, inclusive, for use by the application....
(0006730)
geoffclare (manager)
2024-03-28 16:23

Making this change would actually have no effect on the highest fixed fd number a portable script can use in a redirection. This is because if the limit is OPEN_MAX/2 - 1, a portable script has to assume OPEN_MAX could have its lowest allowed value, _POSIX_OPEN_MAX, which happens to be 20, and 20/2 - 1 is 9.

So a use such as "exec 200<lock.file" as stated in the bug description would still be non-portable.

Higher fd numbers could be used if they are not fixed, by querying OPEN_MAX using getconf and using this to calculate a suitable fd number to put in a variable, then using "eval" to have the variable be expanded in a redirection, but the number of scripts that would take advantage of that is likely to be very small. Scripts can already use higher fd numbers, when supported by the particular shell being used, by checking using "eval" whether the number they want to use is accepted.

Therefore this bug is being rejected.

- Issue History
Date Modified Username Field Change
2024-02-03 01:20 cquike New Issue
2024-02-03 01:20 cquike Name => Enrique Garcia
2024-02-03 01:20 cquike Section => 2.7 Redirection
2024-02-03 01:20 cquike Page Number => (page or range of pages)
2024-02-03 01:20 cquike Line Number => (Line or range of lines)
2024-02-25 05:45 kre Note Added: 0006673
2024-03-06 10:37 cquike Note Added: 0006704
2024-03-28 16:23 geoffclare Interp Status => ---
2024-03-28 16:23 geoffclare Note Added: 0006730
2024-03-28 16:23 geoffclare Status New => Closed
2024-03-28 16:23 geoffclare Resolution Open => Rejected


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