View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001567 | Issue 8 drafts | Shell and Utilities | public | 2022-03-11 04:48 | 2022-04-21 15:32 |
| Reporter | calestyo | Assigned To | |||
| Priority | normal | Severity | Editorial | Type | Clarification Requested |
| Status | Closed | Resolution | Rejected | ||
| Product Version | Draft 2.1 | ||||
| Name | Christoph Anton Mitterer | ||||
| Organization | |||||
| User Reference | |||||
| Section | sh utility | ||||
| Page Number | 3143 | ||||
| Line Number | see below | ||||
| Final Accepted Text | |||||
| Summary | 0001567: ambiguous description when sh is invoked with multiple of -s, -c and command_file | ||||
| Description | From the SYNOPSIS (line 106441 and following) one could deduce that it's simply not allowed to use any of -c, -s and command_file together, however, all shells that I could test here accept arbitrary combinations of these. 1) In OPTIONS: -c (line 106463 and following) says: >Read commands from the command_string operand. >... >No commands shall be read from the standard >input. and -s (line 106472) says: > Read commands from the standard input. The former might indicate that that -c overrides -s, however that's IMO not really clear, because -s could also considered to override the whole option -c and thus the "No commands shall be read from the standard input." wouldn't apply. That -c explicitly mentions that no commands are read from stdin (in addition to the SYNOPSIS) could even taken as implication that it's allowed to specify both... unless this note is meant to indicate that -c wouldn't do both: execute the command_string AND further commands read from stdin. However if that was meant, it wouldn't be really clear either. 2) In STDIN: Line 106507-106509 say: > The standard input shall be used only if one of > the following is true: > • The −s option is specified. > • The −c option is not specified and no operands > are specified. Unless it were clearly forbidden to use any of -c, -s and command_file together, the above would be wrong, e.g. if -s and -c were both used and -c’s "No commands shall be read from the standard input." would override the -s ... it wouldn't read from stdin, just because of the -s. The same when -s is combined with a command_file operand. | ||||
| Desired Action | Clarify, whether any of -c, -s and command_file are allowed to be used together or whether this is forbidden (at least bash and dash allow it already). If it's allowed, clarify whether the results are defined or implementation specific, i.e. whether there is an order of precedence, like: 1. -c 2. command_file 3. -s 4. neither of these (thus also stdin). Especially it should also be made clear, whether commands are only allowed to be read from ONE of these sources, or whether an implementation could e.g. chose to have "sh -s -c date" cause first date to be executed and then further commands to be read from stdin. | ||||
| Tags | No tags attached. | ||||
|
|
As noted in the first paragraph of the Description section of this bug report, there are three synopsis forms for invoking the sh utility. The form on P3143, L106442-106443 includes an optional command_file operand but no -c option and no -s option. The form on L106444-106445 has a mandatory -c option but no command_file operand and no -s option. And the form on L106446-106447 has a mandatory-s option but no command_file operand and no -c option. This means that if you invoke sh with more than one of command_file, -c, or -s the behavior is unspecified. If you invoke a standard conforming sh utility with more than one of those three, that shell is allowed to do absolutely anything it chooses to do with that combination. It can choose to accept the first one of those three that it finds and ignore the others, it can choose to accept the last one it finds on the command line and ignore the others, it can report an error and refuse to execute any commands that might have been requested to be executed, or anything else that the person who maintains that shell thinks might be appropriate. A conforming application is not allowed to invoke sh with more than one of command_file, -c, or -s explicitly because the behavior that results from doing that is unspecified. What the standard says happens when you use -c alone says absolutely nothing about what happens if you also use -s or supply a command_file operand. What the standard says happens when you use the -s option says absolutely nothing about what happens if you also use the -c option or supply a command_file operand. What the standard says happens when you supply a command_file operand says absolutely nothing about what happens if you also use -c or -s There is no reason for the standard to list any set of possible things that might happen when you invoke a standard utility with arguments that do not match any synopsis form in the standard. |
|
|
Don's analysis isn't quite correct. It is simply impossible in sh to combine either -c 0r -s with a command_file - each of the -c and -s options defines quite explicitly what the non-flag args mean when they are given, and command_file is not in the list for either. Note that an argument string does not become a "command_file" just because it happens to be able to be interpreted as a path name, which if resolved, would allow a file containing sh commands to be read. The only case not clear is combining -c and -s which is the one case where it is (kind of) possible to do something different between different shells, and still be (almost) conforming. I support Don's conclusions however, nothing needs to change here, conforming apps should not be attempting to use -c and -s together, and what the shell does if they do, or if a script does "set -s" can all just remain unspecified. FWIW, the NetBSD sh allows -cs - it runs the command string (as for bare -c) which does not read any commands from stdin (as required) and then implements the -s, and after the -c processing is finished (the -c set $0 already, which -s normally does not do, and the command_string has already been consumed, but if one treats the "[argument ...] part of the -c synopsis as being the same [argument ...] that's in the -s synopsis, we come close enough. This is definitely not required by the standard, and I have only ever found one or two minor uses (it allows examining the internal state of the shell after a -c command line has been executed, which can help with some debugging) and a shell which simply issues a usage message when both -c and -s is used is just fine. |
|
|
As said, I'm fine with that simply being unspecified, though I thought it could make sense to explicitly state this. In principle this already follows from 12.1 Utility Argument Syntax, page 199, line 7062,... which is why I'd be fine if you chose to simply close this as invalid. However, there are utilities, where the synopsis already indicates that options are mutually exclusive, but this is later relaxed in the description. Take e.g. cd, page 2516, lines 82446-82447 (which indicate -P and -L being mutually exclusive and behaviour thus undefined if bot are given), but 2517, line 82527 actually specifies the behaviour if both are given. And as mentioned before... if it's anyway clear from the synopsis, that using -c and -s at the same time is undefined, why does "-c" then mention that "No commands shall be read from the standard input."? Either this seems superfluous, or it seems like a requirement that *if* and implementation chooses to allow both, then it would still not be allowed to read any further commands from stdin?! |
|
|
As noted in the other comments, no change to the standard is needed. Therefore, this bug has been rejected. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2022-03-11 04:48 | calestyo | New Issue | |
| 2022-03-11 04:48 | calestyo | Name | => Christoph Anton Mitterer |
| 2022-03-11 04:48 | calestyo | Section | => sh utility |
| 2022-03-11 04:48 | calestyo | Page Number | => 3143 |
| 2022-03-11 04:48 | calestyo | Line Number | => see below |
| 2022-03-11 06:05 | Don Cragun | Note Added: 0005741 | |
| 2022-03-11 06:06 | Don Cragun | Note Edited: 0005741 | |
| 2022-03-11 06:08 | Don Cragun | Note Edited: 0005741 | |
| 2022-03-11 07:23 | kre | Note Added: 0005742 | |
| 2022-03-11 17:57 | calestyo | Note Added: 0005743 | |
| 2022-04-21 15:28 | Don Cragun | Status | New => Closed |
| 2022-04-21 15:28 | Don Cragun | Resolution | Open => Rejected |
| 2022-04-21 15:32 | Don Cragun | Note Added: 0005813 |
