30

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 "$@"?

4 Answers4

29

'Hysterical Raisins', aka Historical Reasons.

The explanation from JesperE (or the Bash man page on shell parameter expansion) 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
  • 730,956
  • 141
  • 904
  • 1,278
  • 7
    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. . . –  Sep 30 '08 at 21:29
  • 4
    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 Oct 02 '08 at 00:24
4

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 have just used "$@".

Lesmana
  • 25,663
  • 9
  • 82
  • 87
JesperE
  • 63,317
  • 21
  • 138
  • 197
  • 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 Sep 30 '08 at 19:45
  • 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. :) –  Sep 30 '08 at 19:59
  • 1
    I wouldn't rule out voodoo programming, either. ;-) – JesperE Sep 30 '08 at 20:20
3

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
  • 346,391
  • 90
  • 374
  • 439
0

Here are some other clues for a more complete answer...

The usage can concern the shebang line, which has never thoroughly be documented and where a single parameter is often expected.

Thereby it seems to be a workaround if filename contains spaces or exceed allowed length.

From Perl man page:

A better construct than $* would be ${1+"$@"}, which handles embedded spaces and such in the filenames, but doesn't work if the script is being interpreted by csh.

From TCL man page:

Many UNIX systems do not allow the #! line to exceed about 30 characters in length, so be sure that the tclsh executable can be accessed with a short file name.

And finally, some utilities could support the abstruse but handy feature of the cat command :

The $@ special parameter finds use as a tool for filtering input into shell scripts. The cat "$@" construction accepts input to a script either from stdin or from files given as parameters to the script.

juj
  • 451
  • 3
  • 7