Description of Problem:
The user supplies a correct login and password to the display manager. The
display manager window reappears asking for a login and password and displaying
no error message.
exec -l $SHELL -c "gnome-session"
and several related lines. This starts login shells that execute commands.
This behavior is very prone to error, and the errors are very difficult to trace
(it just took me 3.5 hours, and I've been hacking Unix systems for 18 years).
Here are some of the ways how this behavior breaks:
1. See bug 59001
2. If the .login file does something that needs a tty.
3. If the .login file does any action depending on the existence of a variable
that is usually defined in an interactive shell but not in the Xsession shell,
such as $TERM.
4. If the .login file execs something, such as ssh-agent $SHELL -l. This
"forgets" the command following -c.
In all these cases, the login simply exits and the display manager login window
appears. The user is locked out of his system and has no idea why. In many of
these cases, there is no message in .xsession-errors.
Version-Release number of selected component (if applicable):
I see that you may want the user to be able to set a path or something before
doing the exec. However, perhaps it would be better to let that be done in a
.xsession file, where the user takes control and knows the consequences. Many
normal .login files break here and with little chance to produce error output.
Few users would expect their .login files to be executed *before* the session
starts, or in any environment that could be considered noninteractive (not
having a tty, not having $TERM, with -c). Also, there is essentially zero
user-level documentation on how window-system logins work. There are no man
pages for the popular display managers, and the complicated system of
cross-calls and fallbacks is challenging for an intermediate user to trace. For
example, I found different commands being executed by Xsession (or something
else) depending on whether I had a .gnome directory or not. If you choose to
keep this behavior, it needs to be documented prominently.
Note that tcsh explicitly disallows the use of -l and -c together, and only the
"-" as argv method can make it happen. Clearly it was not intended to be
used this way.
Generally, modification of any of the X startup files for tcsh has broken
long standing behaviour in bash. Changing all of the entire startup sequence
of XFree86 to do the correct thing for all possible shells is quite a daunting
task to take on, and one of little gain.
The number of tcsh/csh and non-bash users using Linux is quite small compared
to those using bash as their primary login shell. The amount of effort to
go through all startup scripts, including GNOME and KDE's scripts (which
have been affected by various changes in the past), and various i18n related
files as well, and ensure that any given change allows everything that works
now, will continue working, is just too risky for so little gain.
The number of people who report such problems is also extremely small, and
my experience has been that they've customized their environement in some
ways often and are doing something wrong. They don't always see that it is
wrong mind you, but there have indeed been cases. Again, the amount of effort
to troubleshoot all of these types of special case scenarios is quite great.
As such, the officially supported login shell in Red Hat Linux is bash.
Other shells are provided for convenience, etc. but users using them as
general purpose login shells are recommended to use bash instead, or to
fire up tcsh or other shells as subshells from within bash in an xterm,
Again, I understand that this may not be the most convenient resolution to
tcsh users, but IMHO the risks are too high to break our existing setup.
I'm surprised it took 11 months to come up with this answer. And, the
answer overlooks a much simpler solution that eliminates the very
problems you cite with shells in X startup. The dangerous section of
/etc/X11/xdm/Xsession is below. All of these commands are of the
exec -l $SHELL -c "some-command"
My suggestion is to eliminate the "-l $SHELL -c" from all of these,
add a "-ls" in the falseafe xterm command, and just exec the session
What the "-l $SHELL -c" does is execute an unknown shell as a login
shell, asking it to run the command. This makes all the trouble you
say you want to avoid.
The login shell in turn *probably* executes commands in files like
.cshrc, .bash_profile, etc. before running the command. It again may
execute commands in .logout or .bash_logout afterward. Why would
users want to have their dotfiles sourced at this point? The window
system clients should already have all the environment they need, and
the user can only mess that up. Dotfiles legitimately exec other
commands, look for terminal input, etc., all of which prevents the
window system from starting under the present scheme.
If you want users to be able to alter the environment here, they can
use ~/.xsession and then call gnome-session or whatever themselves.
Starting a login shell here forces potentially all users to be aware
of a new and highly unusual place for their dotfiles to be executed,
in a non-interactive situation without a TTY. Remember that unlike
.xsession, shell startup files don't belong to the window system.
They also get executed in the case of remote shell logins and
subsidiary terminal windows, so executing them at this unexpected
point, without a TTY, is looking for trouble of the kind you said you
wanted to avoid.
A further suggestion, and one that is at least as important, is to add
to user documentation a description of the window startup process, so
they can know where to look for problems such as I encountered. You
have to be quite an expert to grovel through the maze of X startup and
find this little subtlety. It's doubly hard if you have no root
access and can't easily login a dozen times, tweaking files to figure
out what you did that broke things. Well-designed systems take pains
to avoid such lockout situations.
Finally, I've heard the assertion that bash is the preferred shell
several times, but I've never seen any data to support it. Perhaps
10% of the hundreds of Linux users I encounter at Cornell use bash. I
suspect that the 25-year-old disparity in shell preferences between
the university (Berkeley) and business (SysV) communities persists,
and you see what is out there in the business world. Not all of your
customers share your view, and if you take the position that you are
only supporting what you (or even a nominal majority) likes, you will
damage the inclusiveness that makes Linux popular. Better is to make
the design robust by not incorporating an unknown shell in the middle
of the startup process.
# now, we see if xdm/gdm/kdm has asked for a specific environment
case $# in
if [ -x /usr/share/apps/switchdesk/Xclients.$1 ]; then
exec -l $SHELL -c "/usr/share/apps/switchdesk/Xclients.$1";
case $1 in
exec -l $SHELL -c "xterm -geometry 80x24-0-0"
exec -l $SHELL -c "gnome-session"
exec -l $SHELL -c "/usr/share/apps/switchdesk/Xclients.kde"
# fall back to twm
exec -l $SHELL -c "/usr/share/apps/switchdesk/Xclients.twm"
# otherwise, take default action
if [ -x "$HOME/.xsession" ]; then
exec -l $SHELL -c "$HOME/.xsession"
elif [ -x "$HOME/.Xclients" ]; then
exec -l $SHELL -c "$HOME/.Xclients"
elif [ -x /etc/X11/xinit/Xclients ]; then
exec -l $SHELL -c "/etc/X11/xinit/Xclients"
# should never get here; failsafe fallback
exec -l $SHELL -c "xsm"
> I'm surprised it took 11 months to come up with this answer.
It didn't take 11 months. It took 5 minutes. The bug report was considered
to be extremely low priority since you're using tcsh. Every single tcsh
related bug report that has ever been filed in bugzilla, has caused us
numerous headaches attempting to "fix" the problem for the tcsh or zsh or
whatever $SHELL user, because that user looks at the problem entirely from
the point of view of their own shell. Users are not aware or concerned
with bash working, i18n if it doesn't affect them. As long as what _they_
want works, then fantastic.
Yes, this bug sat here for a long time, as a low priority, and I've decided
that making any changes for things like this is not worth the risks involved.
Nothing you've said above changes any of that. What you're asking me
to do, may solve your problem, but it in no way demonstrates that it does
not break *anything* else in the entire distribution for *anyone*.
As stated above, I am not willing to take such a risk.
Closing WONTFIX again.
I'll also note that for something that is as big a problem as you make it
out to be, I've received one bug report in 2 years...
For your part, you have not addressed any of the technical points I've raised,
though you have raised irrelevant points about people who like tcsh, the
headaches of supporting more than one program, and the smallness (you claim) of
the tcsh user community.
This is not a tcsh issue, it is a general issue affecting all logins under X.
If you take my report, eliminate the last paragraph and case #1, and change the
word ".login" to ".bash_profile", you have an equally-valid report for bash.
I've given you the solution; it's pretty trivial. Unless you have ever
documented that users should use their shell's startup files to alter the
behavior of X startup (and it's a serious design flaw if you did), it should be
safe to implement.
I worked in the group that wrote X, in versions 9 and 10. If someone had
suggested using a shell startup file to alter the behavior of the window system
login at one of our design meetings, it would have sent people screaming from
the room. We were very careful to separate window system from window manager
from user shell. Someone, perhaps inadvertently, has broken that separation.
Perhaps it does not affect many people, but perhaps it does. As I said, it took
me many hours to find out what was going on. I am not surprised that you
haven't received many bug reports.