Improving <setenv>

Mark Ellis mark.uzumati at
Tue Mar 19 06:21:35 PST 2002

On 2002.03.10 11:01 Neven Has wrote:
> I'm working on (finally) creating a profile for MSB's keep5-6 hint
> (that would be the best abbreviation I could think of ;).
> The main problem is setting the environment (PATH) after chroot.
> With <setenv> as it is now, this is possible, but only if none of
> elements fail after it. It they do, <setenv> won't be run on the next
> retry (independent of the parser used, it just doesn't have the reason
> to),
> so the environment won't be reset.
> I was thinking that we could change the way <setenv> works into
> something like:
>     <setenv variable1="value1" variable2="value2">
>         <!-- Whatever needs variables set. -->
>     </setenv>
> This way, <setenv> will have to be run every time some element inside
> is.
> This seems like a much better implementation to me, not only for
> solving
> the above problem, but in general. It somehow looks more closer to
> what
> "setting the environment" really means (elements inside it being the
> elements inside that environment).
> Or not?

I kinda like the idea, but foresee a few problems. Firstly, you could 
never validate this through a DTD, ever, unless you had a DTD with all 
the variables you could ever want as attributes. On an aesthetic note, 
do we want more "nesting" elements than we already have ? Dunno why i'm 
mentioning this really, i'm undecided myself, just thought i'd throw it 
out there.

As an alternative to another nesting element, we could put env settings 
on the current nesting elements, maybe, probably makes little 
difference. As to the validation problem, the only thing that springs 
to mind is to have one "env" attribute that contained a string of 
'variable=value' s, separated by something you are certain will not 
appear in the strings themselves.

Would this then clear the environment space and put only these in, or 
them to the current space ?

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