tags:

views:

558

answers:

3

I've noticed that sometimes wrapper scripts will use ${1:+"$@"} for the parameters rather than just "$@".

For example, http://svn.macosforge.org/repository/macports/trunk/dports/editors/vim-app/files/gvim.sh uses

exec "$binary" $opts ${1:+"$@"}

Can anyone break ${1:+"$@"} down into English and explain why it would be an advantage over plain "$@"?

+2  A: 

From the bash man page:

   ${parameter:+word}
          Use Alternate Value.  If parameter is null or unset, nothing  is
          substituted, otherwise the expansion of word is substituted.

So, "$@" is substituted unless "$1" is unset. I can't see why they couldn't've just used "$@".

JesperE
BTW: The bash man-page really is your friend when it comes to questions such as this. It's probably the man-page I use most frequently.
JesperE
You're right about 'man bash'. Sorry, I had found that quote as well but didn't include it in my question. I agree that they probably could have just used "$@" but there must be a reason for ${1:+"$@"} . . . maybe we'll find out. :)
I wouldn't rule out voodoo programming, either. ;-)
JesperE
+4  A: 

'Hysterical Raisins', aka Historical Reasons.

The explanation from JesperE (or the Bash man page) is accurate for what it does:

If $1 exists and is not an empty string, then substitute the quoted list of arguments.

Once upon 20 or so years ago, some broken minor variants of the Bourne Shell substituted an empty string "" for "$@" if there were no arguments, instead of the correct, current behaviour of substituting nothing. Whether any such systems are still in use is open to debate.

[Hmm: that expansion would not work correctly for:

command '' arg2 arg3 ...

In this context, the correct notation is:

${1+"$@"}

This works correctly whether $1 is an empty argument or not. So, someone remembered the notation incorrectly, accidentally introducing a bug.]

Jonathan Leffler
Ah ha. Yes, at least according to http://google.com/codesearch the notation you mentioned is much more common. I see 191,000 results for ${1+"$@"} (i.e. no colon) versus 173 results for ${1:+"$@"}. Of course, the quote from "man bash" has a colon. So maybe using the colon isn't a bug. . .
The colon is a different test - it is looking for a non-empty string. It is most often used in connection with an env var that must have a value: ${ENVVAR:+"-value=$ENVVAR"} or whatever. This creates a -value=whatever argument only if ENVVAR is set to a non-empty string.
Jonathan Leffler
A: 

To quote the relevant portion of man bash for the information that Jonathan Leffler referred to in his comment:

When not performing substring expansion, bash tests for a parameter that is unset or null; omitting the colon results in a test only for a parameter that is unset.

(emphasis mine)

Dennis Williamson