The following issue has been SUBMITTED. 
====================================================================== 
https://austingroupbugs.net/view.php?id=1521 
====================================================================== 
Reported By:                kre
Assigned To:                
====================================================================== 
Project:                    1003.1(2016/18)/Issue7+TC2
Issue ID:                   1521
Category:                   Shell and Utilities
Type:                       Error
Severity:                   Objection
Priority:                   normal
Status:                     New
Name:                       Robert Elz 
Organization:                
User Reference:              
Section:                    XCU 2.7.4 
Page Number:                2362 
Line Number:                75362-75377 
Interp Status:              --- 
Final Accepted Text:         
====================================================================== 
Date Submitted:             2021-09-09 15:34 UTC
Last Modified:              2021-09-09 15:34 UTC
====================================================================== 
Summary:                    here document processing is underspecified
Description: 
The specification for a Here-Document (XCU 2.7.4) is lacking
some precision, and needs to be improved.

First, there is no reason to limit the kind of file descriptor
to being a regular file, special file, or a pipe.   Note that
the XBD 3.164 definition of "File" includes:

        File types include regular file, character special file, block
special
        file, FIFO special file, symbolic link, socket, and directory.
        Other types of files may be supported by the implementation.

from which it appears that block/character/FIFO special files exist,
but that sockets, directories, symbolic links, and other types supported
by the implementation are not special files (though there is no actual
definition of a "special file").   While it is unlikely (to say the least)
that a symbolic link or directory would be a useful file type for a
here-document, sockets or other implementation types might be.  The
wording of the standard should allow for that possibility.

Second, it is not precisely specified whether the "input lines"
which are to be stripped of tab characters are the lines in
the input, as presented to the shell, lines in the input, after
line joining (by the \<newline> combination, when that is applied)
has been carried out, or the lines to be input to the command to
which the redirection operator is applied.

Fortunately all shells seem to agree that tabs are stripped from
lines after line joining (when it applies) but before any expansions
are performed which might create more leading tab characters.

This should be precisely specified.

Third, it is not clear whether or not the end delimiter can be
formed from joined lines, or whether it must appear literally
in the input stream.

For this one shells are not in agreement, some initially treat
the end delimiter as part of the here document, and so perform
line joining, discovering the end delimiter after that, and then
removing it from the here document.   Other shells look for the
end delimiter first (after joining previous lines, so a line
which looks like the end delimiter, but which is a continuation
of a previous line, will not be the end delimiter) and do not
permit it to be formed from joined lines.  Since there is no
good reason for an application to ever split the end delimiter
over multiple lines in real code (as distinct from torture
tests) this can be made explicitly unspecified - applications
should not rely upon either behaviour.

Note that there is another open issue, relating to which <newline> is the
<newline> after which a here document begins, these two are orthoganal,
but this one, being simpler, should probably be processed first.
Desired Action: 
In line 75364 change the words
<blockquote>or a pipe</blockquote>
to
<blockquote>a pipe, or some other type of file</blockquote>


In line 75369 change the words
<blockquote>shall be expanded</blockquote>
to
<blockquote>shall be expanded as the redirection operator is
performed, each time it is performed,</blockquote>



In lines 75374-5 change the words
<blockquote>stripped from input lines and the line containing
the trailing delimiter.</blockquote>
to
<blockquote>stripped from input lines after <em>\&lt;newline&gt;
line joining (when it applies) last been performed and the line
containing the trailing delimiter.
It is unspecified whether the line containing the trailing delimiter
is subject to this line joining in any case.
Tab stripping occurs as the here document text is read from the shell
input stream, and is not repeated after any expansions that are
required have occurred.</blockquote>


Please adjust the actual wording applied to be more pleasing.

====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2021-09-09 15:34 kre            New Issue                                    
2021-09-09 15:34 kre            Name                      => Robert Elz      
2021-09-09 15:34 kre            Section                   => XCU 2.7.4       
2021-09-09 15:34 kre            Page Number               => 2362            
2021-09-09 15:34 kre            Line Number               => 75362-75377     
======================================================================


  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
      • Re:... Robert Elz via austin-group-l at The Open Group
        • ... Geoff Clare via austin-group-l at The Open Group
        • ... Robert Elz via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group

Reply via email to