Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!gem.mps.ohio-state.edu!uwm.edu!cs.utexas.edu!mailrus!cwjcc!cwns1!chet
From: chet@cwns1.CWRU.EDU (Chet Ramey)
Newsgroups: gnu.bash.bug
Subject: Re: bugs in command line.
Message-ID: <699@cwjcc.CWRU.Edu>
Date: 27 Sep 89 16:24:14 GMT
References: <8909271448.AA28013@abel.math.uiuc.edu>
Sender: news@cwjcc.CWRU.Edu
Reply-To: chet@po.CWRU.Edu (Chet Ramey)
Distribution: gnu
Organization: Case Western Reserve Univ. Cleveland, Ohio, (USA)
Lines: 29

In article <8909271448.AA28013@abel.math.uiuc.edu> skl@ABEL.MATH.UIUC.EDU (Soren Lundsgaard) writes:
>There is one bug report which I submitted which is still
>outstanding:  ${1+"$@"} is not expanded correctly if there is a
>word with a space in it.

Quoting from the SunOS 4.0 sh man page, which is derived from that of Sys 5
release 3.1:

"Blank Interpretation

After parameter and command substitution, the results of substitution are
scanned for internal field separator characters (those found in IFS) and
split into distinct arguments where such characters are found.  Explicit
null arguments ("" or '') are retained.  Implicit null arguments (those
resulting from parameters that have no values) are removed."

This sounds pretty much like what bash is doing.  If you want to preserve
quotes, quote the whole thing ("${1+$@}").

I don't have a copy of the POSIX 1003.2 spec (the defining document for
bash), but I assume it was derived from the System V Release 3 sh man page
(or at least that man page was used as a reference for this behavior).

Chet Ramey
-- 
Chet Ramey			"We are preparing to think about contemplating 
Network Services Group, CWRU	 preliminary work on plans to develop a
chet@cwjcc.INS.CWRU.Edu		 schedule for producing the 10th Edition of 
				 the Unix Programmers Manual." -- Andrew Hume