Dazed_75 wrote: > > > On Fri, Oct 2, 2009 at 4:16 PM, Eric Shubert > <[email protected] > <mailto:[email protected]>> wrote: > > Eric Shubert wrote: > > Jason Holtzapple wrote: > >> Eric Shubert wrote: > >>> Dazed_75 wrote: > >>>> RESOLVED !!! > >>>> > >>>> Ryan had said: > >>>> > >>>> I found this > https://bugs.launchpad.net/ubuntu/+source/dhcp3/+bug/392826 > >>>> via a quick google search so the answer to your question about > >>>> reordering the script doesn't seem like it would work. > >>>> > >>>> But I had been looking mostly at the discussion of ordering > the elements > >>>> in /etc/rc?.d/ which I tried several variations for. When I > re-read it > >>>> and noticed the script attached, it seemed a reasonable work > around. > >>>> > >>>> Jacob Nevins has said: > >>>> > >>>> I'm also running into this. > >>>> > >>>> I've bodged around it by putting the attached script in > >>>> /etc/network/if-up.d/dhcp3-server . I don't claim it's the best > >>>> solution, or that it should be included in the package, but it > works for > >>>> my situation (where I have a single interface "eth0" > explicitly listed > >>>> in /etc/default/dhcp3-server), so it might be a useful > workaround for > >>>> others. > >>>> > >>>> The script was: > >>>> > >>>> #! /bin/sh > >>>> # Kick DHCP server when interface comes up (for Ubuntu, > probably Debian too) > >>>> > >>>> # Workaround for > <https://bugs.launchpad.net/ubuntu/+source/dhcp3/+bug/392826> > >>>> # Bugs: > >>>> # - Only works when interfaces for dhcpd are explicitly listed. > >>>> > >>>> > >>>> DHCP_IF=/etc/default/dhcp3-server > >>>> DHCP_INIT=/etc/init.d/dhcp3-server > >>>> > >>>> [ -f "$DHCP_IF" -a -f "$DHCP_INIT" ] || exit 0 > >>>> > >>>> . "$DHCP_IF" > >>>> > >>>> if [ "x$INTERFACES" = x ]; then > >>>> > >>>> # Don't know which interfaces it manages, always restart > >>>> restart_dhcp=1 > >>>> else > >>>> restart_dhcp=0 > >>>> for iface in "$INTERFACES"; do > >>>> if [ "$iface" = "$IFACE" ]; then > >>>> > >>>> restart_dhcp=1 > >>>> fi > >>>> done > >>>> fi > >>>> > >>>> if [ "$restart_dhcp" = "1" ]; then > >>>> "$DHCP_INIT" restart > >>>> fi > >>>> > >>>> > >>>> It seemed reasonable to try and it worked. Now there is no > need to > >>>> actually log in and run /etc/init.d/dhcp3-server start in > order to get > >>>> the DHCO server running. Oh, BTW, he was wrong about needing > to name > >>>> the interface to use in /etc/default/dhcp3-server. > >>>> > >>>> -- > >>>> Dazed_75 a.k.a. Larry > >>>> > >>>> The spirit of resistance to government is so valuable on certain > >>>> occasions, that I wish it always to be kept alive. > >>>> - Thomas Jefferson > >>>> > >>>> > >>> While that script appears to work, I don't believe it will work as > >>> intended. Long story short, [ "" = "" ] is always true, as = is > >>> assignment. The tests should be [ "" == "" ] . Substitute > appropriately, > >>> and the rest appears ok. > >>> > >> '=' is a Bourne shell(slash)/usr/bin/test-ism that should still work > >> fine in bash. I hope so ... or bash risks breaking a lot of old > shell > >> code out there. > >> > >> --Jason > > > > That appears to be right. I don't honestly remember how I picked > up that > > tidbit. I've always used == for equality tests as long as I can > remember. > > > > I did a quick "[ x$VAR = x ]" test before sending it off, but of > course > > $VAR was null so it returned true. Need to test a little more > thoroughly. > > > > Sorry about that. > > > FWIW, from the man bash page: > string1 == string2 > True if the strings are equal. = may be used in place of > == for > strict POSIX compliance. > > I wonder, is strict POSIX compliance a good or bad thing, and why? > > -- > -Eric 'shubes' > > _______________________________________________ > PLUG-applications mailing list > [email protected] > <mailto:[email protected]> > http://lists.plug.phoenix.az.us/cgi-bin/mailman/listinfo/plug-applications > > Reminder: All replies will go back to this mailing list. If you wish > to send a reply to a specific person, please use the reply function > and change the "To:" address to that person before sending. > > > First thing is that this was not a bash script but an sh script (note > the #! /bin/sh at the beginning) and according to the sh man page, test > expression or [ expression ] does consider the = operator to be a > comparison, not an assignment. Yes, it also talks about POSIX > compliance but it is not clear that for sh, that is the origin of the > definition. It is clear from the bash man page that they consider the > use of = as a conditional to be a POSIX issue. As Jason said, it would > probably break a lot of scripts to not allow that. > > OTOH, it appears that == is not meaningful in sh. > --
Right. == is not part of the bourne shell. It gets a little more complicated as you dig deeper. On Ubuntu (and I presume debian): shu...@edwin:~$ ls -l /bin/sh lrwxrwxrwx 1 root root 4 2009-01-03 02:20 /bin/sh -> dash On CentOS (and I presume fedora): [shu...@doris ~]$ ls -l /bin/sh lrwxrwxrwx 1 root root 4 Apr 5 18:39 /bin/sh -> bash == appears to be absent in the dash shell as well as the bourne shell. I'm not quite sure why bash does it this way. Possibly to be consistent with other comparison operators, and remove ambiguity with the assignment symbol. Using the single = would certainly be more portable. -- -Eric 'shubes' _______________________________________________ PLUG-applications mailing list [email protected] http://lists.plug.phoenix.az.us/cgi-bin/mailman/listinfo/plug-applications Reminder: All replies will go back to this mailing list. If you wish to send a reply to a specific person, please use the reply function and change the "To:" address to that person before sending.
