>>>>> 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