Updated syntax.txt (was: looking for syntax wor...)
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
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:
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
-*- 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