I am very (zsh)/somewhat (bash) familiar with the shell's initialization sequence when the user logs in through a text interface.

But what about the case of a "graphic login", IOW, when the user logs in through a graphic interface (e.g. through a so-called "display manager" on Linux, or the standard OS X login)?

I am particularly interested in those files (.zprofile, .zlogin, .profile) that are supposed to be sourced only for "login shells". When the login is via a text interface, this is more or less equivalent to being sourced "exactly once per session".

When the login happens through a graphic interface, it is not clear to me that there's ever a "login shell" to begin with. And even if .zprofile et al. are somehow sourced at some point as part of the graphic login sequence, it is not clear to me how the settings (e.g. exported environment variables) resulting from the sourcing of these files affect the rest of the of the session.

For example, do these settings affect the environment seen by apps that are auto-started at the time of login? Or by apps that the user starts later by clicking on desktop icons?

For that matter, what about the settings that happen in .zshenv, or in .zshrc/.bashrc1? Do they have any impact on the environment seen by "auto-started" and/or "click-started" apps?

If the answers to either of the last two question is something like "not by default", the follow-up question would be: how can one ensure that the settings performed in (at least) .zprofile/.profile, and possibly also .zlogin, get transmitted to the environment seen by all the "auto-started" and "click-started" applications?

I'm interested in the answers to these question for two shells, zsh and bash, and two operating systems, Linux and OSX.

1 assuming that .zshrc/.bashrc are being sourced as part of the zsh/bash built-in initialization sequence for "interactive" shells, rather than being sourced explicitly by .zprofile/.profile.

  • 1
    Which shell scripts get sourced when is a surprisingly tricky business. So many factors. If you are logging in via a standard Display Manager, they should source ~/.xsession and /etc/X11/xession. Many also parse ~/.profile but nothing. Neither ~/.zprofile nor ~/.bash_profile nor any other shell-specific init file is sourced for the display and "click-started" apps. However, if an application is click started via a shell (e.g. by shebang or having an Exec line sh -c "...", they will source the ~/.zshrc/~/.bashrc. Confusing enough? :D – kba stands with Monica Feb 18 '16 at 15:34

Shell configuration files come into play only when the shell is invoked. There's nothing magical about them. Any process can change its environment. Most only read it, but any program that exec's another is apt to have cause to alter the environment first.

It all starts with init, or whatever pid 1 is on your system. It starts the X server, which starts the display manager, which provides the login prompt. The sequence that gets X11 started need not include a login shell; for example, init could call fork(2) and exec(2) on /usr/bin/startx. No login, no .profile. The X server inherits only the environment exported by init.

What does the X server's environment look like? You can extract the environment of a process with ps(1). Easier, but not definitive, is to use ssh hostname /usr/bin/env (where hostname is the name of the machine hosting the X11 server). Similar to what usually happens with the X server, sshd executes env without creating a login shell.

Then we come to whatever your display manager does when you log into it. It forks a process, changes the uid from (probably) root to yours, and starts a session manager. For details, I commend you to your friendly manual.

From that point forward, the session manager has established its environment, by whatever means. Processes that it creates -- command interpreters or other applications by "clicking" on them -- inherit its environment. The session manager may provide a way to define additional environment variable values on a per-icon basis, and the process that the clicked-on-thing starts may (as a shell does) alter its environment at startup, perhaps by a configuration file.

It's all there. To understand how the environment comes to be what it is, you "just" have to follow the chain of processes that created it, and understand what each one did to the environment. Unfortunately, not only does that chain vary by OS, distribution, and machine & user configuration, it's also not particularly well documented or tooled. Good luck, for example, finding documentation that states what environment variables will be set before, say, sshd starts, or finding an X11 client that displays the session manager's environment.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.