Re: Login Shell/Profile: Stop the Madness

["Daniel B." <REMOVEdanielTHIS@fgm.com>]

Michael Graham wrote:

> Daniel wrote:
>
> > It would be sensible if logging in via a display manager included
> > the same shell login initialization that logging in on a virtual
> > console performed.  (Or via telnet, rlogin, ssh, etc.)
> ...
> Why should logging into X have the same behaviour as running a bash (or
> whatever) login? 

Because both are methods of logging in.


Obviously, not all of the behavior should be the same (e.g., both GUI
or both text).

However, they are both methods of logging in.  (Look at the wording
of your question--both the X case and the bash case involve forms of
"log in.")

Since both are methods of logging in, the behavior related to logging
in should be the same.  (For example, they both accept the same sets
of pairs of usernames/passwords; you don't normally have different
user names for console login vs. display-manager login.)

Another standard Unix part of "behavior related to logging in" is
setting environment variables to login-time defaults.  NOTE:  This
doesn't only (and doesn't necessarily) involve a shell--PAM reads
/etc/environment and sets environment variables before any
(traditional) shell is started.


> When you log in to a console (Or via telnet, rlogin,
> ssh, etc.) you are just running a login shell, but X is not a shell.

Actually, it is a form of shell.  X (or, rather, the window manager
and desktop environment) is what the user interacts with to run
other programs.  That's the essence of a shell.  (MS Windows is
sometimes called a graphical shell.)

However, even ignoring that wider definition of shell with which
you might not agree, traditional shells are still involved when
you log in via a display manager.  If you open xterm windows,
they're running traditional shell subprocesses, with environment
variables inherited from somewhere.

If you log in on a console into a single, conventional shell
process, PAM applies the /etc/enviroment settings to some process
and then runs your chosen (traditional) shell, which applies its
environment settings.  You can modify the environment, and if you
spawn a subshell, the current environment is inherited by the
subshell's process.

Even in graphical mode, subshells (e.g., in xtem windows) should
work similarly:
- Any pre-shell login-time environment settings (e.g., from
  /etc/environment) should have been applied.  (I _think_ this
  part already works.)
- Any login-time shell environment settings for the user's
  selected interactive shell should have been applied (e.g.,
  .bash_profile) (implemented by running that shell, or course).
- The xterm subshells will inherit current environment variable
  settings from whatever window-manager or desktop-environment
  process spawns the xterm process.  The xterm process's
  environment should reflect the pre-shell and login-shell
  environment settings.

  (Ideally, that spawning process would let you change environment
  variables just like any traditional interactive shell lets you
  do, so that then you launch new processes (whether shells in xterms
  or any graphical program), you can control their environment
  setings.)


> Now if you where saying that there should a mechanism for setting
> environment variable at a user level that was independent of the method
> of login then I would agree but ~/.profile ~/.bash_profile or ~/.login
> is not the place for these as they are used already and have
> well-defined jobs

Yes, there are two levels here, but I think both should work the
same when logging in on a console, logging in on a console and using
startx, or logging in via a display manager.

Daniel