View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000989 | 1003.1(2008)/Issue 7 | Shell and Utilities | public | 2015-10-09 13:39 | 2016-07-14 15:57 |
| Reporter | joerg | Assigned To | ajosey | ||
| Priority | normal | Severity | Editorial | Type | Error |
| Status | Closed | Resolution | Duplicate | ||
| Name | Jörg Schilling | ||||
| Organization | |||||
| User Reference | |||||
| Section | 2.6.2 | ||||
| Page Number | 2328-2329 | ||||
| Line Number | 73954,73980,73981 | ||||
| Interp Status | --- | ||||
| Final Accepted Text | |||||
| Summary | 0000989: Contradicting claims for shell parameter substitution | ||||
| Description | On line 73954, the text says for "Assign default values": In all cases, the final value of parameter shall be substituted. On lines 73980/81, the text says: In all cases shown with ‘‘substitute’’, the expression is replaced with the value shown. In all cases shown with ‘‘assign’’, parameter is assigned that value, which also replaces the expression. BTW; I understand "which" as related to "that value". This is a case that matches this test case: unset unsetvar; printf '%s\n' ${unsetvar="foo bar"} where the Bourne Shell prints: foo bar and ksh prints: foo bar It seems that the Bourne Shell is aligned with the second text (and substitutes "word") while ksh is aligned with the first text (and substitutes $parameter after the assignement). | ||||
| Desired Action | Either allow both variants or correct one of both descriptions after deciding on which version should be correct. | ||||
| Tags | No tags attached. | ||||
|
|
I don't see any conflict here. It is clear from "parameter is assigned that value, which also replaces the expression" that the value assigned to parameter is the value that replaces the expression. The detail of what value is assigned to parameter is covered in the earlier text (and is modified by TC2). The table and the paragraph after it are just there to summarize the effect of a colon; they don't need to give any details of how the assignment is done, just a statement about which cases cause an assignment to be performed. |
|
|
After looking at this again (I was thinking of both printf arguments as quoted, but they aren't), the effect should be the same as if: unset unsetvar; unsetvar = "foo bar" printf '%s\n' ${unsetvar} were used. While both are storing "foo bar", not simply "foo", because the ${..} expression isn't double quoted also, it is ksh that is properly storing <foo bar>, after quote removal on =word, and then doing field splitting after the substitution. Bourne Shell is behaving as if <"foo bar"> is getting stored, and the stored quotes override the field splitting, which is more a bug with the TC2 changes, imo. |
|
|
The description compares ksh with the original Bourne Shell, not with bash. Bash currently behaves the same as ksh (it changed somewhere between bash 4.1.5 and 4.2.37). |
|
|
yes, ty for spotting it. Note edited. |
|
|
The Bourne Shell follows the second description, as it assigns "value" and replaces the expresssion by the "value". Given that the "value" is a quoted string, there is no word splitting and thus printf prints only one line. Ksh however followes the first text and assigns the "value" and then expands the variable "parameter". Given that ${parameter} is not quoted, work splitting applies and printf prints two lines. BTW: the second text was taken from the Bourne Shell man page and the first text was taken from the ksh man page that is in conflict with the Bourne Shell man page. |
|
|
This was covered and discussed as part of http://austingroupbugs.net/view.php?id=221. There is an example in there that directly addresses this case. Bash changed as a result of that interpretation. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-10-09 13:39 | joerg | New Issue | |
| 2015-10-09 13:39 | joerg | Status | New => Under Review |
| 2015-10-09 13:39 | joerg | Assigned To | => ajosey |
| 2015-10-09 13:39 | joerg | Name | => Jörg Schilling |
| 2015-10-09 13:39 | joerg | Section | => 2.6.2 |
| 2015-10-09 13:39 | joerg | Page Number | => 2328-2329 |
| 2015-10-09 13:39 | joerg | Line Number | => 73954,73980,73981 |
| 2015-10-09 15:11 | geoffclare | Note Added: 0002870 | |
| 2015-10-11 18:19 | shware_systems | Note Added: 0002871 | |
| 2015-10-11 18:20 | shware_systems | Note Edited: 0002871 | |
| 2015-10-12 08:30 | geoffclare | Note Added: 0002872 | |
| 2015-10-12 10:29 | shware_systems | Note Edited: 0002871 | |
| 2015-10-12 10:31 | shware_systems | Note Added: 0002873 | |
| 2015-10-12 14:34 | joerg | Note Added: 0002874 | |
| 2015-10-12 14:35 | joerg | Note Edited: 0002874 | |
| 2015-10-12 14:38 | joerg | Note Edited: 0002874 | |
| 2015-10-12 18:31 | chet_ramey | Note Added: 0002875 | |
| 2015-10-15 15:38 | nick | Relationship added | related to 0000221 |
| 2016-07-14 15:56 | Don Cragun | Relationship replaced | duplicate of 0000221 |
| 2016-07-14 15:57 | geoffclare | Interp Status | => --- |
| 2016-07-14 15:57 | geoffclare | Status | Under Review => Closed |
| 2016-07-14 15:57 | geoffclare | Resolution | Open => Duplicate |
