|Anonymous | Login||2022-09-25 07:56 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0001521||[1003.1(2016/18)/Issue7+TC2] Shell and Utilities||Objection||Error||2021-09-09 15:34||2022-01-06 17:26|
|Final Accepted Text|
|Summary||0001521: here document processing is underspecified|
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.
In line 75364 change the words
or a pipe
a pipe, or some other type of file
In line 75369 change the words
shall be expanded
shall be expanded as the redirection operator is
In lines 75374-5 change the words
stripped from input lines and the line containing
stripped from input lines after <backslash><newline>
Please adjust the actual wording applied to be more pleasing.
|Tags||No tags attached.|
edited on: 2021-09-09 15:42
Oops, sorry, I see I missed a < /em > after the > after newline...
And it should say "has been performed" not "last been performed"
No idea how my fingers came up with that one.
|I have updated the desired action to fix the problems noted in Note: 0005497. (I removed the starting < em > rather than adding an ending < /em > as italics would be incorrect there anyway.)|
|See bug 1036 Note: 0005561 for a proposed resolution.|
|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|
|2021-09-09 15:37||kre||Note Added: 0005497|
|2021-09-09 15:39||kre||Note Edited: 0005497|
|2021-09-09 15:42||kre||Note Edited: 0005497|
|2021-09-10 08:41||geoffclare||Interp Status||=> ---|
|2021-09-10 08:41||geoffclare||Note Added: 0005498|
|2021-09-10 08:41||geoffclare||Desired Action Updated|
|2021-09-10 08:47||geoffclare||Relationship added||related to 0001036|
|2021-09-10 08:47||geoffclare||Relationship added||related to 0001043|
|2021-09-10 11:09||geoffclare||Desired Action Updated|
|2021-12-17 15:05||geoffclare||Note Added: 0005562|
|2022-01-06 17:24||Don Cragun||Status||New => Closed|
|2022-01-06 17:24||Don Cragun||Resolution||Open => Duplicate|
|2022-01-06 17:26||Don Cragun||Relationship replaced||duplicate of 0001036|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|