A NOTE has been added to this issue. ====================================================================== https://www.austingroupbugs.net/view.php?id=1915 ====================================================================== Reported By: steffen Assigned To: ====================================================================== Project: 1003.1(2016/18)/Issue7+TC2 Issue ID: 1915 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: steffen Organization: User Reference: Section: 2.5.2 Page Number: 2479 Line Number: 80382 Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2025-03-17 19:17 UTC Last Modified: 2025-04-29 11:16 UTC ====================================================================== Summary: clarification of 2.6.5 field splitting of 2.5.2 special parameter $* ======================================================================
---------------------------------------------------------------------- (0007160) geoffclare (manager) - 2025-04-29 11:16 https://www.austingroupbugs.net/view.php?id=1915#c7160 ---------------------------------------------------------------------- Note https://www.austingroupbugs.net/view.php?id=1915#c7138 was discussed in the April 24, 2025 teleconference and it was agreed that the standard should allow both behaviours. Suggested Interpretation response ------------------------ The standard states how the '*' special parameter is expanded, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: ------------- When IFS begins with a non-whitespace character and a positional parameter (other than the last one) ends with a non-whitespace IFS character, some existing implementations produce an extra empty field in the expansion of unquoted $* after the fields that the standard requires to be produced for that positional parameter. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- On page 2479 line 80362 section 2.5.2 ('@' special parameter), change:<blockquote>When the expansion occurs in a context where field splitting will be performed, any empty fields may be discarded and each of the non-empty fields shall be further split as described in [xref to 2.6.5].</blockquote>to:<blockquote>When the expansion occurs in a context where field splitting will be performed, these initial fields shall be further processed in the same manner as for the '*' special parameter.</blockquote> On page 2479 line 80383 section 2.5.2 ('*' special parameter), change:<blockquote>When the expansion occurs in a context where field splitting will be performed, any empty fields may be discarded and each of the non-empty fields shall be further split as described in [xref to 2.6.5]. When the expansion occurs in a context where field splitting will not be performed, the initial fields shall be joined to form a single field with the value of each parameter separated by the first character of the <i>IFS</i> variable if <i>IFS</i> contains at least one character, or separated by a <space> if <i>IFS</i> is unset, or with no separation if <i>IFS</i> is set to a null string.</blockquote>to:<blockquote>When the expansion occurs in a context where field splitting will not be performed, the initial fields shall be joined to form a single field with the value of each parameter separated by the first character of the <i>IFS</i> variable if <i>IFS</i> contains at least one character, or separated by a <space> if <i>IFS</i> is unset, or with no separation if <i>IFS</i> is set to a null string. When the expansion occurs in a context where field splitting will be performed:<ul><li>If <i>IFS</i> is set to a null string, any empty fields may be discarded but no further processing shall be performed.</li> <li>Otherwise, any empty fields may be discarded and the remaining fields shall be processed in one of the following two ways: <ol> <li>Each of the non-empty fields shall be split as described in [xref to 2.6.5].</li> <li>The remaining fields shall be joined to form a single field, as described above for expansion in a context where field splitting will not be performed, and this field shall then be split as described in [xref to 2.6.5].</li> </ol> </ul> <small>NOTE: These two alternatives produce different results if <i>IFS</i> begins with a non-whitespace character and a positional parameter, other than the last one, ends with a non-whitespace <i>IFS</i> character. Joining before splitting produces an extra empty field after the fields that splitting each field separately produces for that positional parameter. A future version of this standard may require that this extra empty field is not produced.</small></blockquote> After page 3878 line 134509 section C.2.5.2 Special Parameters, add:<blockquote>The Korn shell changed the way $* is expanded between the 1988 and 1993 versions, when subject to field splitting: <i>ksh88</i> first joined the positional parameters as if $* were quoted and then performed field splitting on the result. This produced an extra empty field if <i>IFS</i> begins with a non-whitespace character and a positional parameter, other than the last one, ends with a non-whitespace <i>IFS</i> character. For example:<pre>set a: a; IFS=:; printf '[%s]\n' $* <b>[a] [] [a]</b></pre>The natural expectation is that expanding $* here would produce the same fields as expanding $1 and $2 as separate arguments:<pre>set a: a; IFS=:; printf '[%s]\n' $1 $2 <b>[a] [a]</b> </pre>and this is what <i>ksh93</i> does. Since David Korn was involved with development of the shell language requirements in POSIX.2-1992 at the same time that he was working on <i>ksh93</i>, it is believed that the intention was for POSIX.2-1992 to require the <i>ksh93</i> behavior, but the wording was not sufficiently clear and some shells have continued to behave like <i>ksh88</i>. This standard now explicitly allows both behaviors (and likewise for $@ when subject to field splitting). However, implementors of shells that behave like <i>ksh88</i> are encouraged to change to the <i>ksh93</i> behavior.</blockquote> Issue History Date Modified Username Field Change ====================================================================== 2025-03-17 19:17 steffen New Issue 2025-03-18 10:31 geoffclare Note Added: 0007122 2025-03-18 11:29 lanodan Note Added: 0007123 2025-03-18 11:32 lanodan Note Edited: 0007123 2025-03-18 12:11 geoffclare Note Added: 0007124 2025-04-17 10:00 geoffclare Note Added: 0007138 2025-04-29 11:16 geoffclare Note Added: 0007160 ======================================================================
