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

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
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

-*- 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