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
0001536 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Objection Error 2021-11-20 17:07 2021-11-20 17:07
Reporter kre View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
Name Robert Elz
Organization
User Reference
Section XCU 2;7;5, XCU 2.7.6
Page Number 2363
Line Number 75362-75377
Interp Status ---
Final Accepted Text
Summary 0001536: Unimplemented requirements in fd duplication
Description Note: the text in question appears unchanged in Issue 8 Draft 2.1
but obviously the page & line numbers differ.

In XCU 2.7.5 (the <& redirect operator) it is stated:

    if the digits in word do not represent a file descriptor already open
    for input, a redirection error shall result;

Similarly in XCU 2.7.6 (the >& redirect operator):

    if the digits in word do not represent a file descriptor already open
    for output, a redirection error shall result;

I am unable to find a shell which implements that redirection error, where
the fd given by word is open, but not for input/output as specified.
(as the requirement is "error shall result" that means there are no
conforming shells, or none I have available to test ... I find it hard to
believe that ksh88 is any different).

Try:
    sh $ exec 4>/tmp/foo; exec 6<&4
    sh $ exec 4</tmp/foo; exec 6>&4

in your favourite shell and see how many redirection errors you experience.
(Errors on the redirect of fd 4 do not count for this purpose, it is easy
to set up a scenario where that redirect fails -- just make that one work).

This is hardly surprising, as all shells simply use either dup2() or
fcntl(F_DUPFD) to perform these operations, and as long as the source
fd is open, and there are sufficient available fd's for the new one
to be opened (and its fd number is within range) those operations succeed.
They don't care in the slightest whether the source fd is open for reading,
writing, both, or neither.

Requiring that an error be generated when the source fd is not open for
the direction of I/O implied by the operator in use, would require the
shell to first determine how the source fd was opened (fcntl(F_GETFL)
and verify it - which no-one does - but we would also need to invent a
<>& operator (which no-one has done yet) to make sure to be able to
correctly duplicate a file descriptor open for both read and write.

It would be tempting to simply delete the words "for input" and "for output"
and leave it like that, but that might lead to a suboptimal result, where
shells are (effectively) forbidden from generating errors from the example
code shown above, and while no-one currently does, making it effectively
impossible to ever do, which it would be if applications were told that it
makes no difference which fd duplication redirect operator they use, which
that change would effectively do, is probably not what we want.

Instead, I'd make it unspecified what happens if the input duplication
operator is applied to a fd not already open for input, or if the output
duplication operator is applied to a fd not already open for output.
That leaves current shells compliant, puts the onus on applications to
do the right thing (which is their only choice right now -- it doesn't
matter which duplication operator is applied, what matters is how the
resulting fd is used - it can only be used for operations that were
permitted to the source fd ("word"). It leaves it open for a shell to
actually verify correct usage, but such a shell would probably need to
invent <>& (in that, or some other, syntax) for fd's open read+write.
Desired Action In line 75394 delete the words

for input


and append after the words (before the terminating period)

see Section 2.8.1


a new clause:

; if the file descriptor denoted by word represents an open
file descriptor that is not open for input, the behaviour is
unspecified


In line 75404 delete the words

for output


and append after the words (before the terminating period)

see Section 2.8.1


a new clause:

; if the file descriptor denoted by word represents an open
file descriptor that is not open for output, the behaviour is
unspecified


Somewhere in XRAT (probably) add a new section, or paragraph

<blockqouote>Redirection file descriptor duplication operators.

The file descriptor duplication redirection operators, <& and >&,
make a copy of one file desciptor as another.
The new file descriptor will traditionally have the same access permissions
as the source (old) file descriptor.
However this is not guaranteed by this standard.
Applications must ensure that they use the appropriate redirection
operator for the fle descriptor being duplicated, and only use the
new, duplicate, file descriptor for operations that would be permitted
to the original file descriptor.
Any other usage results in unspecified behaviour.

Or some words with that general intent.

Note that this solution does not require the <>& operator be
invented, a file descriptor open for input and output can be used by
either of the redirect/duplicate operators, and can then be used for
both input and output.
Tags No tags attached.
Attached Files

- Relationships

There are no notes attached to this issue.

- Issue History
Date Modified Username Field Change
2021-11-20 17:07 kre New Issue
2021-11-20 17:07 kre Name => Robert Elz
2021-11-20 17:07 kre Section => XCU 2;7;5, XCU 2.7.6
2021-11-20 17:07 kre Page Number => 2363
2021-11-20 17:07 kre Line Number => 75362-75377


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