Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0000989 [1003.1(2008)/Issue 7] Shell and Utilities Editorial Error 2015-10-09 13:39 2016-07-14 15:57
Reporter joerg View Status public  
Assigned To ajosey
Priority normal Resolution Duplicate  
Status Closed  
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.
Attached Files

- Relationships
duplicate of 0000221Appliedajosey poor wording about even quotes in double quoted parameter expansion 

-  Notes
(0002870)
geoffclare (manager)
2015-10-09 15:11

 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.
(0002871)
shware_systems (reporter)
2015-10-11 18:19
edited on: 2015-10-12 10:29

 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.
(0002872)
geoffclare (manager)
2015-10-12 08:30

 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).
(0002873)
shware_systems (reporter)
2015-10-12 10:31

 yes, ty for spotting it. Note edited.
(0002874)
joerg (reporter)
2015-10-12 14:34
edited on: 2015-10-12 14:38

 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.
(0002875)
chet_ramey (reporter)
2015-10-12 18:31

 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.

- Issue History
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

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