For some years I've had a seemingly odd problem where logging in via xenodm did not respect my login class. I've tried repeatedly to work out why, and until now always failed -- it turns out that my ~/.xsession file was not marked as executable and this caused our Xsession to run it via /bin/sh. This is ultimately an act of gross stupidity on my part, but I thought it might be worth documenting how I'd managed not to fix this for so long.
Here's the relevant chunk of xenodm's default Xsession: # The startup script is not intended to have arguments. startup=$HOME/.xsession resources=$HOME/.Xresources if [ -s "$startup" ]; then if [ -x "$startup" ]; then "$startup" else /bin/sh "$startup" fi else ... fi Notice that it runs ~/.xsession differently based on its executable permission bits. This isn't documented anywhere and xenodm's man page unintentionally threw me off the scent, partly because it's not very OpenBSD-like. The first mention of Xsession in xenodm's man page is vague (this should have been a clue to me to read Xsession more carefully I now realise!): Then xenodm runs the Xsession script as the user. This system session file may do some additional startup and typically runs the .xsession script in the user's home directory. When the Xsession script exits, the session is over. It's quite easy at that point not to realise that there is a section of the man page later called "SESSION PROGRAM" which clears up some of that vagueness. A forward link might be a good idea? The "SESSION PROGRAM" section itself implicitly describes all possible Xsession scripts rather than the one xenodm actually ships with. For example: At most installations, Xsession should look in $HOME for a file .xsession, which contains commands that each user would like to use as a session. An example Xsession script is then described: This example recognizes the special failsafe mode, specified in the translations in the Xresources file, to provide an escape from the ordinary session. It also requires that the .xsession file be executable so we don't have to guess what shell it wants to use. Of course, if I'd read that carefully I should have checked that my ~/.xsession file is executable. However, the example Xsession script in the man page then contains this code: if [ -f "$startup" ]; then exec "$startup" else ... fi i.e. it doesn't contain the "if ~/.xsession isn't executable, run it via /bin/sh" part that xenodm's default Xsession does. It thus never occurred to me to check whether my ~/.xsession is executable, because under the example Xsession, it couldn't possibly run if it wasn't executable. The reason I'm filing a bug report and not a patch is that I'm not really sure if/what a fix for this might be. I am not sure if xenodm's man page is structured as it is to keep it in sync with upstream, and I'm also not sure if it's expected that people will actually change Xsession or not. Some possible ideas are: tell people to read the source of /etc/X11/xenodm/Xsession to; change the example Xsession to reflect what xenodm's default Xsession does. Laurie