Bug 4243 - hush parsing of ${1+"$@"}
Summary: hush parsing of ${1+"$@"}
Status: RESOLVED FIXED
Alias: None
Product: Busybox
Classification: Unclassified
Component: Standard Compliance (show other bugs)
Version: 1.19.x
Hardware: PC Linux
: P5 minor
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-23 10:24 UTC by Christian Häggström
Modified: 2018-08-04 20:31 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:


Attachments
adds test for ${1+"$@"} (751 bytes, patch)
2011-09-23 10:24 UTC, Christian Häggström
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Häggström 2011-09-23 10:24:09 UTC
Created attachment 3613 [details]
adds test for ${1+"$@"}

We have some shell scripts that needs to be compatible among many shells, and we use ${1+"$@"} instead of "$@" in some wrapper script for the reasons described here:
http://www.gnu.org/s/hello/manual/autoconf/Shell-Substitutions.html

Now, busybox ash and hush both interpret it differenly than bash. I tried with the git HEAD.

$ echo 'for x in ${1+"$@"}; do echo $x; done' > testscript
$ ./hush testscript "a b"
"a
b"
$ bash testscript "a b"
a b

$ ./hush -v
BusyBox v1.20.0.git (2011-09-23 11:11:24 CEST) multi-call binary.

I haven't been able to find what the POSIX standard says about ${1+"$@"}, so please close the bug report if you believe it is non-standard behaviour.
Comment 1 Denys Vlasenko 2012-09-26 09:55:46 UTC
This is sheer insanity. Bash is buggy wrt """$@", therefore we'll use ambiguous constructs ${1+"$@"}?

Where is the definitive part of the standard which says what exactly should happen with ${1+"$@"} construct?
Comment 2 Mike Frysinger 2012-10-21 17:59:18 UTC
(In reply to comment #1)

i think it breaks down into two parts.  there's:
  ${1+word}
which, if $1 is set, substitutes the words

then there's "$@" which expands the array of words.

so it should be:
$ set -- '1 2' 3 4
$ printf '%s\n' "$@"
1 2
3
4

you could e-mail austin-group-l@opengroup.org for an interpretation ... i'm sure someone will be able to get the details for you
Comment 3 Denys Vlasenko 2018-08-04 20:31:17 UTC
Fixed in git.