https://bugzilla.novell.com/show_bug.cgi?id=244788 werner@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |suse@tlinx.org ------- Comment #3 from werner@novell.com 2007-02-15 03:41 MST ------- IMHO ... the current standard behaviour of the bash is somewhat broken without this change. I've get a large numbers of reports that the path after a `slogin host.remote' or `ssh host.remote' the system PATH environment variable from the remote among other environment variables is not provided. Most people do not use the fulls path for e.g. xemacs or an kde application but only the basename even with a non-interactive ssh usage. This does not happen on the local system because after login (/bin/login or xdm/kdm/gdm) the /etc/profile was sourced by the bash. All processes afterwards have the full environment of the local system. Now after doing a `slogin host.remote' the remote system environment was never set because the ssh daemon does not a real login even if the ssh command is called a slogin. Beside this sourcing /etc/bash.bashrc only for non-login but interactive bash processes was also the cause of a large numbers of reports within my bugzilla and mail folder. One reason for souring the /etc/bash.bashrc within /etc/profile not only on SuSE. Currently I've done the setup in this a way that system environment is exported in /etc/profile or /etc/csh.login for tcsh users at login and afterwards not exported things like aliases and prompts are set by /etc/bash.bashrc or /etc/csh.cshrc for tcsh users. To solve the problem of missing the system environment for an ssh login the /etc/bash.bashrc and the /etc/csh.cshrc test about the exported readonly variable which is set by souring /etc/profile (PROFILEREAD) respectivly by souring /etc/csh.login (CSHRCREAD) for an ssh session only and if those variables are not set they source the system environment aka /etc/profile respectivly /etc/csh.login. Please see that the files /etc/profile respectivly /etc/csh.login also include the environment provided by /etc/profile.d/*.sh and /etc/profile.d/*.csh provided by all packages using environment variables . as you may understand I'd like not to loose this by removing the lines in /etc/bash.bashrc you mentioned nor in /etc/csh.cshrc. One suggestion about the problem of sourcing files twice is to use an exported readonly variable. This I'm using because there are many users out there which do source /etc/profile within their ~/.bashrc due to mentioned problem above. This had caused a lot of trouble by sourcing things twice or within loops. This might be also an option to solve your problem I've caused with this change. That is the possiblity to add some bourne shell code to your files which should work on all systems. For sourced only bourne shell file this may look like test -z "$MYFILERAD" || return readonly MYFILERAD=true export MYFILERAD what do you think about this? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.