In tcsh-6.14-r33 various settings were moved from /etc/csh.cshrc to /etc/csh.login (default $PATH definition; source of /etc/profile.d/*.csh ...). The login process in a X-Window session didn't start a login-shell at any time so /etc/csh.login is never sourced. After the start of xterm or a similar x-terminal with a non login-shell (which is the default) no applications are usable. Possible fixes are: 1. start the shell in xterm as login-shell (but this isn't what a login-shell should be) 2. start the window-manager from a login-shell (maybe a bug of gdm?) 3. Old behavior of doing this kind of work in /etc/csh.cshrc A similar problem is described in the closed bug #13579 of 2003. Please note that this isn't a problem if you login through ssh. The sshd spawn a login shell and everything is ok. Also this is a X-Terminal where the X-Server run on a separate host, but I don't think this should be a problem. Reproducible: Always Steps to Reproduce: 1.Make tcsh your login shell in /etc/passwd 2.Login through xdm/gdm (No startx) 3.start xterm (which didn't spawn a login-shell) Actual Results: No programs are in the search path. Portage 2.1.2.4 (default-linux/amd64/2006.1, gcc-4.1.2, glibc-2.5-r1, 2.6.20-gentoo-r6 x86_64) ================================================================= System uname: 2.6.20-gentoo-r6 x86_64 AMD Opteron(tm) Processor 248 Gentoo Base System release 1.12.10 Timestamp of tree: Tue, 24 Apr 2007 07:20:01 +0000 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.4 [enabled] dev-java/java-config: 1.3.7, 2.0.31-r7 dev-lang/python: 2.4.4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r7 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.23b virtual/os-headers: 2.6.20-r2 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O3 -march=k8 -pipe -funroll-loops -fomit-frame-pointer" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/NX/etc /usr/NX/home /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/X11/app-defaults /etc/X11/serverconfig /etc/X11/starthere /etc/X11/sysconfig /etc/env.d /etc/env.d/java/ /etc/gconf /etc/init.d /etc/java-config/vms/ /etc/revdep-rebuild /etc/sound /etc/terminfo /etc/texmf/web2c /usr/X11R6/lib/X11/xkb /usr/share/X11/xkb /usr/share/texmf/dvips/config" CXXFLAGS="-O3 -march=k8 -pipe -funroll-loops -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks metadata-transfer parallel-fetch sandbox sfperms strict userfetch userpriv" GENTOO_MIRRORS="ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo http://pandemonium.tiscali.de/pub/gentoo/ ftp://pandemonium.tiscali.de/pub/gentoo/ http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/" LINGUAS="de en" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="X X509 aalib acpi alsa amd64 apache2 bash-completion berkdb bitmap-fonts blas browserplugin bzip2 bzlib cairo cdr chroot cli cracklib crypt cups dbus divx4linux dvd dvdr dvi eds emacs encode erandom exif f77 foomaticdb fortran gd gdbm gecko-sdk gif gimpprint glitz gnome gnutls gphoto2 gpm graphviz gstreamer gtk gtk2 gtkhtml hal howl iconv idea imap isdnlog java jbig jpeg lcms ldap libg++ libsexy lm_sensors logrotate mailwrapper md5sum midi mime mng mozcalendar mp3 mpeg mysql nas nautilus ncurses nis nls nntp nptl nptlonly nsplugin opengl pam pcre pdf pdflib perl pic plotutils png postscript ppds pppd python qt qt3 qt4 quicktime readline reflection rrdtool samba sdl session sftplogging slp smp spell spl ssl svg t1lib tcpd threads tiff truetype truetype-fonts type1-fonts unicode vim-with-x wmf xinerama xml xml2 xorg xpm xprint xv xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de en" USERLAND="GNU" VIDEO_CARDS="vesa" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Thank you for this bug. This feels kind of weird. The behaviour is copied from what the bash shell does. In fact this whole change was necessary to facilitate KDE users to have a working tcsh shell. If you start a shell from your window manager, it should inherit the path from the environment set by the window manager. If the window manager doesn't set it, you need to start a login shell. From the KDE case I recall that there the login specific files (etc/profile and etc/csh.login) were explicitly called after starting the window manager to get the correct environment. This is a bit confusing to me here. I wonder how bash is dealt with using a gnome/gdm setup. As I lack a system that has this setup, could you try and see if you can find out what route the windowmanager takes to startup the environment, and what the difference between bash and tcsh are there?
Hi Fabian, after some more specific research it turns out that this isn't a bug of the tcsh login. Unfortunately there was a .profile from a old solaris installation in my home directory which override all necessary settings. But after all there are some different methods used for the login process. X: /etc/profile and $HOME/.profile are sourced - which is a sh compatible conf file as far as I know - my wm is started in a "sh" shell so this is the point were this file is executed(I think) /etc/csh.login is NOT sourced at all Remote login: /etc/csh.login is sourced no "profile" is sourced Because /etc/profile dose nearly the same as csh.login all functionality is available. I don't know how other linux distributions implement the tcsh (or any other) login process. For now it seems no problem at all. Sorry for reporting of a wrong bug report. Best regards Christian
(In reply to comment #2) > Hi Fabian, > after some more specific research it turns out that this isn't a bug of the > tcsh login. Unfortunately there was a .profile from a old solaris installation > in my home directory which override all necessary settings. But after all there > are some different methods used for the login process. Ok, that kills things :) > X: > /etc/profile and $HOME/.profile are sourced > - which is a sh compatible conf file as far as I know > - my wm is started in a "sh" shell so this is the point were this file is > executed(I think) > /etc/csh.login is NOT sourced at all Probably because no other shell but the sh-shell is being used. > Remote login: > /etc/csh.login is sourced > no "profile" is sourced that's because your shell is tcsh, and it doesn't use /etc/profile at all. > Because /etc/profile dose nearly the same as csh.login all functionality is > available. I don't know how other linux distributions implement the tcsh (or > any other) login process. csh.login is the tcsh equivalent of profile. > For now it seems no problem at all. Sorry for reporting of a wrong bug report. No problem. Better a bug then a problem going without being noticed and you switching to something else. I take I can close this bug then.
(In reply to comment #3) Some additional comment. As noticed before the path problem is gone. As I wrote, in the X login process no csh.login is executed. But there is the place where the /etc/profile.d/*.csh scripts will be sourced (this was done in csh.cshrc in the old tcsh scripts). So in the end no one of this scripts is executed if I login through X ;-(. Now I source them in my own .cshrc. Maybe you could check other linux distributions and the login process of tcsh there.
