Lines 1 and 21-24 of /etc/X11/xdm/Xsession are as follows: 1: #!/bin/bash --login [...] 21: # handle KDM 22: if [ -n "$1" ]; then 23: export XSESSION="$1" 24: fi I'm not really sure how KDM works and uses /etc/X11/xdm/Xsession (if it uses it at all), but this creates a real problem when *not* using XDM and certain inputrc settings with bash. If "bell-style none" is set, then $1 and $2 of a bash login shell are set to "bell-style" and "none" respectively; try starting a new shell and doing "echo $1 $2" right off the bat to see this. So when /etc/X11/xdm/Xsession runs, it sets the XSESSION environment variable to "bell-style", which of course makes no sense as an X session type. This variable propagates through the rest of the XDM startup scripts, overriding anything else the user or administrator has set. When /etc/X11/chooser.sh tries to find the "bell-style" session, it of course doesn't find anything, and returns the default "/usr/X11R6/bin/twm". As a result, the user finds that not only his ~/.xsession ignored, but the XSESSION variable he set in /etc/rc.conf is ignored as well. Commenting out lines 22-24 of /etc/X11/xdm/Xsession fixes this problem. If it exists, the user's ~/.xsession is run, and if it doesn't exist, the system-wide Xsession runs properly. Again, I don't run KDM, so I don't know exactly what /etc/X11/xdm/Xsession is expecting to receive from it on $1. It sure isn't expecting "bell-style".
I can't confirm this behaivour. I have set bell-style none in my /etc/inputrc and I certainly don't get that echoed when I do echo $1 $2 whether login shell or no.
A quote from the bash manpage (first paragraph of the 'set' builtin command): "Any arguments remaining after the options are processed are treated as values for the positional parameters and are assigned, in order, to $1, $2, ... $n." While testing with a small shellscript I noticed that if any parameters are passed via the commandline, the parameters created by 'set' are discarded. Unfortunately I didn't see this behaviour mentioned in the documentation. So this error only happens if the user has additional arguments to 'set' in his ~/.bashrc _and_ if there are no parameters passed to the Xsession script (which is the case if using xdm as the login manager). A solution would be to check if DISPLAYMANAGER is set to "kdm" (or any other displaymanager that expects parameters) in /etc/rc.conf and to only execute lines 22-24 if this test is true.
please see http://bugs.gentoo.org/77447 it may be related to this ( and now resolved ).
If this remains a problem with modular X, please reopen.