Re: Login Shell/Profile: Stop the Madness

From: Daniel B. (dsb_at_smart.net)
Date: 07/17/04

  • Next message: Micha Feigin: "jre segfaults"
    Date: Sat, 17 Jul 2004 13:20:13 -0400
    To: debian-user@lists.debian.org
    
    

    [Note implementation question near end.]

    Michael Graham wrote:
    >
    > Michael wrote:
    > > ...about shell environment initialization. ...
    > > ... at no time is a login shell
    > > created which is necessary to trigger profile initialization.
    >
    > Although it's annoying that this is the way *dm work it is the only
    > sensible way to do it (at least that I've heard!)...

    Let's start with sensible behavior to the user (before considering
    implementation):

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

    > Think of this: The display manager is in essence a series of shell
    > scripts with a fancy front-end. Now each of these shell scripts must use
    > a certain shell (bash, sh, csh, tcsh, ksh, zsh, the list goes on) and
    > each user on the system could potentially be using a different shell.
    >
    > Now do you have the display manager source every possible file that
    > should be sourced for each possible shell?

    No.

    But what the display manager should do at some point is start a
    login shell (that is, start the user's selected shell, with the
    standard login flag for shell programs so that shell reads the
    user's login-time files).

    That's what logging in to a virtual console does.

    That's part of the standard Unix login mechanism.

    That's what any method of logging in should do.

    Therefore, that's what display managers (or some script in the
    chain) should do.

    > Now do you have the display manager source every possible file that
    > should be sourced for the shell that the login manager uses?

    No. It invokes the selected shell and that shell sources its own
    files.

    The display manager doesn't have to know anything about which
    files a specific shell will read. It only has to know about
    the standard login-shell flag for shells.

    > Or do you
    > setup a system where by the users shell is determined and the
    > appropriate files sourced?

    YES! EXACTLY! Just like /bin/login does. And just like
    /bin/login has been doing for years (decades?)!

    > I hope if you think about it you'll realise that it is highly
    > non-trivial to implement a system where no matter which shell the user
    > uses the dm will act in the same way.

    If you use the appropriate mechanism (the standard login flag
    for shells), what's hard about it? (Also see question at end.)

    > For instance if the dm uses a bash login shell and I have two users on

    But the display manager wouldn't use a specific login shell.
    It would use the user's selected login shell. (Note that
    display manager scripts can use whatever shell the implementer
    wants.)

    > the system one using tcsh and one using bash. Then the bash user would
    > have his login files sourced and the tcsh user would not

    When the bash user logs in to a console, his or her base login
    files are sourced. What the tsch user logs in to a console,
    his or her tcsh login files are sourced.

    Logging in other than loggin in on a virtual console should still
    do the same thing.

    IMPLEMENTATION QUESTION:

    Why can't it work like this:
    - The display/login manager looks up the user's selected login
      shell (as /bin/login does).
    - At some point in the chain of startup programs and scripts,
      the manager invokes the user's selected shell as a login shell,
      by passing the standard login-shell flag (partly as /bin/login
      does (but /bin/login starts an interactive shell)).
    - The invoked shell, being invoked as a login shell, performs
      login-shell initialization, including reading the shell-
      specific login-initialization files (e.g., .bash_login if bash).
    - When the manager invokes the shell, it has the shell run a
      simple command to pass control back to the remainder of the
      manager's chain of scripts and/or programs. Here "simple"
      means simple enough to work in all reasonable or typical shells
      (e.g., no fancy redirection, etc.).

    CORE QUESTION: Can shells be invoked as login shells _and_
    be given a command or script to run?

    For example, "bash --login -c some_command" seems to be one
    way of doing that in bash. The question is whether there is
    any standard (cross-shell) way to do that.

    If some shell programs assume that a login shell is interactive,
    could a command be piped in on the standard input? (Would
    that work, and would that work across most shells?)

    Actually, even if there is no standard way to do that across
    all shells, the display manager should have a hook for doing
    that, and should come with adapters for common shells. If
    the user wants to use an unsupported shell, the user just has
    to make an adapter to hook into the hook.

    For example:
    - Have files invoke_bash.sh, invoke_tcsh.sh, etc.
    - The manager gets the user's selected shell name (e.g., "bash").
    - The manager runs invoke_<selected shell>.sh.
    - invoke_bash.sh runs "bash --login -c some_command"
    - invoke_tcsh.sh does whatever is needed for tcsh (possibly
      something like "echo 'some_command' > tcsh -l" if that works).
    - A user using a shell that the display manager doesn't already
      support but which can be invoked somehow writes
      invoke_<user's_shell>.sh appropriately.

    Why wouldn't that work?

    Daniel

    -- 
    To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org 
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
    

  • Next message: Micha Feigin: "jre segfaults"