| 1 |
Hi! |
| 2 |
|
| 3 |
I'm a Gentoo newbie (a couple of years of Linux experience though). |
| 4 |
Since I just made a clean stage1 install I have to configure my |
| 5 |
system. And the first thing I did have brought me some annoying |
| 6 |
"problems". |
| 7 |
|
| 8 |
Particularly, I modified the LESS variable in /etc/env.d/70less so I |
| 9 |
have some info displayed. And then I did env-update which updated my |
| 10 |
/etc/profile.env. After reboot though profile.env lacked the changes I |
| 11 |
made (LESS wasn't there). So I did env-update again and it updated |
| 12 |
profile.env just fine. But after every reboot LESS was gone again. |
| 13 |
|
| 14 |
After some hours I found out that the problem was caused by |
| 15 |
/sbin/rc-envupdate.sh script that was called on reboot from 'bootmisc' |
| 16 |
in runlevel 'boot' (when it says "Updating environment"). After some |
| 17 |
debugging I found out that, when rc-envupdate.sh parses the files in |
| 18 |
/etc/env.d it creates a list of variables it founds. But every name is |
| 19 |
only once in the list so it knows what to write to profile.env . |
| 20 |
|
| 21 |
The ambiguity check is pretty simple: the first match of current |
| 22 |
variable is deleted from the list of already known variables and the |
| 23 |
resulting list is compared to the original list. If they are equal |
| 24 |
then we have a new variable, if they are not equal then we have found |
| 25 |
an already known variable. |
| 26 |
|
| 27 |
Now to my problem. In /etc/env.d/00basic there is a variable called |
| 28 |
LESSOPEN. My LESS variable is in 70less so it is parsed later. While |
| 29 |
rc-envupdate.sh was making check on LESS it simply deleted LESS from |
| 30 |
LESSOPEN because LESSOPEN already was in the list. It means that |
| 31 |
rc-envupdate.sh doesn't check for whole words but only for substrings |
| 32 |
(env-update _does_ look for words). |
| 33 |
|
| 34 |
I don't think this is a serious bug, since everybody can just change |
| 35 |
the 'bootmisc' script to call env-update instead. But env-update is |
| 36 |
written in python and needs more time to do the same job |
| 37 |
(rc-envupdate.sh is in bash). I don't whether I should file a bug |
| 38 |
report, but I didn't find anything similar in the bug database. |
| 39 |
|
| 40 |
So here is the patch (or in the attachment): |
| 41 |
========================= patch starts here ========================= |
| 42 |
--- rc-envupdate.sh 2003-03-14 02:06:07.000000000 +0100 |
| 43 |
+++ rc-envupdate.sh.new 2003-03-15 01:09:15.000000000 +0100 |
| 44 |
@@ -52,14 +52,14 @@ |
| 45 |
(/bin/awk '!/^#|^\t+#/ { gsub ( /=/, "\t" ) ; print $0 }' ${x}) | \ |
| 46 |
while read -r variable value |
| 47 |
do |
| 48 |
- if [ "$(eval echo \${VARLIST/${variable}/})" = "${VARLIST}" -a \ |
| 49 |
+ if [ "$(eval echo \${VARLIST/ ${variable} /})" = "$(eval echo \${VARLIST/# /})" -a \ |
| 50 |
-n "${variable}" -a -n "${value}" ] |
| 51 |
then |
| 52 |
if [ -n "${VARLIST}" ] |
| 53 |
then |
| 54 |
- VARLIST="${VARLIST} ${variable}" |
| 55 |
+ VARLIST="${VARLIST} ${variable} " |
| 56 |
else |
| 57 |
- VARLIST="${variable}" |
| 58 |
+ VARLIST=" ${variable} " |
| 59 |
fi |
| 60 |
echo "${VARLIST}" >${svcdir}/varlist |
| 61 |
fi |
| 62 |
========================= patch ends here ========================= |
| 63 |
|
| 64 |
|
| 65 |
Did anybody experience this behavior? |
| 66 |
|
| 67 |
|
| 68 |
Regards, |
| 69 |
Renat |
| 70 |
|
| 71 |
-- |
| 72 |
Don't worry. Be hippy. |
Archives