Hi I have a variable which needs use of $HOME. I created file /etc/env.d/99svn: SVN_SSH="ssh -i '\$HOME'/.ssh/id_dsa.subversion" So it works. But first I wrote : SVN_SSH=SVN_SSH="ssh -i $HOME/.ssh/id_dsa.subversion" which seems to be more natural... with env-update.sh it generated into /etc/profile.env: SVN_SSH='ssh -i /root/.ssh/id_dsa.subversion' with python version: SVN_SSH='ssh -i /.ssh/id_dsa.subversion'
Don't restrict bugs...
why not just use ~/.ssh/...
When I use "~/.ssh/...." I have errors with "svn svn+ssh://...../repos". It says "~/.ssh/id_dsa.subversion: no such file or directory" Maybe ssh doesn't support ~/ path format?
I would say what you get with env-update.sh is expected behaviour. It's normal that you have to escape variables which you don't want to evaluate immediately. It's a bug though that env-update doesn't evaluate variables at all, IMHO.
(In reply to comment #4) > It's a bug though that env-update doesn't evaluate variables at all, IMHO. So would I, as well as the following: In my case I use in /etc/env.d/99oracle lines like: ORACLE_BASE=/opt/oracle ORACLE_HOME=$ORACLE_BASE/product/10.2.0.1.0 and later in the shall I try to use ORCALE_HOME: echo $ORACLE_BASE"\n"$ORACLE_HOME /opt/oracle $ORACLE_BASE/product/10.2.0.1.0 and it is not working as expected. Expected would be to have ORACLE_HOME containing: /opt/oracle/product/10.2.0.1.0 Am I wrong?
(In reply to comment #4) > It's a bug though that env-update doesn't evaluate variables at all, IMHO. Evaluating variables from just within /etc/env.d vs. including the calling environment are two possible ways to go about it. I could understand the former but the latter seems like a bad idea to me.
One other thing to consider is that env-update treats some variables as cumulative while others overwrite previous values. That leads to some ambiguity in how variables should be evaluated. Should cumulative variables be accumulated before evaluations, during, or after? After considering this, I thing this bug is a WONTFIX.
So we (or at least I) have a minor conflict: in http://gentoo-wiki.com/HOWTO_Install_Oracle_10g#Setup_Variables there is a recommendation about setting variables which will be evaluated immediatly. So either the how-to, env-update or my understanding is wrong. Thanks for spending some light on this.
the howto is wrong
*** Bug 151544 has been marked as a duplicate of this bug. ***
*** Bug 170381 has been marked as a duplicate of this bug. ***
If it really won't be supported, there should be a warning, when running `env-update`, when a variable tries to reference another one (detect "$", if not prefixed with a backslash). Something like: `ewarn "In file /etc/env.d/example, variable EXAMPLE tries to reference another variable (EXAMPLE2), which is not supported. You should remove the reference, to avoid any problem."`. The manual should also be updated, to add a more general warning (http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=5 says nothing about it -it just says that some variables will be concatenated, instead of replaced). As it is counterintuitive, there should really be some more information about it. I had some problem with a few ebuilds which used the ":=" operator, in makefiles, as Make will try to interpret the referenced variable (as it is kept as is by `env-update`), and if the referenced variable is a reference to itself (for example, in "/etc/env.d/02ccache", I had `ROOTPATH="/usr/lib/ccache/bin:${PATH}"`), Make will halt, with this error: "*** Recursive variable `PATH' references itself (eventually). Stop."... (see bug #175569 and bug #171171). As "/etc/profile" does not seem to be sourced by my terminal (non-login shell, which does not seem to inherit the login shell environment variables... -well, that's another problem I'll deal with later), it took me some time to understand where was the problem coming from, as my PATH was the default one (which surely should have been a hint, but I didn't get it...), so I thought the problem was coming from the packages themselves... (I thought about some compatibility problem with Make, or something like this...).
This one is similar to bug 176139 where we have multiple overlapping references. We have /etc/env.d/ mentioned in at least 2 places: http://devmanual.gentoo.org/tasks-reference/environment/index.html http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=5 The Gentoo Developer Handbook avoids duplication by referencing the other handbook for /etc/env.d documentation: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1#doc_chap3 The behavior of the special SPACE_SEPARATED and COLON_SEPARATED variables doesn't seem to be officially documented anywhere at the moment. It's described here: http://archives.gentoo.org/gentoo-dev/msg_91855.xml
(In reply to comment #13) So, does the GDP need to make any changes to any documents in /doc/? Documents not in /doc/ are not our territory, and if there are no changes to make we don't need to be CCed on this.
For the GDP, I think this part is an occasional source of confusion for users: http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=5#doc_chap2_sect1 It tells users that they can define variables there but it doesn't say anything about what syntax is allowed there. Sometimes users assume that they can use shell variables in the definition of other variables and that's actually not supported.
(In reply to comment #15) Done. Added a note in the handbook forbidding using shell variables to define other variables.
So what's left to do here?
I think we can close this now. The warning in the handbook should be enough to prevent confusion.
*** Bug 211087 has been marked as a duplicate of this bug. ***
*** Bug 212335 has been marked as a duplicate of this bug. ***
I have altered the Oracle HOWTO to show a sample profile.d script instead of the env.d script which included previous variables. The original env.d script with no expansion is still there.
