View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001478 | Issue 8 drafts | Shell and Utilities | public | 2021-05-23 16:12 | 2024-06-11 09:12 |
| Reporter | stephane | Assigned To | |||
| Priority | normal | Severity | Editorial | Type | Clarification Requested |
| Status | Closed | Resolution | Accepted As Marked | ||
| 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 | 0001478: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 | ||||
|
|
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. |
|
|
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. |
| 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 | => 0001478: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 |
