Date: Wed, 29 Jul 1998 16:27:15 -0700 (PDT) From: David Wolfskill <dhw@whistle.com> To: FreeBSD-gnats-submit@FreeBSD.ORG Subject: misc/7435: Minor tweak to PR 6387's change to /etc/rc.network Message-ID: <199807292327.QAA14121@pau-amma.whistle.com>
index | next in thread | raw e-mail
>Number: 7435
>Category: misc
>Synopsis: PR 6387 solution didn't handle pipelines adequately
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: change-request
>Submitter-Id: current-users
>Arrival-Date: Wed Jul 29 16:30:01 PDT 1998
>Last-Modified:
>Originator: David Wolfskill
>Organization:
Whistle Communications
>Release: FreeBSD 2.2.6-RELEASE i386
>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.... :-}
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807292327.QAA14121>