LFS-6.0 print process

Bryan Kadzban bryan at kadzban.is-a-geek.net
Thu Jul 8 20:27:36 PDT 2004


Nathan Coulson wrote:
> b's not as easy as I thought it was

Heh, I noticed that last night.  No biggie, though, I figured out a sort
of easy way around most of the difficulties.  (Yikes.  ;-) )

> Between the 3 of us, perhaps one of us wont get stuck (::.  Perhaps I
> cant use subshells like I want to.

That's what I ended up doing, getting rid of the second subshell.  Not
only is it a problem that it can't keep the value of SERVICE in the
parent like we should, but the subshell also won't inherit any "global"
variables that come before the first SERVICE line unless they're
specifically exported.

I also realized that it would probably be good if the $SERVICE script
had a way to differentiate between invocations of itself if necessary.

In the end, instead of having SERVICE= lines break each invocation, I
introduced another variable, LABEL.  Each LABEL= line introduces another
"section".  The value of LABEL (along with $1, the interface) is what
the $SERVICE script uses to differentiate between invocations of itself
in messages to the user.

Since ifconfig.<interface> is now a bit different, I've included an 
ifconfig.eth0.sample file in the sysconfig/network-devices directory. 
This is not installed ever, it's only in the bootscripts package for a 
bit more documentation on how it works.

An overview:

I actually have 3 while loops, not 2.  The first one is there to read in
and set the "global" variables (they're set for everything related to
this interface).  The second one, while it is lexically inside the first
one, is really independent.  Once the second loop is entered, it won't
be exited until end-of-file (at which point the first will also exit).
The second loop handles each invocation of the right $SERVICE script.

The third loop reads each variable for that specific section.  It's
broken out of when either another LABEL gets set, or end of file is found.

After the third loop exits, I save the new LABEL (since I've basically
read one line too far, and I'll need to redo the line I just read) and
restore the "old" one (really the current one).  Then I do the old error
checking (is SERVICE set? does the .../$SERVICE script exist?).

If that succeeds, then I actually source the $SERVICE script instead of
running it like the current ifup/down scripts do.  This is because the
$SERVICE scripts no longer source ifconfig.$1 themselves (they don't
know which section they should look at), but instead rely on variables
set by the third loop in ifup/down.  Since those variables aren't
exported, the $SERVICE script needs to run in the same shell as ifup or
ifdown.

The other issue with this is that $SERVICE scripts can no longer use
exit, unless they want to interrupt ifup/down (not generally a good
idea).  The only time the static script does this is when it's called
with incorrect arguments; this is (arguably) as it should be.

After the $SERVICE script is done, ifup/down restore LABEL to what it
should be for the next iteration of the second while loop, and then
unset each of the (local) variables that got set by the last section.
Then, UNSET (the variable which holds the names of the local variables)
gets unset, just to keep stuff clean.  It won't really affect anything
if UNSET doesn't get unset, but variables will be unset twice if that
happens.

Although it occurs to me -- if the user sets up a global, and then later
sets up a local with the same name, the global's value will be lost.
Maybe this isn't a big deal, but I've made some comments in the sample 
ifconfig file outlining the issue.

Anyway, the patch against 20040704 is attached.  Comments are sprinkled
throughout ifup, but ifdown was kept more sparse.  I expect that most of 
the comments will be removed (if not, then whatever is kept should be
copied to ifdown also).
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: multiple-services-4.patch
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20040708/efb5d447/attachment.ksh>


More information about the lfs-dev mailing list