Bugzilla – Bug 131964
tcsh config numerous problems
Last modified: 2005-11-07 10:18:02 UTC
This patch fixes problems: * Various ~/ were not expanded due to a misplaced unset noglob. Main symptom: $HOME/bin is missing in PATH. If the reason for the bad placement was to ensure safe quoting of variables, then the correct solution is to use $var:q. * System paths (.../sbin) are concatenated to $PATH in the wrong place. As all the .../sbin have to be prepended and all the .../bin appended, another temp variable is required. The following problems are *NOT* fixed: * The setting of environment variables, most notably PATH, is different to the settings applied to bash. I don't think there was a SUSE release ever where things were right, so it's about time to get organised. For two users login in, one with chsh /bin/sh and the other with chsh /bin/tcsh, I expect to see identical output of env. I don't think anyone has ever tested this at SUSE. * The braindead tcsh design decision of running login after cshrc renders login essentially useless for environment variable settings, as some of them are already required in cshrc - most notably PATH. * Using csh.login for setting PATH is never any good, as PATH needs also be set for non-login shells. Try ssh remotehost env for a nasty surprise. * Programs like rsh, rcp, and ssh DO NOT RUN A LOGIN SHELL. See e.g. ssh remotehost mozilla for why this is a problem on SUSE. * It is arguable whether aliases, prompt etc should be defined for non-interactive shells, but terminal setups should be skipped. * Do not use the /bin/sh setup for setting PATH etc in tcsh. For starters, PATH gets longer with each subshell, and it never works anyway for users which have tcsh as their login shell (chsh). * There are interactive non-login shells, interactive login shells, non-interactive non-login shells, and possibly non-interactive login shells. It's a pity that nobody ever really manages to take care of that for tcsh. For bash it seems to just work. I believe it's a case of programmer PEBKAC, not a shortcoming of tcsh.
Created attachment 56211 [details] some tcsh config fixes
I'm maintainer of the bash and the tcsh and I've tested this. My daily shell for interactive work is the tcsh whereas my scripts are mainly written in bash or bourne shell syntax. For the 10.1 I've mainly rewritten the csh.login/csh.cshrc and the tcsh will now source csh.login before csh.cshrc because now the environment are set in csh.login. Btw: PATH _will_ be set in csh.login because this will be exported to every process started from this shell. Beside this: How often users change their shell? And believe me I now about interactive non-login shells, interactive login shells, non-interactive non-login shells ... For a login with slogin/ssh onto an other system the csh.login is executed beside this, if the $tty and $prompt is set and the user is owner of the terminal the terminal setups should be executed. For executio of a single command with ssh on a remote host the PATH is set by the ssh or should be know by the remote command, e.g. by using the full path, to avoid problems with other path layouts on the remote system. The commands rsh/rcp should not be used but slogin/ssh/scp.
The noglob is now disabled around the path expansion.
I hope you didn't have this really bad idea of recompiling tcsh to load csh.login before csh.cshrc? It's seriously bad because it breaks expected tcsh behaviour. The initial braindead decision about csh.login can't be fixed, you have to forget about csh.login ever existed and put its contents at the top of cshrc, surrounded by suitable if's. Feel free to use a sourced file between if..endif. If the path setting in csh.login is exported (i.e. inherited) by every subshell, how do you explain this behaviour: > ssh -l user remotehost echo '$path' /sbin /usr/sbin /usr/local/sbin /usr/bin /bin /usr/sbin /sbin /usr/lib/mit/bin /usr/lib/mit/sbin /usr/local/bin > ssh -l user remotehost ... remotehost|user[1]:~> echo $path /sbin /usr/sbin /usr/local/sbin /usr/bin /bin /usr/lib/mit/bin /usr/lib/mit/sbin /usr/local/bin /home/user2/bin /usr/games /opt/gnome/bin /opt/kde3/bin /usr/bin/X11 Note the difference in X11, KDE, gnome. Hence my stressing the different types of shells, and the need to set the path in all. How often users change shell is missing the point. The point is that whatever shell $USER chooses, (s)he expects the same environment variables!!! What have you done about the differences in environment variable settings between bash and tcsh? What have you done to ensure that with the next change to bash, the equivalent change happens to tcsh? What have you done about the incorrect .../sbin concatenation in the tcsh path? Btw I know I shouldn't use rcp, but on some boxes (not mine) there's no ssh and anyway it was an illustration about a point of tcsh, not of how to login in remotely. Reopening, too many unaddressed issues.
I'll will not switch back with the order of sourcing csh.login and csh.cshrc. The manual page state that this is also possible. If you want the same behaviour of bash and tcsh this is the way to go. And I've made /etc/profile and /etc/csh.login more equal by exchanging features and settings in both dirtections. I expect that you know that the ssh does not expand and never has expanded the path variable but only exported it. Therefore if you are only executing a remote command you'll get what you've done, see manual page of ssh: If command is specified, command is executed on the remote host instead of a login shell. ... maybe I do expand the path in /etc/bash.bashrc and /etc/csh.cshrc if the variable SSH_CLIENT is found the first time. An old idea of mine just similar to the method done for setting the locale if the variable SSH_SENDS_LOCALE is _not_ found.
Thanks Werner! If ssh cmd doesn't run any shell at all then that makes sense, but I don't understand your expansion of path in connection with SSH_CLIENT. If ssh cmd doesn't run a shell you'd never get to /etc/any-rc, and ssh without cmd runs a login shell. Will these changes come out for 10.0?
Try out openSuSE 10.1 ;) The sshd does use a simple system() function call, therefore it runs the SHELL found in passwd withj the option -c. For this reason I've added # # Just in case the user excutes a command with ssh # if test -n "$SSH_CLIENT" -a -z "$PROFILEREAD" ; then . /etc/profile > /dev/null 2>&1 fi to /etc/bash.bashrc ... and # # Just in case the user excutes a command with ssh # if ( ${?SSH_CLIENT} && ! ${?CSHRCREAD} ) then source /etc/csh.login >& /dev/null endif to /etc/csh.cshrc. I'm pretty sure that I'll will beaten by others for this change ;)