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
0001478 [Issue 8 drafts] Shell and Utilities Editorial Clarification Requested 2021-05-23 16:12 2024-06-11 09:12
Reporter stephane View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Closed   Product Version Draft 2
Name Stéphane Chazelas
Organization
User Reference
Section 2.6.2 Parameter Expansion
Page Number 2318-2320
Line Number
Final Accepted Text Note: 0005389
Summary 0001478: clarify ${@?error}, ${@+set}, "${@+set}", "${*+set}"... etc. expansions
Description While the spec does leave expansions of ${@#pattern} (and variants with ##, %, %%) unspecified, or that $@/$* expansion shall not cause the shell to exit when the nounset option is set (without going as far as saying that $@ / $* should be considered always set), it leaves it quite unclear what the expansion of

${@?error} "${@?error}", ${@+"$@" more}, "${*-foo}", "${@:+foo}", ${*+foo} should yield.

In practice, there is a lot of variation in behaviour between implementations, with some implementations considering $@/$* "set" always (like for set -u) or only if $# > 0. Or "$*" "non-empty" only if $1 is non empty or some only if "$*" would yield a non-empty string (with variations in behaviour if $IFS is empty), etc. For some ${@?error} is a syntax error, etc.

Some shells with array support try to be consistent with their handling of $@ compared to that of other arrays, but in different ways as their arrays take different shapes, etc.

The only portable variants I've managed to find were: "${*-foo}" and "${*+foo}" which expand to foo (resp. "$*") if and only if $# == 0, which is not among the most useful ones.
Desired Action Leaving the expansion of all those - + ? :- :+ :? operators unspecified for the @ and * parameters seems like the least bad option.

Alternatives are likely to either make things more confusing or break some shells backward compatibility.

Users can always spell things out like:

if [ "$#" -eq 0 ]; then
  ...
else
  ...
fi


or if:

if [ -n "$*" ]; then
  ...
else
  ...
fi
Tags issue8
Attached Files

- Relationships

-  Notes
(0005365)
stephane (reporter)
2021-05-23 16:16

 For the record, this came to my attention at

https://unix.stackexchange.com/questions/650208/issue-processing-multiple-files-counting-lines/650590#comment1220610_650590 [^]

Where someone posted this:

#!/bin/sh -

wc -l -- "${@?expected to get filename argument(s)}"


code which in practice is not portable, and for which I'm not sure what the POSIX spec currently says.
(0005389)
geoffclare (manager)
2021-06-21 09:37
edited on: 2021-06-21 09:38

 Suggested change:

On page 2318 line 74742 section 2.6.2 append a sentence to the paragraph:
If parameter is '*' or '@', the result of the expansion is unspecified.

- Issue History
Date Modified Username Field Change
2021-05-23 16:12 stephane New Issue
2021-05-23 16:12 stephane Name => Stéphane Chazelas
2021-05-23 16:12 stephane Section => 2.6.2 Parameter Expansion
2021-05-23 16:12 stephane Page Number => 2318-2320
2021-05-23 16:16 stephane Note Added: 0005365
2021-06-21 09:37 geoffclare Note Added: 0005389
2021-06-21 09:38 geoffclare Note Edited: 0005389
2021-07-01 16:09 geoffclare Final Accepted Text => Note: 0005389
2021-07-01 16:09 geoffclare Status New => Resolved
2021-07-01 16:09 geoffclare Resolution Open => Accepted As Marked
2021-07-01 16:09 geoffclare Tag Attached: issue8
2021-07-20 09:33 geoffclare Status Resolved => Applied
2024-06-11 09:12 agadmin Status Applied => Closed

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