Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

X sessions and shell startup files

5 views
Skip to first unread message

Ivan Shmakov

unread,
Aug 18, 2018, 11:07:36 AM8/18/18
to
>>>>> Helmut Waitzmann <nn.th...@xoxy.net> writes:

[Cross-posting to news:comp.windows.x, for reasons.]

[...]

> One example I know of is a graphical login session: the display
> manager, having received the username from the user and verified the
> password, finally starts a non-interactive login shell with the
> userid of the user, which invokes the session manager as selected
> by the user, like the C language code snippet

> execl( "/bin/bash", "-bash", "-c", "--", "... # start the session
> manager here", "-bash" );

> In this case one doesn't want the user's shell aliases

A technicality: Bash doesn't expand aliases in non-interactive
shells by default; cf. bash(1):

Aliases are not expanded when the shell is not interactive,
unless the expand_aliases shell option is set using shopt (see
the description of shopt under SHELL BUILTIN COMMANDS below).

> and functions intended for the user's interactive shells to be defined,
> because they might change the semantics of the shell command line

> "... # start the session manager here",

> making it fail.

As to the functions, I suppose that preventing user from doing
stupid things with them will have a side effect of preventing
doing clever things with the same.

Note, for example, that .bash_profile in this case can just as
well modify PATH in such a way as to make the "... # start the
session manager here" command line fail.

$ grep -F -- PATH < .bash_profile
export PATH=${HOME}/bin:${HOME}/hacks:${PATH}
$ readlink -- ~/hacks/session_manager_i_do_not_like
/bin/false
$

> So I guess, that nearly all users use to invoke non-interactive main
> login shells, they even don't know of.

Actually, I'm curious as to which display managers actually behave
in the way described? IME, it was a kind of a minor problem to
get consistent environment between X and non-X sessions.

For instance, with Linux-PAM, it's possible to use pam_env.so
(non-default) user_readenv=1 setting. Perhaps a better
alternative, at least on Debian, is to rely on a feature of the
40x11-common_xsessionrc (/etc/X11/Xsession.d) file, which reads:

#Source user defined xsessionrc (locales and other environment variables)
if [ -r "$USERXSESSIONRC" ]; then
. "$USERXSESSIONRC"
fi

Personally, I use a dedicated ~/.session_common file

...
## Environment
case "$PATH" in ("$HOME"/bin:*) ;; (*) PATH=${HOME}/bin:${PATH} ;; esac

unset CVS_RSH
unset LC_ALL
...

sourced from both .bash_profile (alongside .bashrc):

## Source .bashrc and .session_common
[ -e "$HOME"/.bashrc ] && . "$HOME"/.bashrc
[ -e "$HOME"/.session_common ] && . "$HOME"/.session_common

and ~/.xsession:

## Source .session_common (unless done from ~/.xsessionrc)
test "$SOURCE_SESSION_COMMON" != no \
-a -e "$HOME"/.session_common \
&& . "$HOME"/.session_common

... And, now that I've checked it, ~/.xsessionrc:

## Source .session_common
test -e "$HOME"/.session_common && . "$HOME"/.session_common
SOURCE_SESSION_COMMON=no

[...]

--
FSF associate member #7257 np. Kosci Zostaly Rzucone (...) -- Chris Prattini
0 new messages