[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: [Fwd: [Bug 53345] .bash_profile  script is not sourced]
From:       Oswald Buddenhagen <ossi () kde ! org>
Date:       2004-02-26 18:38:16
Message-ID: 20040226183816.GA10168 () ugly ! local
[Download RAW message or body]

[cc-ing the gdm maintainer for obvious reasons]

On Thu, Feb 26, 2004 at 05:10:11PM +0100, Adriaan de Groot wrote:
> > OTOH, the current script already appears to contain some sort of work
> > around:
> 
> Ick. But what does it _do_? Heck, I'd file a wishlist item for more code 
> documentation here. In some cases it will at least stick the $PATH set in the 
> profiles after the PATH set before sourcing them (DM_PATH). 
> 
yeah, i'm wondering myself at times. *g*
this is an Utterly Ugly Hack (TM), and i should really remove it when i'm
consequential with my purity attitude. anyway, the problem:
in a typical setup, we have three(!) sources for PATH: what is
configured in kdmrc, what is configured by PAM (through pam_env), and
what is configured in the sh profiles. the mentioned hack merges the
PATH received from kdm (see below) with the PATH set by the sh profiles.
here it becomes obvious, why sourcing even those foreign startup scripts
is plainly sinister. i really should remove it and educate the people to
use Xsession's xprofiles - 100% consistent, 100% defined behaviour. the
other problem is PAM vs. kdmrc: currently, the PAM setting simply
overrides the kdmrc setting - this sucks, as the kde path is added to
kdmrc by the installation process (to make kde start at all without the
user fiddling with it first). the proper solution would be patching the
PAM setup at install time, but it's impossible to cover all possible PAM
setups, so i think i'll have to put a similar hack like above into kdm
to handle the situation halfways. alternatively, the kde session type
definition (kde.desktop) could specifiy a full path ... hmm ...

so now the proper solution(s) ...

in a Perfect World (TM), all generic environment setup would be done by
the login tool (*dm, login, su, rshd, etc.) in a shell-/session-
agnostic way before those get control at all. a good start is pam_env,
even though it needs to be extended (syntactically, and to read
~/.environment, not only /etc/environment). a shell's startup files
would do only setup specific to that particular shell.

but as we do not live in a perfect world, no generic environment setup
exists - too bad. in particular, the PATH situation is not really clear
for shells, as the various login tools provide no consistent setting -
that's why it is good practice to clear the PATH in /etc/profile first -
and also the reason, why Xsession should not source it. so here is my
proposal. it is similarily idealistic as the Perfect solution, but at
least it does not involve modifying doozens of programs, only following
a strict policy regarding the already sourced startup scripts:
- we introduce environment setup scripts. those scripts do all the same,
  only with different languages - every one of them using the lowest
  common denominator of a shell family (bourne/posix shells, c shells).
  those scripts do _not_ do anything specific to a particular shell.
  those setup scripts are strictly non-interactive.
- every shell (and Xsession) has its startup scripts. those do some
  shell-specific setup to reach a uniform environment first, then they
  source the environment setup script for their shell family, and
  finally do shell-specific setup to fully utilize the particular shell.
  these scripts _can_ be interactive, depending on the shell's
  specification, even though it would be certainly a bad idea to make a
  system-wide setup script interactive - but in user-specific scripts it
  is feasible for special tasks.
- finally, the posix shell family as an example:
  /etc/profile:
    # if we don't _know_ that PATH is something useful on this system:
    PATH=<defaultpath>
    . /etc/shenv
  /etc/shenv:
    PATH=$PATH:<application-specific paths>
    LD_LIBRARY_PATH=...
    LC_ALL=...
  ~/.bash_profile:
    . ~/.shenv
    # bash is silly. pretend that we're an interactive non-login shell:
    . /etc/bash.bashrc
    . ~/.bashrc
  ~/.shenv:
    PATH=$PATH:$HOME/bin:<some-clever-stuff-(tm)>
  /etc/bash.bashrc:
    # system-wide aliases & functions, default prompt, etc.
    # don't export anything here; it is specific to the interactive shell
    # and the next one will source the *bashrcs itself.
  ~/.bashrc:
    # my aliases, functions, etc.
    PS1='\[\033[1m\]\u@\h:\w >\[\033[0m\]'
  ~/.profile:  # yes, this is for the plain bourne/posix shell only
    . $HOME/.shenv
    PS1='\u@\h:\w >'
    export PS1  # non-login shells won't source profile, so export now
  /etc/xprofile:
    # we got a sensible default PATH from *dm already. and it may
    # contain the path to our favorite environment, so do our best to
    # preserve it. actually this is an Ugly Hack and we should ensure
    # that kde can start without it, so the complete PATH setup can be
    # done in shenv.
    . /etc/shenv
  ~/.xprofile
    . $HOME/.shenv

note that the *bashrc stuff is not really relevant to the current
discusison, but i've seen so many insanely configured systems, that i
want to point out the Right Way Of Doing It (TM) here. however, consider
the effects of BASH_ENV/ENV and that the two can be even hard-coded into
your bash installation (like suse does for some time now). important is
only, that the setup for the interaction is separated from the
non-interactive stuff, so non-login shells don't execute it the
login-only stuff over and over (thus possibly creating super-long PATHs,
apart from being slow).

for csh clones the system is generally quite similar to using bourne
shells with ENV preset, but i'm not that much into it.


oh, btw ... i once discussed this with the relevant person at suse ...
even though he didn't claim that it is The Absolute Truth (TM), he
tended to james' "solution" - because the system was b0rked forever, and
changing it to something sane now would make the hotlines glow.

greetings

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]