View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001807 | 1003.1(2016/18)/Issue7+TC2 | Shell and Utilities | public | 2024-02-03 01:20 | 2024-03-28 16:23 |
| Reporter | cquike | Assigned To | |||
| Priority | normal | Severity | Comment | Type | Clarification Requested |
| Status | Closed | Resolution | Rejected | ||
| 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. | ||||
|
|
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. |
|
|
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.... |
|
|
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. |
| 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 |
