Re: Another $@ expansion issue
Date:Thu, 28 Feb 2019 12:04:25 +
From:Geoff Clare
Message-ID: <20190228120425.GA10849@lt2.masqnet>
To take this in something of a reverse order...
| As far as I can see this agrees with the examples in XRAT C.2.5.2.
It was intended to - nothing there was supposed to be even slightly
controversial, and I was very surprised that bosh managed to get it
all wrong (everything else gets the same results).
The point was just that in
${var=word}
"word" is expanded in a context where there is no field splitting
(quotes are irrelevant to that). This is just the same as in
var=word
The latter is quite clear in the standard (XCU 2.9.1 point 4):
4. Each variable assignment shall be expanded for tilde expansion,
parameter expansion, command substitution, arithmetic expansion,
and quote removal prior to assigning the value.
"field splitting" is not mentioned. And isn't done (nothing is new here,
this is as it has always been).
On the other hand, in 2.6.2 ...
${parameter:=[word]}Assign Default Values. If parameter is unset
or null, the expansion of word (or an empty
string if word is omitted) shall be assigned
to parameter. [...]
I had not noticed at the time (but have now) that this is actually
specified in 2.6.2 ... but it occurs at the bottom of the page before
the descriptions of the ${varword} expansions, and I did not
think to look backwards, or I would have just quoted this:
each case that a value of word is needed (based on the state
of parameter, as described below), word shall be subjected to
tilde expansion, parameter expansion, command substitution, and
arithmetic expansion. [...]
No mention of field splitting there (but field splitting, in an
appropriate context, does happen to the results of the expansion in
which the expansion of word was used). That is, the context matters.
Generally when the standard just uses "the expansion" or "word expansions"
it means "all of them", eg: back in 2.9.1, this time, point 2
2. The words that are not variable assignments or redirections
shall be expanded. [...]
Where that (and it is used in other places that way) means "apply all of the
expansions" - which does include field splitting.
As written, those words from 2.6.2 might be read to imply the same (and
I think I may have seen implementations, once, where it was) and that
field splitting should be performed.If that happens, how one would
assign the result to parameter is completely unspecified however, there
is nothing (at least in shells that don't implement arrays) which explains
in any way how to assign multiple words (fields) to a variable. That's
because it simply isn't done.
So, while it is not strictly necessary, it might be an idea to add
to something to "the expansion of word" (in all of the cases) to
be more like "the expansion of word as indicated earlier in this section"
or something - just to avoid others not noticing what the previous
page said.
All of this stuff (in my previous message) was just to indicate that the two
bullet points in the description of $@ can be deleted as they add nothing
(or could be made to add nothing) useful to the definition.
As currently stated, the 2nd one allows only $(param-word} and ${param+word}
(explicitly) and makes all others unspecified (if $@ is used in word),
so I needed to show that those two are the only two where the word appears
in a context where field splitting happens. Having done that all we need
is to say that $@ is unspecified when in a context where field splitting
does not happen. (Field splitting does eventually happen to the "word"
in ${var+word} - (or '-' instead of '+') if it is used (otherwise it isn't
expanded, and whether an expansion would be specified or not is irrelevant)
whereas it never does in the other cases (in ${var=word} it is the expansion
of var, after a value has been assigned to it that is field split, not the
expasion of word.
The only one where there's even a possibility of doubt about that is the '='
operator case - hence I gave the (undisputed really) example to show that
field splitting does not happen to the expansion of word in ${param=word}
| I don't like this rearrangement because it is a completely different
| structure from the one for '*'.
The text for $* would need some changes as well.Certainly I agree that
having them aligned is a good thing, as they are so similar, and it makes
it much easier to spot what the differences between the two are if they are
written using similar language, and in a similar order.
But I don't think the differences would end up being quite as big as you
imagine - though the way the different parts would be shown would differ from
the way it is done now (see more below). I do agree however that the way I
[1003.1(2013)/Issue7+TC1 0000680]: pselect EINTR error case clarification
The following issue has been set as RELATED TO issue 0001186. == http://austingroupbugs.net/view.php?id=680 == Reported By:mdempsky Assigned To: == Project:1003.1(2013)/Issue7+TC1 Issue ID: 680 Category: System Interfaces Type: Enhancement Request Severity: Editorial Priority: normal Status: Resolved Name: Matthew Dempsky Organization: OpenBSD User Reference: Section:pselect Page Number:1539 Line Number:50094 Interp Status: --- Final Accepted Text:See Desired Action Resolution: Accepted Fixed in Version: == Date Submitted: 2013-04-20 15:28 UTC Last Modified: 2013-04-25 16:13 UTC == Summary:pselect EINTR error case clarification == Relationships ID Summary -- related to 0001186 pselect specification allows for race c... == Issue History Date ModifiedUsername FieldChange == 2013-04-20 15:28 mdempsky New Issue 2013-04-20 15:28 mdempsky Name => Matthew Dempsky 2013-04-20 15:28 mdempsky Organization => OpenBSD 2013-04-20 15:28 mdempsky Section => pselect 2013-04-25 16:13 nick Page Number => 1539 2013-04-25 16:13 nick Line Number => 50094 2013-04-25 16:13 nick Interp Status => --- 2013-04-25 16:13 nick Final Accepted Text => See Desired Action 2013-04-25 16:13 nick Status New => Resolved 2013-04-25 16:13 nick Resolution Open => Accepted 2013-04-25 16:13 nick Tag Attached: tc2-2008 2019-02-28 16:52 eblake Relationship added related to 0001186 ==
[1003.1(2016)/Issue7+TC2 0001186]: pselect specification allows for race condition that pselect was created to avoid
The following issue has been set as RELATED TO issue 680. == http://austingroupbugs.net/view.php?id=1186 == Reported By:davmac Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1186 Category: System Interfaces Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: Davin McCall Organization: User Reference: Section:pselect Page Number:1554-1555 Line Number:50880 Interp Status: --- Final Accepted Text: == Date Submitted: 2018-02-02 18:47 UTC Last Modified: 2019-02-28 16:52 UTC == Summary:pselect specification allows for race condition that pselect was created to avoid == Relationships ID Summary -- related to 680 pselect EINTR error case clarification == Issue History Date ModifiedUsername FieldChange == 2018-02-02 18:47 davmac New Issue 2018-02-02 18:47 davmac Name => Davin McCall 2018-02-02 18:47 davmac Section => pselect 2018-02-02 18:47 davmac Page Number => 1554-1555 2018-02-02 18:47 davmac Line Number => 50880 2018-02-02 19:33 davmac Note Added: 0003917 2018-02-04 20:00 jilles Note Added: 0003918 2019-02-28 16:52 eblake Relationship added related to 680 ==
[1003.1(2016)/Issue7+TC2 0001185]: Additional 3rd option for getting line size.
The following issue has been RESOLVED. == http://austingroupbugs.net/view.php?id=1185 == Reported By:dannyniu Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1185 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: Resolved Name: DannyNiu/NJF Organization: User Reference: Section:more Page Number: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/more.html Line Number:EXTENDED DESCRIPTION Interp Status: --- Final Accepted Text:http://austingroupbugs.net/view.php?id=1185#c4260 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2018-02-02 04:13 UTC Last Modified: 2019-02-28 16:48 UTC == Summary:Additional 3rd option for getting line size. == Relationships ID Summary -- related to 0001151 Introduce new signal SIGWINCH and funct... == Issue History Date ModifiedUsername FieldChange == 2018-02-02 04:13 dannyniu New Issue 2018-02-02 04:13 dannyniu Name => DannyNiu/NJF 2018-02-02 04:13 dannyniu Section => more 2018-02-02 04:13 dannyniu Page Number => http://pubs.opengroup.org/onlinepubs/9699919799/utilities/more.html 2018-02-02 04:13 dannyniu Line Number => EXTENDED DESCRIPTION 2018-02-02 04:24 dannyniu Note Added: 0003916 2018-02-13 23:54 kreNote Added: 0003920 2018-02-14 02:29 nick Note Added: 0003921 2018-02-14 04:53 shware_systems Note Added: 0003922 2018-02-14 05:03 shware_systems Note Edited: 0003922 2018-02-14 05:20 shware_systems Note Edited: 0003922 2018-02-14 10:44 kreNote Added: 0003923 2018-02-14 18:22 shware_systems Note Added: 0003924 2019-02-20 12:04 geoffclare Note Added: 0004260 2019-02-25 16:46 nick Relationship added related to 0001151 2019-02-28 16:48 geoffclare Interp Status => --- 2019-02-28 16:48 geoffclare Final Accepted Text => http://austingroupbugs.net/view.php?id=1185#c4260 2019-02-28 16:48 geoffclare Status New => Resolved 2019-02-28 16:48 geoffclare Resolution Open => Accepted As Marked ==
[1003.1(2016)/Issue7+TC2 0001184]: strftime %C padding character unspecified
The following issue has been set as DUPLICATE OF issue 472. == http://austingroupbugs.net/view.php?id=1184 == Reported By:dennisw Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1184 Category: System Interfaces Type: Omission Severity: Objection Priority: normal Status: Closed Name: Dennis Wölfing Organization: User Reference: Section:strftime Page Number:2045 Line Number:65551-65557 Interp Status: --- Final Accepted Text: Resolution: Duplicate Duplicate: 0 Fixed in Version: == Date Submitted: 2018-01-31 16:49 UTC Last Modified: 2019-02-28 16:36 UTC == Summary:strftime %C padding character unspecified == Relationships ID Summary -- duplicate of472 strftime %C does not account for sign c... related to 466 date +%C problem == Issue History Date ModifiedUsername FieldChange == 2018-01-31 16:49 denniswNew Issue 2018-01-31 16:49 denniswName => Dennis Wölfing 2018-01-31 16:49 denniswSection => strftime 2018-01-31 16:49 denniswPage Number => 2045 2018-01-31 16:49 denniswLine Number => 65551-65557 2018-02-01 09:19 geoffclare Note Added: 0003915 2019-02-21 17:24 geoffclare Note Added: 0004262 2019-02-21 17:24 geoffclare Interp Status => --- 2019-02-21 17:24 geoffclare Final Accepted Text => http://austingroupbugs.net/view.php?id=1184#c4262 2019-02-21 17:24 geoffclare Status New => Resolved 2019-02-21 17:24 geoffclare Resolution Open => Accepted As Marked 2019-02-21 17:25 geoffclare Tag Attached: tc3-2008 2019-02-21 17:28 eblake Relationship added related to 466 2019-02-21 17:29 eblake Relationship added related to 472 2019-02-21 17:31 eblake Note Added: 0004263 2019-02-25 16:51 nick Resolution Accepted As Marked => Reopened 2019-02-28 16:32 Don Cragun Final Accepted Text http://austingroupbugs.net/view.php?id=1184#c4262 => 2019-02-28 16:32 Don Cragun Status Resolved => Closed 2019-02-28 16:32 Don Cragun Resolution Reopened => Duplicate 2019-02-28 16:36 Don Cragun Relationship replacedduplicate of 472 ==
[1003.1(2008)/Issue 7 0000472]: strftime %C does not account for sign character
The issue 0001184 has been set as DUPLICATE OF the following issue. == http://austingroupbugs.net/view.php?id=472 == Reported By:markh Assigned To:ajosey == Project:1003.1(2008)/Issue 7 Issue ID: 472 Category: System Interfaces Type: Error Severity: Objection Priority: normal Status: Interpretation Required Name: Mark Harris Organization: User Reference: Section:strftime Page Number:2008 Line Number:63559 Interp Status: Pending Final Accepted Text:see http://austingroupbugs.net/view.php?id=472#c4270 == Date Submitted: 2011-07-07 08:37 UTC Last Modified: 2019-02-28 16:32 UTC == Summary:strftime %C does not account for sign character == Relationships ID Summary -- has duplicate 0001184 strftime %C padding character unspecified == Issue History Date ModifiedUsername FieldChange == 2011-07-07 08:37 markh New Issue 2011-07-07 08:37 markh Status New => Under Review 2011-07-07 08:37 markh Assigned To => ajosey 2011-07-07 08:37 markh Name => Mark Harris 2011-07-07 08:37 markh Section => strftime 2011-07-07 08:37 markh Page Number => 2008 2011-07-07 08:37 markh Line Number => 63559 2011-07-07 11:36 geoffclare Note Added: 886 2011-07-28 07:32 markh Note Added: 892 2011-08-11 15:38 eblake Note Added: 936 2011-08-11 15:40 eblake Interp Status => --- 2011-08-11 15:40 eblake Final Accepted Text => see http://austingroupbugs.net/view.php?id=472#c936 2011-08-11 15:40 eblake Status Under Review => Resolved 2011-08-11 15:40 eblake Resolution Open => Accepted As Marked 2011-08-11 15:40 eblake Tag Attached: issue8 2011-08-11 15:41 eblake Interp Status--- => Pending 2011-08-11 18:08 Don Cragun Status Resolved => Interpretation Required 2012-06-29 16:19 ajosey Interp StatusPending => Proposed 2012-06-29 16:19 ajosey Note Added: 0001301 2012-08-30 09:11 ajosey Interp StatusProposed => Approved 2012-08-30 09:11 ajosey Note Added: 0001342 2019-02-21 17:29 eblake Relationship added related to 0001184 2019-02-25 16:57 nick Resolution Accepted As Marked => Reopened 2019-02-25 17:05 nick Note Added: 0004266 2019-02-28 14:43 geoffclare Note Added: 0004270 2019-02-28 14:44 geoffclare Tag Detached: issue8 2019-02-28 16:32 geoffclare Interp StatusApproved => Pending 2019-02-28 16:32 geoffclare Final Accepted Text see http://austingroupbugs.net/view.php?id=472#c936 => see http://austingroupbugs.net/view.php?id=472#c4270 2019-02-28 16:32 geoffclare Resolution Reopened => Accepted As Marked 2019-02-28 16:32 geoffclare Tag Attached: tc3-2008 2019-02-28 16:36 Don Cragun Relationship replacedhas duplicate 0001184 ==
[1003.1(2016)/Issue7+TC2 0001184]: strftime %C padding character unspecified
The following issue has been CLOSED. == http://austingroupbugs.net/view.php?id=1184 == Reported By:dennisw Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1184 Category: System Interfaces Type: Omission Severity: Objection Priority: normal Status: Closed Name: Dennis Wölfing Organization: User Reference: Section:strftime Page Number:2045 Line Number:65551-65557 Interp Status: --- Final Accepted Text: Resolution: Duplicate Duplicate: 0 Fixed in Version: == Date Submitted: 2018-01-31 16:49 UTC Last Modified: 2019-02-28 16:32 UTC == Summary:strftime %C padding character unspecified == Relationships ID Summary -- related to 466 date +%C problem related to 472 strftime %C does not account for sign c... == Issue History Date ModifiedUsername FieldChange == 2018-01-31 16:49 denniswNew Issue 2018-01-31 16:49 denniswName => Dennis Wölfing 2018-01-31 16:49 denniswSection => strftime 2018-01-31 16:49 denniswPage Number => 2045 2018-01-31 16:49 denniswLine Number => 65551-65557 2018-02-01 09:19 geoffclare Note Added: 0003915 2019-02-21 17:24 geoffclare Note Added: 0004262 2019-02-21 17:24 geoffclare Interp Status => --- 2019-02-21 17:24 geoffclare Final Accepted Text => http://austingroupbugs.net/view.php?id=1184#c4262 2019-02-21 17:24 geoffclare Status New => Resolved 2019-02-21 17:24 geoffclare Resolution Open => Accepted As Marked 2019-02-21 17:25 geoffclare Tag Attached: tc3-2008 2019-02-21 17:28 eblake Relationship added related to 466 2019-02-21 17:29 eblake Relationship added related to 472 2019-02-21 17:31 eblake Note Added: 0004263 2019-02-25 16:51 nick Resolution Accepted As Marked => Reopened 2019-02-28 16:32 Don Cragun Final Accepted Text http://austingroupbugs.net/view.php?id=1184#c4262 => 2019-02-28 16:32 Don Cragun Status Resolved => Closed 2019-02-28 16:32 Don Cragun Resolution Reopened => Duplicate ==
[1003.1(2008)/Issue 7 0000472]: strftime %C does not account for sign character
The following issue has been UPDATED. == http://austingroupbugs.net/view.php?id=472 == Reported By:markh Assigned To:ajosey == Project:1003.1(2008)/Issue 7 Issue ID: 472 Category: System Interfaces Type: Error Severity: Objection Priority: normal Status: Interpretation Required Name: Mark Harris Organization: User Reference: Section:strftime Page Number:2008 Line Number:63559 Interp Status: Pending Final Accepted Text:see http://austingroupbugs.net/view.php?id=472#c4270 == Date Submitted: 2011-07-07 08:37 UTC Last Modified: 2019-02-28 16:32 UTC == Summary:strftime %C does not account for sign character == Relationships ID Summary -- related to 0001184 strftime %C padding character unspecified == Issue History Date ModifiedUsername FieldChange == 2011-07-07 08:37 markh New Issue 2011-07-07 08:37 markh Status New => Under Review 2011-07-07 08:37 markh Assigned To => ajosey 2011-07-07 08:37 markh Name => Mark Harris 2011-07-07 08:37 markh Section => strftime 2011-07-07 08:37 markh Page Number => 2008 2011-07-07 08:37 markh Line Number => 63559 2011-07-07 11:36 geoffclare Note Added: 886 2011-07-28 07:32 markh Note Added: 892 2011-08-11 15:38 eblake Note Added: 936 2011-08-11 15:40 eblake Interp Status => --- 2011-08-11 15:40 eblake Final Accepted Text => see http://austingroupbugs.net/view.php?id=472#c936 2011-08-11 15:40 eblake Status Under Review => Resolved 2011-08-11 15:40 eblake Resolution Open => Accepted As Marked 2011-08-11 15:40 eblake Tag Attached: issue8 2011-08-11 15:41 eblake Interp Status--- => Pending 2011-08-11 18:08 Don Cragun Status Resolved => Interpretation Required 2012-06-29 16:19 ajosey Interp StatusPending => Proposed 2012-06-29 16:19 ajosey Note Added: 0001301 2012-08-30 09:11 ajosey Interp StatusProposed => Approved 2012-08-30 09:11 ajosey Note Added: 0001342 2019-02-21 17:29 eblake Relationship added related to 0001184 2019-02-25 16:57 nick Resolution Accepted As Marked => Reopened 2019-02-25 17:05 nick Note Added: 0004266 2019-02-28 14:43 geoffclare Note Added: 0004270 2019-02-28 14:44 geoffclare Tag Detached: issue8 2019-02-28 16:32 geoffclare Interp StatusApproved => Pending 2019-02-28 16:32 geoffclare Final Accepted Text see http://austingroupbugs.net/view.php?id=472#c936 => see http://austingroupbugs.net/view.php?id=472#c4270 2019-02-28 16:32 geoffclare Resolution Reopened => Accepted As Marked ==
[1003.1(2016)/Issue7+TC2 0001230]: Require bc implementations to allow arrays as last parameter
The following issue has been RESOLVED. == http://austingroupbugs.net/view.php?id=1230 == Reported By:gavin_howard Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1230 Category: Shell and Utilities Type: Omission Severity: Comment Priority: normal Status: Resolved Name: Gavin Howard Organization: User Reference: Section:bc(1) Page Number:2526-2538 Line Number:81596-81614 Interp Status: --- Final Accepted Text:See http://austingroupbugs.net/view.php?id=1230#c4267. Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2019-02-21 17:30 UTC Last Modified: 2019-02-28 16:16 UTC == Summary:Require bc implementations to allow arrays as last parameter == Issue History Date ModifiedUsername FieldChange == 2019-02-21 17:30 gavin_howard New Issue 2019-02-21 17:30 gavin_howard Name => Gavin Howard 2019-02-21 17:30 gavin_howard Section => bc(1) 2019-02-21 17:30 gavin_howard Page Number => 2526-2538 2019-02-21 17:30 gavin_howard Line Number => 81596-81614 2019-02-25 15:58 shware_systems Note Added: 0004264 2019-02-25 16:29 joerg Note Added: 0004265 2019-02-25 16:48 shware_systems Note Edited: 0004264 2019-02-25 19:45 gavin_howard Note Added: 0004267 2019-02-25 19:58 gavin_howard Note Added: 0004268 2019-02-28 16:16 Don Cragun Interp Status => --- 2019-02-28 16:16 Don Cragun Final Accepted Text => See http://austingroupbugs.net/view.php?id=1230#c4267. 2019-02-28 16:16 Don Cragun Status New => Resolved 2019-02-28 16:16 Don Cragun Resolution Open => Accepted As Marked ==
Re: [1003.1(2008)/Issue 7 0000472]: strftime %C does not account for sign character
Shware Systems wrote, on 28 Feb 2019: > > The new wording still doesn't make explicit padding characters for wider > field widths than 3 shall be '0', not , to address Bug 1184. What's on > the etherpad does have this. The behaviour is explicitly unspecified if a conversion contains a field width without a flag. The flag determines the padding character. Regards, Geoff. > In a message dated 2/28/2019 9:46:28 AM Eastern Standard Time, > nore...@msnkbrown.net writes: > > -- > (0004270) geoffclare (manager) - 2019-02-28 > 14:43http://austingroupbugs.net/view.php?id=472#c4270 > -- > Interpretation responseThe standard is unclear on > this issue, and no conformance distinction canbe made between alternative > implementations based on this. This is beingreferred to the sponsor. > Rationale:-The standard should be consistent between %C, %G, and > %Y. > Notes to the Editor (not part of this > interpretation):--- > Change L63558-63562 from:If a minimum field width is > notspecified, the number of characters placed into the array pointed to > bys will be the number of digits in the year divided by 100 or > two,whichever is greater. [CX] If a minimum field width is specified, > thenumber of characters placed into the array pointed to by s will be > thenumber of digits in the year divided by 100 or the minimum field > width,whichever is greater.[/CX]to:If a minimum > fieldwidth is not specified: If the year is between 0 and > inclusive, two characters shall be placed into the array pointed to > bys, including a leading '0' if there would otherwise be only a > singledigit. [CX]If the year is less than 0 or greater than , > the number ofcharacters placed into the array pointed to by s shall be > the numberof digits and leading sign characters (if any) in the result of > dividingthe year by 100 and truncating, or two, whichever is greater.[/CX] > [CX] If a minimum field width is specified, the number of > charactersplaced into the array pointed to by s shall be the number of > digitsand leading sign characters (if any) in the result of dividing the year > by100 and truncating, or the minimum field width, whichever > isgreater.[/CX]On P2009 L63584 (G conversion) change "will" to > "shall". > On P2009 L63622 (Y conversion) change "will" to "shall". -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2008)/Issue 7 0000472]: strftime %C does not account for sign character
The new wording still doesn't make explicit padding characters for wider field
widths than 3 shall be '0', not , to address Bug 1184. What's on the
etherpad does have this.
Some may argue the minimum field width for "%+" should be 3, as well, as
required sign character ('+'/'-') plus 2 digits; to maintain alignments.
In a message dated 2/28/2019 9:46:28 AM Eastern Standard Time,
nore...@msnkbrown.net writes:
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=472
== Reported
By: markhAssigned To:
ajosey==
Project: 1003.1(2008)/Issue 7Issue ID:
472Category: System InterfacesType:
ErrorSeverity: ObjectionPriority:
normalStatus: Interpretation RequiredName:
Mark Harris Organization:
User Reference:
Section: strftime Page Number: 2008 Line
Number: 63559 Interp Status: Approved Final
Accepted Text: see http://austingroupbugs.net/view.php?id=472#c936
== Date
Submitted: 2011-07-07 08:37 UTCLast Modified:
2019-02-28 14:43
UTC==
Summary: strftime %C does not account for sign
character==Relationships
ID
Summary--related
to 0001184 strftime %C padding character
unspecified==
--
(0004270) geoffclare (manager) - 2019-02-28
14:43http://austingroupbugs.net/view.php?id=472#c4270
--
Interpretation responseThe standard is unclear on this
issue, and no conformance distinction canbe made between alternative
implementations based on this. This is beingreferred to the sponsor.
Rationale:-The standard should be consistent between %C, %G, and %Y.
Notes to the Editor (not part of this
interpretation):---
Change L63558-63562 from:If a minimum field width is notspecified,
the number of characters placed into the array pointed to bys will be
the number of digits in the year divided by 100 or two,whichever is greater.
[CX] If a minimum field width is specified, thenumber of characters placed into
the array pointed to by s will be thenumber of digits in the year divided by
100 or the minimum field width,whichever is
greater.[/CX]to:If a minimum fieldwidth is not
specified: If the year is between 0 and inclusive, two characters
shall be placed into the array pointed to bys, including a leading '0'
if there would otherwise be only a singledigit. [CX]If the year is
less than 0 or greater than , the number ofcharacters placed into the array
pointed to by s shall be the numberof digits and leading sign characters
(if any) in the result of dividingthe year by 100 and truncating, or two,
whichever is greater.[/CX] [CX] If a minimum field width is
specified, the number of charactersplaced into the array pointed to by s
shall be the number of digitsand leading sign characters (if any) in the result
of dividing the year by100 and truncating, or the minimum field width,
whichever isgreater.[/CX]On P2009 L63584 (G conversion) change
"will" to "shall".
On P2009 L63622 (Y conversion) change "will" to "shall".
Issue History Date Modified Username Field Change
==
2011-07-07 08:37 markh New Issue
2011-07-07 08:37 markh Status New => Under Review
2011-07-07 08:37 markh Assigned To => ajosey
2011-07-07 08:37 markh Name => Mark Harris
2011-07-07 08:37 markh Section => strftime
2011-07-07 08:37 markh Page Number => 2008
2011-07-07 08:37 markh Line Number => 63559
2011-07-07 11:36 geoffclare Note Added: 886
2011-07-28 07:32 markh Note Added: 892
2011-08-11 15:38 eblake Note Added: 936
2011-08-11 15:40 eblake Interp Status
[1003.1(2013)/Issue7+TC1 0001158]: Please, use dashs (i. e. "-") consistently in the document and make it searchable
The following issue has a resolution that has been APPLIED. == http://austingroupbugs.net/view.php?id=1158 == Reported By:safinaskar Assigned To: == Project:1003.1(2013)/Issue7+TC1 Issue ID: 1158 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: Applied Name: Askar Safin Organization: User Reference: Section:echo utility Page Number:2674 Line Number:87119 Interp Status: --- Final Accepted Text: Resolution: Accepted Fixed in Version: == Date Submitted: 2017-07-31 20:21 UTC Last Modified: 2019-02-28 15:06 UTC == Summary:Please, use dashs (i. e. "-") consistently in the document and make it searchable == -- (0004271) geoffclare (manager) - 2019-02-28 15:06 http://austingroupbugs.net/view.php?id=1158#c4271 -- This has now been fixed in the troff source. Issue History Date ModifiedUsername FieldChange == 2017-07-31 20:21 safinaskar New Issue 2017-07-31 20:21 safinaskar Name => Askar Safin 2017-07-31 20:21 safinaskar Section => echo utility 2017-07-31 20:21 safinaskar Page Number => 2674 2017-07-31 20:21 safinaskar Line Number => 87119 2017-07-31 20:38 nick Note Added: 0003810 2017-08-01 08:32 geoffclare Note Added: 0003811 2019-01-17 16:00 shware_systems Note Added: 0004213 2019-02-28 15:06 geoffclare Interp Status => --- 2019-02-28 15:06 geoffclare Note Added: 0004271 2019-02-28 15:06 geoffclare Status New => Applied 2019-02-28 15:06 geoffclare Resolution Open => Accepted ==
[1003.1(2008)/Issue 7 0000472]: strftime %C does not account for sign character
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=472 == Reported By:markh Assigned To:ajosey == Project:1003.1(2008)/Issue 7 Issue ID: 472 Category: System Interfaces Type: Error Severity: Objection Priority: normal Status: Interpretation Required Name: Mark Harris Organization: User Reference: Section:strftime Page Number:2008 Line Number:63559 Interp Status: Approved Final Accepted Text:see http://austingroupbugs.net/view.php?id=472#c936 == Date Submitted: 2011-07-07 08:37 UTC Last Modified: 2019-02-28 14:43 UTC == Summary:strftime %C does not account for sign character == Relationships ID Summary -- related to 0001184 strftime %C padding character unspecified == -- (0004270) geoffclare (manager) - 2019-02-28 14:43 http://austingroupbugs.net/view.php?id=472#c4270 -- Interpretation response The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale: - The standard should be consistent between %C, %G, and %Y. Notes to the Editor (not part of this interpretation): --- Change L63558-63562 from:If a minimum field width is not specified, the number of characters placed into the array pointed to by s will be the number of digits in the year divided by 100 or two, whichever is greater. [CX] If a minimum field width is specified, the number of characters placed into the array pointed to by s will be the number of digits in the year divided by 100 or the minimum field width, whichever is greater.[/CX]to:If a minimum field width is not specified: If the year is between 0 and inclusive, two characters shall be placed into the array pointed to by s, including a leading '0' if there would otherwise be only a single digit. [CX]If the year is less than 0 or greater than , the number of characters placed into the array pointed to by s shall be the number of digits and leading sign characters (if any) in the result of dividing the year by 100 and truncating, or two, whichever is greater.[/CX] [CX] If a minimum field width is specified, the number of characters placed into the array pointed to by s shall be the number of digits and leading sign characters (if any) in the result of dividing the year by 100 and truncating, or the minimum field width, whichever is greater.[/CX] On P2009 L63584 (G conversion) change "will" to "shall". On P2009 L63622 (Y conversion) change "will" to "shall". Issue History Date ModifiedUsername FieldChange == 2011-07-07 08:37 markh New Issue 2011-07-07 08:37 markh Status New => Under Review 2011-07-07 08:37 markh Assigned To => ajosey 2011-07-07 08:37 markh Name => Mark Harris 2011-07-07 08:37 markh Section => strftime 2011-07-07 08:37 markh Page Number => 2008 2011-07-07 08:37 markh Line Number => 63559 2011-07-07 11:36 geoffclare Note Added: 886 2011-07-28 07:32 markh Note Added: 892 2011-08-11 15:38 eblake Note Added: 936 2011-08-11 15:40 eblake Interp Status => --- 2011-08-11 15:40 eblake Final Accepted Text => see http://austingroupbugs.net/view.php?id=472#c936 2011-08-11 15:40 eblake Status Under Review => Resolved 2011-08-11 15:40 eblake Resolution Open => Accepted As Marked 2011-08-11 15:40 eblake Tag Attached: issue8
Re: Another $@ expansion issue
Robert Elz wrote, on 28 Feb 2019:
>
> | However, given that the most widely used modern shells produce a null
> | field, I believe we should make this unspecified rather than forcing
> | them to change.
>
> Then the question becomes just how we do that.
[snip]
> The problem is a tendency to go off on tangents filling in details, to
> try and get everything just right - but in the middle of what should be
> a fairly simple sentence (or sentences) - leading to something that is
> much too long, and where the original premise and final conclusion are
> separated by reams of text which are only barely related to the issue
> at hand.
>
> This can generally be solved by a rewrite which keeps all of the
> content (or the important parts anyway) but rearranges the order so
> the logical flow makes sense and anyone can follow.
The reason the '@' description is structured the way it is is because
when I drafted what became the current text, I started from the '*'
description and added in the extra quirks that '@' has. If '@' is
rearranged too much it will destroy the neat correspondence between
the two descriptions.
> Here there are 3 situations where $@ can be used, two of them have (or
> can have) specified results, the third is "anything else" and does not.
> What we need to do is get that set out at the beginning. What the specified
> result is for the two cases (contexts) where we have such a thing, and the
> extra requirements on the second one can be specified later.
>
> This would be helped if we weren't slightly mixed up about what it means
> to be a "context where field splitting will be performed" - we already got
> rid of the assumption that when IFS='' we no longer have such a context,
> we also need to get rid of the assumption that when a word is quoted we
> are not in a context where field splitting will be performed.
>
> Just as in the IFS='' case, quoting prevents any field splitting actually
> happening, it does not avoid us being in a context where field splitting
> could happen. The contexts where field splitting happens are exactly
> those where the standard says it happens.
That may be how it works in your mind, but it's not what the standard
says. The description of field splitting explicitly says it is only
performed for expansions that are not in double quotes ("the shell shall
scan the results of expansions and substitutions that did not occur in
double-quotes for field splitting and multiple fields can result").
In any case, I think it is worth keeping the clarification in the
descriptions of '@' and '*' that field splitting is applied to each of
the positional-parameter-derived initial fields individually.
[snip]
> This is where we should get to the part about:
>
> Expands to the positional parameters, starting from one, initially
> producing one field for each positional parameter that is set.
>
> except that at that point, I'd add this:
>
> If there are no positional parameters, the expansion of '@' shall
> generate zero fields, even when '@' is within double-quotes;
>
> which currently occurs later, except I would write it as
>
> If there are no positional parameters, the expansion of '@' shall
> produce nothing.
>
> (We still need to deal with "$@" ... that's coming later).
>
> That's what we want, double quotes or no double quotes, and embedded
> within a word or not. The "embedded within" shouldn't be connected to
> the case where there are no positional params, but to the case where
> there are, something like:
>
> If there are positional parameters, then any text preceding
> the $@ in the word being expanded shall be placed before, and
> joined to, the expansion of the first positional parameter, and
> any text following the $@ in the word being expanded shall be placed
> after, and joined to, the expansion of the final positional parameter.
> One field shall be generated for each positional parameter, that is,
> $# fields. If the '@' being expanded occurred within double quotes,
> then the expansion of each positional parameter is placed within
> double quotes in the fields generated. These double quotes are
> treated as copies of the original pair, and are later deleted by
> quote removal.
>
> Where there are no positional parameters, the $@ shall be
> deleted from the word, and whatever remains shall be the
> result. In the special case where the word expanded was
> exactly "$@", the double quotes are also deleted, leaving nothing
> - the expansion of the word shall produce no fields.
>
> In other cases where the $@ occurred within double quotes,
> and other expansions within the same pair of double quotes
> as contain the $@ also produced no output text, and no other
> text is present, it is unspecified whether the empty double
> quoted string remains as a null string, or is
