Updated syntax.txt (was: looking for syntax wor...)

Gerard Beekmans gerard at linuxfromscratch.org
Fri Jan 12 11:58:17 PST 2001


> > <setenv>/<unsetenv>
> >
> > 	It's not really needed, but it can make things look prettier?
>
> prettier??? I say kill them...

Sometimes it's desirable to set environment variables. When?
If you enter chroot, the following can happen:

root:/mnt/lfs# chroot /mnt/lfs /usr/bin/env -i HOME=/root /bin/bash --login
root:/# echo $TERM
dumb


Yes, you can overcome this by typing:
root:/mnt/lfs# chroot /mnt/lfs /usr/bin/env -i HOME=/root TERM=xterm 
/bin/bash --login

But who's to say everybody is using an xterm? Perhaps TERM should be set to 
Linux. Or vt100. Or something.

Then again in the automated installation a set terminal doesn't do much good, 
you don't really need it.

Ok, better example

the CPPFLAGS=-Dre_max_failures=re_max_failures2 ./configure blah

This is failing quite often on some machines (unknown reason still, perhaps 
user error, perhaps the way that shell was setup) so I'm changing this to the 
following in the book:
export CPPFLAGS=-Dremaxetc
../configure
export CPPFLAGS=

the last line (empty value) will unset it (unset CPPFLAGS doens't work here, 
probably because i used export to set it rather than 'set')

And because back-end will run on a Linux distro (for now anyway) it may, at 
some people's systems, suffer from the "CPPFLAGS=blah ./configure" not 
working. Then the back-end should be able to fix this somehow. the <setenv> 
and <unsetenv> tags seemed a good idea to overcome those potential problems

-- 
Gerard Beekmans
www.linuxfromscratch.org

-*- If Linux doesn't have the solution, you have the wrong problem -*-

-- 
Unsubscribe: send email to alfs-discuss-request at linuxfromscratch.org
and put unsubscribe in the subject header of the message




More information about the alfs-discuss mailing list