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
0001037 [1003.1(2013)/Issue7+TC1] Shell and Utilities Objection Omission 2016-03-23 14:26 2022-07-25 15:04
Reporter joerg View Status public  
Assigned To
Priority normal Resolution Rejected  
Status Closed  
Name Jörg Schilling
Organization Fraunhofer FOKUS
User Reference
Section 2.10.1
Page Number 2352
Line Number 74936 - 74940
Interp Status ---
Final Accepted Text
Summary 0001037: The grammar for here documents misses the data body and the final EOF condition
Description The current shell grammar only describes the first line of the here
documents and misses to mention the body and the end indication.
Desired Action Add a useful grammar to describe a whole here document
Tags No tags attached.
Attached Files

- Relationships
related to 0001036Applied Errors/Omissions in specification of here document redirection 
related to 0000890Closed Here-document in a command string (sh -c) 
related to 0001043Closed Which newline starts collection of here document data? 

-  Notes
(0003102)
kre (reporter)
2016-03-23 23:53

I would suggest that a grammar would be overkill, Here docs are just
(essentially) single or double quoted strings (the only difference is
that the quote character itself is not a quote character inside, but
just a character). Single quoted ones (ones where the delimiter word
on the redirection was quoted) are literally just strings, no other
processing at all, except leading tab removal from each line if requested.

Double quoted ones (without a quoted delimiter word) are expanded in exactly
the same way as "" strings (except $@ in there is either undefined, or treated
the same as $* - multiple fields makes no sense). They also have leading tabs
removed from each line when first read if requested.

All that's left is the end delimiter, which is the same in each case, and is
just the (quote removed) delimiter word. If tab stripping is happening it
happens before looking for the end string, which (after tab stripping) must be
the whole line (though it need not be followed by a \n, EOF is sufficient as
an alternative.)

Is there really a need to state that explicitly, or more explicitly than it
already is?

What would be more useful would be to indicate the method (if any in
particular is expected) that the data is given to the command - should it
be placed in a file, and the file opened, and set to the appropriate fd for
the process, or can a pipe be used instead? That is, does the file need
to allow lseek(fd, SEEK_SET, 0L) and similar?
(0003106)
geoffclare (manager)
2016-03-24 09:29

Regarding the last paragraph in Note: 0003102 this is being addressed in TC2. See 0000890
(0003107)
joerg (reporter)
2016-03-24 10:32

The remarks in Note: 3102 seem to be unrelated to my report.

Note that your lseek() related remark is not related to the grammar and
that the actual content, (whether quoted or not) is also something
different.

The intention is a correct grammar that can be used to verify the shell.

The current grammar is far from being usable and a program that creates
shell code from that grammar causes syntax errors from all known shells
not only related to the missing here document body and end marker.
(0003108)
kre (reporter)
2016-03-24 16:10

Re:
    Regarding the last paragraph in Note: 0003102 this is being addressed in
    TC2. See 0000890
(note 3106)

I had seen that one (890) but after I looked at the description of the problem
reported, it did not seem related to the issue I was concerned with - so I did
not go on to read the attached note with the "add this sentence" part included.
Sorry. And yes, when that is added it will resolve the issue.

And Joerg, I know that 3102 was not really related to your report (other than
the part that says a grammar is not really needed), though it is true that
I thought your report was about the content of the here doc.

I suspect that the reason that the grammar doesn't include anything more, is
because it is an entirely lexical object - when a heredoc redirect operator
has been scanned, then after the next newline token, lines of text are
read, until a line that is the end word is encountered, that data is saved
and associated with the appropriate redirect token, but otherwise nothing even notices it ever existed. I am not sure how the grammar could describe that.
The one issue it could deal with is the one of which newline token is the
"next" one, but that is the subject of another conversation I believe.

kre
(0004034)
geoffclare (manager)
2018-05-15 14:39

The absence of the here-document body (and end marker) from the grammar is intentional. See XRAT C.2.10:

"Note that the body of here-documents are handled by token recognition (see XCU Section 2.3, on page 2347) and do not appear in the grammar directly. (However, the here-document I/O redirection operator is handled as part of the grammar.)"

- Issue History
Date Modified Username Field Change
2016-03-23 14:26 joerg New Issue
2016-03-23 14:26 joerg Name => Jörg Schilling
2016-03-23 14:26 joerg Organization => Fraunhofer FOKUS
2016-03-23 14:26 joerg Section => 2.10.1
2016-03-23 14:26 joerg Page Number => 2352
2016-03-23 14:26 joerg Line Number => 74936 - 74940
2016-03-23 23:53 kre Note Added: 0003102
2016-03-24 09:29 geoffclare Note Added: 0003106
2016-03-24 10:32 joerg Note Added: 0003107
2016-03-24 16:10 kre Note Added: 0003108
2017-03-02 16:18 nick Relationship added related to 0001036
2017-03-23 16:11 nick Relationship added related to 0001043
2017-05-11 13:42 kre Note Added: 0003689
2017-05-11 13:47 kre Note Deleted: 0003689
2018-05-15 14:39 geoffclare Note Added: 0004034
2022-07-21 22:33 Don Cragun Relationship added related to 0000890
2022-07-25 15:04 Don Cragun Interp Status => ---
2022-07-25 15:04 Don Cragun Status New => Closed
2022-07-25 15:04 Don Cragun Resolution Open => Rejected


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