Bug#250765: kdm: never spawns a login shell; thus ~/.bash_profile is never read
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=250765 for the full BTS discussion. martin f krafft wrote: On all KDE systems I administer, ~/.bash_profile is never read. This has gotten a lot of discussion lately on debian-user. Look at all of the postings about this! And these are not all of them, just those found after a brief search. http://lists.debian.org/debian-x/2003/03/msg00255.html http://lists.debian.org/debian-user/2003/09/msg02518.html http://lists.debian.org/debian-user/2004/03/msg17308.html http://lists.debian.org/debian-user/2004/05/msg03884.html - Which started this bug! http://lists.debian.org/debian-user/2004/06/msg01093.html http://lists.debian.org/debian-user/2004/06/msg00669.html http://lists.debian.org/debian-user/2004/06/msg01990.html http://lists.debian.org/debian-user/2004/06/msg02270.html I list those many out just to show that many people are having problems. In http://lists.debian.org/debian-user/2004/06/msg04016.html Mike Allen suggests: Another method that uses the user's default shell is to change: /etc/X11/Xsession.d/99xfree86-common_start to read: exec -l $SHELL -c $STARTUP Clever. I like it. But I point out in the next note that 'exec -l' is a bash'ism and that #!/bin/bash would be needed for Xsession. But otherwise I can't find anything seriously wrong with this solution. It nicely solves the problem of specifying the shell by not specifying the shell. I would normally eschew non-posix shell solutions like this but can't see a reasonable substitute. The only downside that I can see is that if someone already has a ~/.xsession with '#!/bin/bash --login;exec x-session-manager' then the environment scripts are read twice when the user logs in with [gkx]dm. But that hardly seems like an overwhelming disadvantage. In http://lists.debian.org/debian-user/2004/06/msg02361.html Mike further points out that Red Hat uses just that technique. That is, the technique of doing the following pseudo-code. #!/bin/bash exec -l $SHELL -c $STARTUP I think a solution has been found by Red Hat. I think Debian should implement the same technique. It promotes compatibility between the distros. It resolves a long running xdm login problem for newbies. Comments? Bob -- Bob Proulx [EMAIL PROTECTED] http://www.proulx.com/~bob/ CP-ASEL-IA-Tailwheel-Glider pgpcOdchOBxHg.pgp Description: PGP signature
Bug#250765: kdm: never spawns a login shell; thus ~/.bash_profile is never read
martin f krafft wrote: also sprach Bob Proulx [EMAIL PROTECTED] [2004.06.01.0305 +0200]: thought. The first user who put '. /etc/bash_completion' into their $HOME/.profile (read by bash at login) broke things because that is not /bin/sh shell syntax in there. So just noting one type of failure mechanism. you mean 'source /etc/bash_completion'? I think '. /etc...' is /bin/sh. source is bashism. At least that's what lintian says... Traditional /bin/sh Bourne and compatible shells use '. file' to source files. /bin/csh and compatible shells use 'source file' to source files. Bash is a combination and will accept either syntax. So lintian is correct to identify that as a bashism. But the problem is not the syntax of the '. /etc/bash_completion' but rather the contents of /etc/bash_completion which is bash specific. If you try load it into /bin/sh (even one linked to /bin/bash) then it will have errors. Bob pgp55oSgaXhfY.pgp Description: PGP signature
Bug#250765: kdm: never spawns a login shell; thus ~/.bash_profile is never read
martin f krafft wrote: On all KDE systems I administer, ~/.bash_profile is never read. Thus, any entries in there -- quite a few in the case of a programmer -- are never read. I think this is because KDM never spawns a login shell, and Konsole doesn't either. Could this please be fixed? There are a lot of reasons why kdmsession or the like should be started as a child of a proper login shell. Perhaps. But how? The implementation for different users with bash, csh, zsh, ksh, some other weird shell, is probably not impossible but I can't think of a way to handle it cleanly. This is an upstream FAQ: http://www.kde.org/documentation/faq/configure.html#id2913380 Summary: 9.7. KDE (kdm) does not read my .bash_profile! The login managersxdm and kdm do not run a login shell, so .profile, .bash_profile, etc. are not sourced. When the user logs in, xdm runs Xstartup as root and then Xsession as user. So the normal practice is to add statements in Xsession to source the user profile. Please edit your Xsession and .xsession files. They purposefully avoid reading the user's environment. When you select KDE you select *only* KDE and nothing else but KDE. I imagine it is just too difficult to guess the user's login shell and get the syntax right for all of the possibilities so they avoid it entirely. But I am not a KDE developer and do not know the actual reasons. Use a .xsession file with the #! line using your login shell and passing in whatever options your shell uses to make it a login shell. That will read your login environment. Here is one example for a bash shell as the login shell. #!/bin/bash --login exec x-session-manager # or startkde or fvwm or whatever Make sure it is executable or it will have no effect. chmod a+x $HOME/.xsession Then when you log in with kdm/gdm/xdm make sure you select default and not specifically KDE since selecting KDE avoids reading your environment files. Bob -- Bob Proulx [EMAIL PROTECTED] http://www.proulx.com/~bob/ CP-ASEL-IA-Tailwheel-Glider pgpFZKPbg2W2J.pgp Description: PGP signature
Bug#250765: kdm: never spawns a login shell; thus ~/.bash_profile is never read
martin f krafft wrote:
also sprach Bob Proulx [EMAIL PROTECTED] [2004.06.01.0108 +0200]:
Perhaps. But how? The implementation for different users with bash,
csh, zsh, ksh, some other weird shell, is probably not impossible but
I can't think of a way to handle it cleanly.
exec $(getent passwd `whoami` | cut -d: -f7) --login -c Xsession
?
Assume /bin/ksh as the login shell for one counter example. That does
not produce a valid command for ksh.
ksh --login
ksh: ksh: --: unknown option
Nor for /bin/csh.
csh --login
Unknown option: `--login'
Usage: csh [ -bcdefilmnqstvVxX ] [ argument ... ].
The ksh needs -l to be told it is a login shell. That works for bash
and zsh too so looks promising. But csh won't take -l unless it is
the only option present. I can't think of a way to pass an option to
a shell and have it work for every possible shell.
One time in the past I tried using a file of my construction at
/etc/X11/Xsession.d/95xfree86-common_userprofile which would load up
the user's profile. But at that time the script is /bin/sh. I knew
that but we were all running bourne compatible shells. Or so I
thought. The first user who put '. /etc/bash_completion' into their
$HOME/.profile (read by bash at login) broke things because that is
not /bin/sh shell syntax in there. So just noting one type of failure
mechanism.
The real answer would have to be that the program name starts with a
'-' like login shells expect. Of course we can do that[1], but then
we need to be able to tell the shell in the shell's command syntax to
run the Xsession command.
# just for example but not for real
echo Xsession | -$(basename $SHELL)
Something along those lines seems like the best way to go.
I think upstream is the right place to push these types of design
decisions. This is not specific to Debian in any way. KDE has this
issue on all platforms.
#!/bin/bash --login
exec x-session-manager # or startkde or fvwm or whatever
Thanks. That's what I have been doing. It's just ugly...
And poorly documented.
Bob
[1] Perl comes to mind. Off the top of my head. Untested!
#!/usr/bin/perl
my $SHELL = $ENV{'SHELL'};
my $SHELL_BASENAME = $SHELL;
$SHELL_BASENAME =~ [EMAIL PROTECTED]/@@;
exec {$SHELL} -$SHELL_BASENAME;
--
Bob Proulx [EMAIL PROTECTED]
http://www.proulx.com/~bob/
CP-ASEL-IA-Tailwheel-Glider
pgpX3x4sVrTCu.pgp
Description: PGP signature
