Re: Login Shell/Profile: Stop the Madness

From: Daniel B. (REMOVEdanielTHIS_at_fgm.com)
Date: 08/23/04

  • Next message: John Fleming: "Software RAID using Sarge Installer" 
    Date: Mon, 23 Aug 2004 16:35:21 -0400
To: Michael Graham <oobermick@yahoo.co.uk>

    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 

    -- 
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
  • Next message: John Fleming: "Software RAID using Sarge Installer"

    Relevant Pages

    • Re: [opensuse] mp3info help
      ... Yes, Linux access controls are up to this, probably without even using ... The first amounts to logging. ... If this is being done with a shell, then there will be a shell history. ... If you re-implemented it s a database then the set of commands, ...
      (SuSE)
    • Re: changing the shell and editor
      ... An alternative to logging out and back in is having root run the ... >>now i use the bash shell. ... i am not able to change my enviroment ...
      (freebsd-newbies)
    • Re: Re (2): ~/.profile
      ... Because .profile is the "generic" shell side of things it is better to ... than to use the more compact but newer combined form. ... that Debian's default file uses bash syntax ... It is a long story but normally when logging in through a graphical ...
      (Debian-User)
    • Delay in logging in
      ... Logging in is very slow. ... Running 'su' from a shell gives the same delay as ... then about ten screens of output dumped to the screen. ...
      (alt.os.linux.suse)
    • Re: Environment variable not remembered outside a script?
      ... After executing the two files (.zshrc is already executed when I opened the ... This is a difference between running a script and sourcing it. ... and any environment variables it sets are ... themselves are not a shell feature but are actually part of the UNIX ...
      (comp.unix.shell)