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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
