From dhw@whistle.com  Wed Jul 29 16:29:12 1998
Received: from pau-amma.whistle.com (s205m64.whistle.com [207.76.205.64])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA29487
          for <FreeBSD-gnats-submit@freebsd.org>; Wed, 29 Jul 1998 16:29:10 -0700 (PDT)
          (envelope-from dhw@whistle.com)
Received: (from dhw@localhost)
	by pau-amma.whistle.com (8.8.8/8.8.7) id QAA14121;
	Wed, 29 Jul 1998 16:27:15 -0700 (PDT)
	(envelope-from dhw)
Message-Id: <199807292327.QAA14121@pau-amma.whistle.com>
Date: Wed, 29 Jul 1998 16:27:15 -0700 (PDT)
From: David Wolfskill <dhw@whistle.com>
Reply-To: dhw@whistle.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: Minor tweak to PR 6387's change to /etc/rc.network
X-Send-Pr-Version: 3.2

>Number:         7435
>Category:       misc
>Synopsis:       [PATCH(HACK)] PR 6387 solution didn't handle pipelines adequately
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jul 29 16:30:01 PDT 1998
>Closed-Date:    Wed Sep 16 22:38:50 MEST 1998
>Last-Modified:  Wed Sep 16 22:42:13 MEST 1998
>Originator:     David Wolfskill
>Release:        FreeBSD 2.2.6-RELEASE i386
>Organization:
Whistle Communications
>Environment:

	FreeBSD 2.2.x, I suppose....

>Description:

	The change I suggested in /etc/rc.network for PR 6387
	fails to account for the way FreeBSD's implementation of
	the Bourne shell handles `pipeline` expansion during variable
	interpolation.

	In particular, although
		echo `echo baz | sed -e's/z/r/'`
	yields "bar" (as expected),
		export fz; fz="echo baz | sed -e's/z/r/'"
	causes
		echo $fz
	to yield "echo baz | sed -e's/z/r/'" OK, but then
		echo `$fz`
	yields "baz | sed -e's/z/r/'" -- which, in the middle of
	a script isn't exactly what I was expecting -- and is not
	only un-useful, but generates an error message.  :-(

	Please note:  it may well be that the FreeBSD Bourne shell
	implementation has this in common with others (and I've merely
	failed to notice before), or that FreeBSD's implementation is
	different, but correct.  Regardless, the code I submitted was
	not useful for the intended purpose (which was to allow rc.conf
	to be the only place where "user-servicable parts" were inside
	that the user or admin could tweak to get various desired
	results, in this case, for the amd maps.  It seems that the
	following patch changes the behavior to match my expectations,
	and thus "work".

>How-To-Repeat:

	Try specifying a pipeline, such as
	"ypcat -k amd.master | sed -e 's#/usr/local#/usr/local.shrimp#'"
	for the amd_map_program variable in /etc/rc.conf.

	The above narrative ought to be a better test case to understand
	the basic issue(s), though.

>Fix:
	
	Well, what I did here may be shown by the following diff:

pau-amma[36]% cvs diff -u freebsd/src/etc/rc.network
Index: freebsd/src/etc/rc.network
===================================================================
RCS file: /cvs/freebsd/src/etc/rc.network,v
retrieving revision 1.28
diff -u -r1.28 rc.network
--- rc.network  1998/07/08 15:40:53     1.28
+++ rc.network  1998/07/29 22:55:30
@@ -243,7 +243,7 @@
     if [ "X${amd_enable}" = X"YES" ]; then
            echo -n ' amd'
            if [ "X${amd_map_program}" != X"NO" ]; then
-               amd_flags="${amd_flags} `${amd_map_program}`"
+               amd_flags="${amd_flags} `echo ${amd_map_program} | sh`"
            fi
            amd -p ${amd_flags} > /var/run/amd.pid 2> /dev/null
     fi


	Now, I think that's rather a hack... but it seems to work
	better....  :-}
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->suspended 
State-Changed-By: phk 
State-Changed-When: Fri Jul 31 01:58:41 PDT 1998 
State-Changed-Why:  
awaiting committer 
State-Changed-From-To: suspended->closed 
State-Changed-By: cracauer 
State-Changed-When: Wed Sep 16 22:38:50 MEST 1998 
State-Changed-Why:  
The amd_map_program variable needs to be eval'ed. I commited this to 
-current, it doesn't apply to -stable.  

The shell behaves right, the solution without additional shell 
spawning is: 
"... `eval ${amd_map_program}`" 

Thanks for your work and happy hacking 
Martin 
>Unformatted:
