NetBSD Problem Report #33956

From njoly@pasteur.fr  Sun Jul  9 13:19:29 2006
Return-Path: <njoly@pasteur.fr>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id D17F663B896
	for <gnats-bugs@gnats.NetBSD.org>; Sun,  9 Jul 2006 13:19:28 +0000 (UTC)
Message-Id: <20060709132227.67D6542010@cixy.dial.pasteur.fr>
Date: Sun,  9 Jul 2006 15:22:27 +0200 (CEST)
From: njoly@pasteur.fr
Reply-To: njoly@pasteur.fr
To: gnats-bugs@NetBSD.org
Subject: -current /bin/sh small regression with $@ in functions
X-Send-Pr-Version: 3.95

>Number:         33956
>Category:       bin
>Synopsis:       -current /bin/sh small regression with $@ in functions
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    jmmv
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jul 09 13:20:00 +0000 2006
>Closed-Date:    Wed Oct 14 13:03:03 +0000 2009
>Last-Modified:  Wed Oct 14 13:05:02 +0000 2009
>Originator:     Nicolas Joly
>Release:        NetBSD 3.99.21
>Organization:
Institut Pasteur, Paris.
>Environment:
System: NetBSD cixy.dial.pasteur.fr 3.99.21 NetBSD 3.99.21 (CIXY) #21: Sun Jul 9 10:41:55 CEST 2006 njoly@cixy.dial.pasteur.fr:/local/src/NetBSD/obj/i386/sys/arch/i386/compile/CIXY i386
Architecture: i386
Machine: i386
>Description:
I noticed that the following shell code does not produce the expected output
(note the missing dots ...) anymore with -current /bin/sh (it works with ksh
and zsh on the same machine, and with sh from 3.0):

njoly@cixy [tmp/sh]> cat foo.sh 

echocheck() { echo -n "Checking for $@ ... "; }

echocheck "foo bar"; echo "ok"
echocheck "foo_bar"; echo "ok"

njoly@cixy [tmp/sh]> /bin/sh ./foo.sh 
Checking for foo barok
Checking for foo_barok
njoly@cixy [tmp/sh]> /bin/ksh ./foo.sh 
Checking for foo bar ... ok
Checking for foo_bar ... ok
njoly@cixy [tmp/sh]> /local/bin/zsh ./foo.sh 
Checking for foo bar ... ok
Checking for foo_bar ... ok

>How-To-Repeat:
Simply run the previous example, and check the output
>Fix:
don't know

>Release-Note:

>Audit-Trail:
From: dholland+netbsd@eecs.harvard.edu (David Holland)
To: current-users@netbsd.org, njoly@pasteur.fr
Cc: gnats-bugs@netbsd.org
Subject: Re: bin/33956: -current /bin/sh possible regression
Date: Mon, 10 Jul 2006 18:05:32 -0400 (EDT)

 Nicolas Joly <njoly@pasteur.fr> wrote:
  > I just noticed that -current /bin/sh does not give the expected
  > results (note the missing dots ...) with the following piece of code:
  >
  > [snip]
  >
  > I'm pretty sure it worked previously, but i can't remember when.

 Whether or not it's a regression, it's definitely a bug.

 Shorter test case:

    sh -c 'foo() { echo "Testing ${@} fnord"; }; foo a'
    sh -c 'foo() { echo "Testing ${@} fnord"; }; foo a b'

 produces

    Testing a
    Testing a b  fnord

 I thought at first the problem was this code

 	apply_ifs = ((varflags & VSQUOTE) == 0 ||
 		(*var == '@' && shellparam.nparam != 1));

 at line 685 of expand.c (version 1.74), which doesn't set apply_ifs if
 there's only one argument. If you don't apply ifs expansion, an
 embedded null gets left behind and the trailing material thus gets
 lost.

 However, that turns out to be a red herring. The real problem is that
 extra space after the 'b'. Where's it coming from?

    sh -c 'foo() { printargv "Testing ${@} fnord"; }; foo a b'

 (where printargv is the obvious thing) produces

    argv[0]: -printargv-
    argv[1]: -Testing a-
    argv[2]: -b-
    argv[3]: - fnord-

 whereas with ksh, bash, and zsh you get

 argv[0]: -printargv-
 argv[1]: -Testing a-
 argv[2]: -b fnord-

 It turns out that there's an extra embedded null (these are used for
 dividing arguments within a quoted string) left at the end of the
 expansion of @, which causes b to be its own argument, so the extra
 space is inserted by echo.

 Patch:

 Index: expand.c
 ===================================================================
 RCS file: /cvsroot/src/bin/sh/expand.c,v
 retrieving revision 1.74
 diff -u -r1.74 expand.c
 --- expand.c	20 May 2006 13:57:27 -0000	1.74
 +++ expand.c	10 Jul 2006 21:57:47 -0000
 @@ -873,7 +873,8 @@
  			for (ap = shellparam.p ; (p = *ap++) != NULL ; ) {
  				STRTODEST(p);
  				/* Nul forces a parameter split inside "" */
 -				STPUTC('\0', expdest);
 +				if (*ap) 
 +					STPUTC('\0', expdest);
  			}
  			break;
  		}

 Cheers. :-)

 -- 
    - David A. Holland / dholland@eecs.harvard.edu

From: dholland+netbsd@eecs.harvard.edu (David Holland)
To: current-users@netbsd.org, <j+nbsd@2006.salmi.ch>
Cc: gnats-bugs@netbsd.org
Subject: Re: bin/33956: -current /bin/sh possible regression
Date: Tue, 11 Jul 2006 14:33:52 -0400 (EDT)

 Jukka Salmi <j+nbsd@2006.salmi.ch> wrote:
  > Hmm, this reverts what has been recently [1]changed to fix PR
  > [2]bin/33472...
  > 
  > Cheers, Jukka
  > 
  > [1] http://cvsweb.netbsd.org/bsdweb.cgi/src/bin/sh/expand.c.diff?r1=1.73&r2=1.74
  > [2] http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=33472

 Hrm, good point.

 *investigates*

 This additional patch fixes that bug:

 --- expand.c~	2006-07-10 17:56:18.000000000 -0400
 +++ expand.c	2006-07-11 14:15:31.000000000 -0400
 @@ -1035,7 +1035,7 @@
  	 * Some recent clarification of the Posix spec say that it
  	 * should only generate one....
  	 */
 -	if (*start) {
 +	if (*start || inquotes) {
  		sp = (struct strlist *)stalloc(sizeof *sp);
  		sp->text = start;
  		*arglist->lastp = sp;


 and here's a patch for the regression suite (which doesn't all pass,
 but my hacking hasn't changed that)

 --- regress/bin/sh/expand.sh~	2006-05-11 20:05:59.000000000 -0400
 +++ regress/bin/sh/expand.sh	2006-07-11 14:22:21.000000000 -0400
 @@ -27,3 +27,11 @@
  set -- "" ""				# This code triggered the bug.
  got=`echo "$@" | sed 's,$,EOL,'`
  assert_equals "2" " EOL" "$got"
 +
 +# The original fix wasn't quite right, and this triggers that bug.
 +foo() { echo "Testing ${@} fnord"; }
 +got=`foo a`
 +assert_equals "3" "Testing a fnord" "$got"
 +got=`foo a b`
 +assert_equals "3" "Testing a b fnord" "$got"
 +

 --- regress/bin/sh/Makefile~	2006-06-16 10:43:17.000000000 -0400
 +++ regress/bin/sh/Makefile	2006-07-11 14:28:46.000000000 -0400
 @@ -10,6 +10,6 @@
  	sh ${.CURDIR}/fsplit.sh
  	sh ${.CURDIR}/here.sh
  	sh ${.CURDIR}/set_e.sh
 -	#sh ${.CURDIR}/expand.sh	# First needs to be fixed.
 +	sh ${.CURDIR}/expand.sh

  .include <bsd.prog.mk>


 -- 
    - David A. Holland / dholland@eecs.harvard.edu

From: dholland+netbsd@eecs.harvard.edu (David Holland)
To: current-users@netbsd.org, j+nbsd@2006.salmi.ch
Cc: gnats-bugs@netbsd.org
Subject: Re: bin/33956: -current /bin/sh possible regression
Date: Tue, 11 Jul 2006 14:49:45 -0400 (EDT)

 I just wrote:
  > -       if (*start) {
  > +       if (*start || inquotes) {

 That's not quite right; it inserts a spurious blank argument when you do
 'set -- ; echo "$@"'. Which should probably get added to the regression
 test too.

 Use this instead:

 --- expand.c.save	2006-07-10 17:56:18.000000000 -0400
 +++ expand.c	2006-07-11 14:41:24.000000000 -0400
 @@ -1035,7 +1035,7 @@
  	 * Some recent clarification of the Posix spec say that it
  	 * should only generate one....
  	 */
 -	if (*start) {
 +	if (*start || (inquotes && start > string)) {
  		sp = (struct strlist *)stalloc(sizeof *sp);
  		sp->text = start;
  		*arglist->lastp = sp;

From: Rhialto <rhialto@falu.nl>
To: David Holland <dholland+netbsd@eecs.harvard.edu>
Cc: current-users@NetBSD.org, njoly@pasteur.fr, gnats-bugs@NetBSD.org
Subject: Re: bin/33956: -current /bin/sh possible regression
Date: Wed, 12 Jul 2006 02:09:39 +0200

 On Mon 10 Jul 2006 at 18:05:32 -0400, David Holland wrote:
 >    sh -c 'foo() { printargv "Testing ${@} fnord"; }; foo a b'

 In my view, the *real* problem is that the above case simply is
 undefined, hence any particular output is never a bug.

 Look at the manpage (from 3.0):

      @            Expands to the positional parameters, starting from one.
                   When the expansion occurs within double-quotes, each posi-
                   tional parameter expands as a separate argument.  If there
                   are no positional parameters, the expansion of @ generates
                   zero arguments, even when @ is double-quoted.  What this
                   basically means, for example, is if $1 is ``abc'' and $2 is
                   ``def ghi'', then "$@" expands to the two arguments:

                         "abc" "def ghi"

 This arguably only defines "$@", not if anything else is between the quotes.
 The author of that definition simply never contemplated that case.

 -Olaf.
 -- 
 ___ Olaf 'Rhialto' Seibert      -- You author it, and I'll reader it.
 \X/ rhialto/at/xs4all.nl        -- Cetero censeo "authored" delendum esse.

From: Rhialto <rhialto@falu.nl>
To: David Holland <dholland+netbsd@eecs.harvard.edu>
Cc: current-users@NetBSD.org, njoly@pasteur.fr, gnats-bugs@NetBSD.org
Subject: Re: bin/33956: -current /bin/sh possible regression
Date: Wed, 12 Jul 2006 02:16:18 +0200

 On Wed 12 Jul 2006 at 02:09:39 +0200, Rhialto wrote:
 >      @            Expands to the positional parameters, starting from one.
 >                   When the expansion occurs within double-quotes, each posi-
 >                   tional parameter expands as a separate argument.  If there
 >                   are no positional parameters, the expansion of @ generates
 >                   zero arguments, even when @ is double-quoted.  What this
 >                   basically means, for example, is if $1 is ``abc'' and $2 is
 >                   ``def ghi'', then "$@" expands to the two arguments:
 > 
 >                         "abc" "def ghi"
 > 
 > This arguably only defines "$@", not if anything else is between the quotes.
 > The author of that definition simply never contemplated that case.

 Even if one argued that "Testing ${@} fnord" is a meaningful
 substitution, then according to the above definition, it should produce
 zero arguments if there are no positional parameters. Yet,

     sh -c 'foo() { echo "Testing ${@} fnord"; }; foo'

 produces (on 3.0)

     Testing  fnord

 which I must consider a bug.

 -Olaf.
 -- 
 ___ Olaf 'Rhialto' Seibert      -- You author it, and I'll reader it.
 \X/ rhialto/at/xs4all.nl        -- Cetero censeo "authored" delendum esse.

From: seebs@plethora.net (Peter Seebach)
To: current-users@NetBSD.org, gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/33956: -current /bin/sh possible regression 
Date: Tue, 11 Jul 2006 19:38:20 -0500

 In message <20060712001618.GC923@falu.nl>, Rhialto writes:
 >Even if one argued that "Testing ${@} fnord" is a meaningful
 >substitution, then according to the above definition, it should produce
 >zero arguments if there are no positional parameters. Yet,
 >
 >    sh -c 'foo() { echo "Testing ${@} fnord"; }; foo'
 >
 >produces (on 3.0)
 >
 >    Testing  fnord
 >
 >which I must consider a bug.

 Why?  The @ expanded to nothing, as expected.  It doesn't prevent other
 variables from expanding, or other text from continuing to exist.

 -s

From: Rhialto <rhialto@falu.nl>
To: Peter Seebach <seebs@plethora.net>
Cc: current-users@NetBSD.org, gnats-bugs@NetBSD.org
Subject: Re: bin/33956: -current /bin/sh possible regression
Date: Wed, 12 Jul 2006 02:54:06 +0200

 On Tue 11 Jul 2006 at 19:38:20 -0500, Peter Seebach wrote:
 > Why?  The @ expanded to nothing, as expected.  It doesn't prevent other
 > variables from expanding, or other text from continuing to exist.

 Note that definition says "arguments". I'll have to assume it says that
 for a reason. So there shall be zero arguments, if there are no
 positional parameters, and echo shall print nothing (except for a
 newline). I don't think you can argue with that.

 Let me take this opportunity, as a devil's advocate, of another possible
 generalisation of "$@" to "foo $@ bar". I would argue that

     sh -c 'foo() { printargv "Testing ${@} fnord"; }; foo a b'

 should print

     Testing a fnord Testing b fnord

 and there is nothing in the definition that will contradict this
 interpretation.

 > -s
 -Olaf.
 -- 
 ___ Olaf 'Rhialto' Seibert      -- You author it, and I'll reader it.
 \X/ rhialto/at/xs4all.nl        -- Cetero censeo "authored" delendum esse.

From: Rhialto <rhialto@falu.nl>
To: Peter Seebach <seebs@plethora.net>
Cc: current-users@NetBSD.org, gnats-bugs@NetBSD.org
Subject: Re: bin/33956: -current /bin/sh possible regression
Date: Wed, 12 Jul 2006 03:03:51 +0200

 Oops, cutting/pasting a bit sloppily (it's late over here).
 Considering it is printargv and not echo, the relevant bits would be

      sh -c 'foo() { printargv "Testing ${@} fnord"; }; foo a b'

     argv[1] = -Testing a fnord-
     argv[2] = -Testing b fnord-

 -Olaf.
 -- 
 ___ Olaf 'Rhialto' Seibert      -- You author it, and I'll reader it.
 \X/ rhialto/at/xs4all.nl        -- Cetero censeo "authored" delendum esse.

From: Chapman Flack <nblists@anastigmatix.net>
To: Rhialto <rhialto@falu.nl>
Cc: David Holland <dholland+netbsd@eecs.harvard.edu>,
	current-users@NetBSD.org, njoly@pasteur.fr, gnats-bugs@NetBSD.org
Subject: Re: bin/33956: -current /bin/sh possible regression
Date: Tue, 11 Jul 2006 21:04:04 -0400

 Rhialto wrote:
 > In my view, the *real* problem is that the above case simply is
 > undefined, hence any particular output is never a bug.
 > 
 > Look at the manpage (from 3.0):
 > ...
 > This arguably only defines "$@", not if anything else is between the quotes.
 > The author of that definition simply never contemplated that case.

 Reasoning from the weaknesses of our own man page isn't dispositive,
 though, because even our man page says that [a]sh is intended to
 implement the POSIX semantics, which are defined:

 @   Expands to the positional parameters, starting from one. When the
     expansion occurs within double-quotes, and where field splitting
     (see Field Splitting) is performed, each positional parameter shall
     expand as a separate field, with the provision that the expansion of
     the first parameter shall still be joined with the beginning part of
     the original word (assuming that the expanded parameter was embedded
     within a word), and the expansion of the last parameter shall still
     be joined with the last part of the original word. If there are no
     positional parameters, the expansion of '@' shall generate zero
     fields, even when '@' is double-quoted.

 Granted, even that wording would win no contests for precision, but it
 does cover the case almost completely. In the particular case of NO
 positional parameters, it could technically be read to allow either
 "foo  bar" or nothing at all as the expansion of "foo $@ bar", but that
 seems more an artifact of the writing than an intent of the spec; both
 existing practice and POLA would tend to rule out the 'nothing at all'
 interpretation.

 -Chap

From: Rhialto <rhialto@falu.nl>
To: Chapman Flack <nblists@anastigmatix.net>
Cc: Rhialto <rhialto@falu.nl>,
	David Holland <dholland+netbsd@eecs.harvard.edu>,
	current-users@NetBSD.org, njoly@pasteur.fr, gnats-bugs@NetBSD.org
Subject: Re: bin/33956: -current /bin/sh possible regression
Date: Wed, 12 Jul 2006 03:20:59 +0200

 On Tue 11 Jul 2006 at 21:04:04 -0400, Chapman Flack wrote:
 > Reasoning from the weaknesses of our own man page isn't dispositive,
 > though, because even our man page says that [a]sh is intended to
 > implement the POSIX semantics, which are defined:

 Well, ok, I was wondering what POSIX would say. But I think I have a
 fair point that I can only judge NetBSD behaviour by actually included
 NetBSD documentation, which according to my recollection follows
 historical documentation pretty closely in this case (looking at the
 sh(1) of my ULTRIX 4.0 grey wall, I even see that it writes no more than

     "$*" is equivalent to "$1 $2 ..." whereas
     "$@" is equivalent to "$1" "$2" ... .

 which strengthens my idea that originally this case was not
 contemplated)

 > @   Expands to the positional parameters, starting from one. When the
 >    expansion occurs within double-quotes, and where field splitting
 >    (see Field Splitting) is performed, each positional parameter shall
 >    expand as a separate field, with the provision that the expansion of
 >    the first parameter shall still be joined with the beginning part of
 >    the original word (assuming that the expanded parameter was embedded
 >    within a word), and the expansion of the last parameter shall still
 >    be joined with the last part of the original word. If there are no
 >    positional parameters, the expansion of '@' shall generate zero
 >    fields, even when '@' is double-quoted.
 > 
 > Granted, even that wording would win no contests for precision, but it
 > does cover the case almost completely. In the particular case of NO
 > positional parameters, it could technically be read to allow either
 > "foo  bar" or nothing at all as the expansion of "foo $@ bar", but that
 > seems more an artifact of the writing than an intent of the spec; both
 > existing practice and POLA would tend to rule out the 'nothing at all'
 > interpretation.

 I think someone noticed that people were using $@ in a way that was not
 intended, and wrote up a sort-of sensible definiton for it after the
 fact. Personally I would not cry if all configure scripts with "Checking
 $@ ..." would cause d(a)emons to fly out of the author's nose. They
 could equally well write $* instead (and I might even refrain from
 arguing that it would be undefined too ;-)

 > -Chap
 -Olaf.
 -- 
 ___ Olaf 'Rhialto' Seibert      -- You author it, and I'll reader it.
 \X/ rhialto/at/xs4all.nl        -- Cetero censeo "authored" delendum esse.

From: "Greg A. Woods" <woods@weird.com>
To: Chapman Flack <nblists@anastigmatix.net>
Cc: NetBSD-current Users Discussion List <current-users@NetBSD.org>,
	NetBSD GNATS <gnats-bugs@NetBSD.org>
Subject: Re: bin/33956: -current /bin/sh possible regression
Date: Wed, 12 Jul 2006 12:54:25 -0400

 --pgp-sign-Multipart_Wed_Jul_12_12:54:21_2006-1
 Content-Type: text/plain; charset=US-ASCII
 Content-Transfer-Encoding: quoted-printable

 At Tue, 11 Jul 2006 21:04:04 -0400,
 Chapman Flack wrote:
 >=20
 > Rhialto wrote:
 > > In my view, the *real* problem is that the above case simply is
 > > undefined, hence any particular output is never a bug.
 > >=20
 > > Look at the manpage (from 3.0):
 > > ...
 > > This arguably only defines "$@", not if anything else is between the qu=
 otes.
 > > The author of that definition simply never contemplated that case.
 >=20
 > Reasoning from the weaknesses of our own man page isn't dispositive,
 > though, because even our man page says that [a]sh is intended to
 > implement the POSIX semantics, which are defined:
 >=20
 > @   Expands to the positional parameters, starting from one. When the
 >     expansion occurs within double-quotes, and where field splitting
 >     (see Field Splitting) is performed, each positional parameter shall
 >     expand as a separate field, with the provision that the expansion of
 >     the first parameter shall still be joined with the beginning part of
 >     the original word (assuming that the expanded parameter was embedded
 >     within a word), and the expansion of the last parameter shall still
 >     be joined with the last part of the original word. If there are no
 >     positional parameters, the expansion of '@' shall generate zero
 >     fields, even when '@' is double-quoted.
 >=20
 > Granted, even that wording would win no contests for precision, but it
 > does cover the case almost completely. In the particular case of NO
 > positional parameters, it could technically be read to allow either
 > "foo  bar" or nothing at all as the expansion of "foo $@ bar", but that
 > seems more an artifact of the writing than an intent of the spec; both
 > existing practice and POLA would tend to rule out the 'nothing at all'
 > interpretation.

 I suspect the intent of the POSIX wording implies that the following
 should have been appended to the last sentence for clairy's sake:

 	", with the provision that the original word will still be
 	generated as one field if the $@ was embedded within a word"

 Keeping in mind that the old-fashioned way to ensure that zero
 parameters were generated when passing an ``empty'' ARGV to another
 command was to use the following simple little construct:

 	${1+"$@"}

 thus the ``addition'' of that last rule (about generating zero fields,
 even when it is double-quoted) is relatively recent in terms of shell
 behaviour (coming in as a common requirement right about the time that
 POSIX document was first written) and so it may be the author(s)
 thinking wasn't quite so clear either.  (I suspect, though I don't
 remember for sure, that the whole "embedded within a word" behaviour was
 either documenting some common implementation or making some compromise,
 and was not the result of some really logicall thinking about the
 issue.  I suspect logically it should have embedded each parameter
 within the word, creating new fields for each parameter and produced no
 fields at all if there were no elements in ARGV.)

 Indeed, as you say, just because the _expansion_ produces zero fields
 doesn't mean the word the expansion is embedded in is not to be
 produced.  At this point that would most certainly violate the POLA no
 matter whose fence you're sitting on.  The wording is at least clear
 enough to say that the original word won't be split into two fields. :-)

 (As for NetBSD's shell(s), well any incompatability with POSIX should be
 remedied, wether it be in the documentation, behaviour, or both.)

 --=20
 						Greg A. Woods

 H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@robohack.ca>
 Planix, Inc. <woods@planix.com>       Secrets of the Weird <woods@weird.com>

 --pgp-sign-Multipart_Wed_Jul_12_12:54:21_2006-1
 Content-Type: application/pgp-signature
 Content-Transfer-Encoding: 7bit

 -----BEGIN PGP SIGNATURE-----
 Version: PGPfreeware 5.0i for non-commercial use
 MessageID: vlZAboWjwJRdgqGjWltFzynUQeGrg59E

 iQA/AwUBRLUpP2J7XxTCWceFEQLwIwCgg/KJjNdxdExSj+sSGtVq6nlx86gAoOUi
 CfRuVph71s9J6YoxXeLPPN0E
 =f04i
 -----END PGP SIGNATURE-----

 --pgp-sign-Multipart_Wed_Jul_12_12:54:21_2006-1--

From: David Laight <dsl@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: PR/33956 CVS commit: src/bin/sh
Date: Mon, 21 Aug 2006 21:30:14 +0000 (UTC)

 Module Name:	src
 Committed By:	dsl
 Date:		Mon Aug 21 21:30:14 UTC 2006

 Modified Files:
 	src/bin/sh: expand.c

 Log Message:
 Rework the code changes from revisions 1.69, 1.70 and 1.74 so that the code
 behaves correctly.
 As far as I can tell, "x$@y" now expands correctly, as does IFS=:; set -$IFS.
 Fixes PR/33472 (again) and PR/33956


 To generate a diff of this commit:
 cvs rdiff -r1.74 -r1.75 src/bin/sh/expand.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Matthias Scheler <tron@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: PR/33956 CVS commit: [netbsd-4] src/bin/sh
Date: Fri,  1 Sep 2006 14:57:54 +0000 (UTC)

 Module Name:	src
 Committed By:	tron
 Date:		Fri Sep  1 14:57:54 UTC 2006

 Modified Files:
 	src/bin/sh [netbsd-4]: expand.c

 Log Message:
 Pull up following revision(s) (requested by dsl in ticket #83):
 	bin/sh/expand.c: revision 1.75
 Rework the code changes from revisions 1.69, 1.70 and 1.74 so that the code
 behaves correctly.
 As far as I can tell, "x$@y" now expands correctly, as does IFS=:; set -$IFS.
 Fixes PR/33472 (again) and PR/33956


 To generate a diff of this commit:
 cvs rdiff -r1.74 -r1.74.2.1 src/bin/sh/expand.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Geert Hendrickx <ghen@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: PR/33956 CVS commit: [netbsd-3] src/bin/sh
Date: Sat,  2 Sep 2006 20:38:46 +0000 (UTC)

 Module Name:	src
 Committed By:	ghen
 Date:		Sat Sep  2 20:38:46 UTC 2006

 Modified Files:
 	src/bin/sh [netbsd-3]: expand.c

 Log Message:
 Pull up following revision(s) (requested by dsl in ticket #1487):
 	bin/sh/expand.c: revision 1.75
 Rework the code changes from revisions 1.69, 1.70 and 1.74 so that the code
 behaves correctly.
 As far as I can tell, "x$@y" now expands correctly, as does IFS=:; set -$IFS.
 Fixes PR/33472 (again) and PR/33956


 To generate a diff of this commit:
 cvs rdiff -r1.68.2.3 -r1.68.2.4 src/bin/sh/expand.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->closed
State-Changed-By: dsl@netbsd.org
State-Changed-When: Fri, 15 Sep 2006 20:08:44 +0000
State-Changed-Why:
fixed and pulled up into netbsd 3 an 4


Responsible-Changed-From-To: bin-bug-people->jmmv
Responsible-Changed-By: jmmv@netbsd.org
Responsible-Changed-When: Sun, 21 Oct 2007 11:34:45 +0000
Responsible-Changed-Why:
I will deal with the regression test bundled here.


State-Changed-From-To: closed->open
State-Changed-By: jmmv@netbsd.org
State-Changed-When: Sun, 21 Oct 2007 11:34:45 +0000
State-Changed-Why:
I was told a while ago that a regression test was added as part of this PR,
but the code was never committed to the tree.  I will handle this part as
part of the atf work.


State-Changed-From-To: open->closed
State-Changed-By: jmmv@NetBSD.org
State-Changed-When: Wed, 14 Oct 2009 13:03:03 +0000
State-Changed-Why:
I've added the tests herein described to tests/util/sh/t_expand.sh.


From: "Julio M. Merino Vidal" <jmmv@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/33956 CVS commit: src/tests/util/sh
Date: Wed, 14 Oct 2009 13:02:04 +0000

 Module Name:	src
 Committed By:	jmmv
 Date:		Wed Oct 14 13:02:04 UTC 2009

 Modified Files:
 	src/tests/util/sh: t_expand.sh

 Log Message:
 Add test cases for "prefix $@ suffix" expansion.  From PR bin/33956.
 This issue was fixed a while ago but the tests described in the report
 were never written as proper test cases.


 To generate a diff of this commit:
 cvs rdiff -u -r1.2 -r1.3 src/tests/util/sh/t_expand.sh

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.