View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001037 | 1003.1(2013)/Issue7+TC1 | Shell and Utilities | public | 2016-03-23 14:26 | 2022-07-25 15:04 |
| Reporter | joerg | Assigned To | |||
| Priority | normal | Severity | Objection | Type | Omission |
| Status | Closed | Resolution | Rejected | ||
| 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. | ||||
|
|
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? |
|
|
Regarding the last paragraph in 0001037:0003102 this is being addressed in TC2. See 0000890 |
|
|
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. |
|
|
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 |
|
|
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.)" |
| 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 |
| 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 |
