Improving <setenv>

Seth W. Klein sk at
Thu Mar 21 10:26:16 PST 2002

Mark Ellis <mark.uzumati at> wrote:
> On 2002.03.21 09:28 Lee Saferite wrote:
> > I like the idea of <chroot>, <su>, and <setenv>  but for simplicity
> > (or mybe to make it more complicated)  why couldn't we have a:
> > <stage name="Ch.5 - Installing Bash" root="/some/dir" user="lfsuser"
> > group="lfs" env="E=mc2">
> > You could use the attibute addenv to append to the env.  and you would
> > have all env changes be aplicable only to elements of the stage tag.
> > I mean, if you look at it, every time you do a setenv or su or chroot
> > you are entering a 'stage' of the building process, no?
> > Comments/Flames welcome.  =)
> I think i like this, it might seem messy at first 'cos you'd have to 
> have most of those attributes as optional, but its versatile and could 
> even replace *build :) <ducks/>

<looksinnocent/> ;)

But strangely enough, i think i like it too. Lets see...

I didn't think i liked the name "stage", but on second thought, i think
i do like it.

Stages would have to nest and attribute values would have to be
inherited. Example:
<stage root="/some/dir" user="lfs">
 <stage user="root">
  <!-- stage.root is "/some/dir" -->

Can this replace package then? I think it can. It would add a grouping
element for packages, too. (I forget what that was called last time
someone suggested it.)


<stage name="Static Packages" wd="&LFS;" user="lfs" group="lfs">
 <stage name="Directory Structure">
  <stage wd="&LFS;/usr">
 <stage name="Bash" version="2.05a" wd="&LFS;/usr/src">
  <stage wd="&LFS;/usr/src/&bash-directory;">
   <stage env="&OPT;">
    <!-- newer configure scripts don't need this 'cause they
         take variables on the command line -->
  <stage wd="&LFS;/bin">
<stage name="Chroot Packages" chroot="&LFS;" user="root" group="root"
  envclearto="TERM="$TERM" HOME=/root">

So i have
  wd="/"      <!-- working directory, hoping that someone would think
                   of a good name 'cause i haven't -->
  env=""      <!-- at least in my profiles, add is the common case -->
  envclearto=<no default> <!-- and total reset rare  -->
  user=<user running the tool>
  chroot=<no default>
  role|class|etc.=  <!-- maybe something like this for *build people
                         who just _have_ surround their elements with
                         an extra layer ;) <ducks/> -->

> Still one problem, specifying more than one env variable. A separation 
> character works in something like $PATH 'cos that character can never 
> appear in what it is separating. Everyones mission should they choose 
> to accept it is to think of how to separate arbitrary env var content 
> that can conceivably contain anything, while staying within the limits 
> of legal XML. I'm off to the pub :)

~ $ cd var/tmp/
~/var/tmp $ echo 'echo $FOO $BAR' > echovar
~/var/tmp $ FOO="-march=i986 -cpu=i986" BAR="-O9 $FOO -pipe" bash echovar
-march=i986 -cpu=i986 -O9 -march=i986 -cpu=i986 -pipe
~/var/tmp $ FOO="-march=i986 -cpu=i986" BAR='-O9 $FOO -pipe' bash echovar
-march=i986 -cpu=i986 -O9 $FOO -pipe
~/var/tmp $ rm echovar 
~/var/tmp $ 

So maybe:
<stage env="FOO="-march=i986 -cpu=i986" BAR="-O9 $FOO -pipe"">
Would make the life of real parser writers difficult, but they'll have
trouble anyway because they'll need to handle PATH=$PATH:/bar (won't
they), and everyone who just passes this stuff off to bash will have
to problems.

Seth W. Klein
sk at                   
Maintainer, LFS FAQ       
             Life on the edge? You're taking too much space
       if you're not living hanging from your safty harness rope.       
Unsubscribe: send email to listar at
and put 'unsubscribe alfs-discuss' in the subject header of the message

More information about the alfs-discuss mailing list