How to capture all the environment variables from shell?

[Nobody]

On Wed, 11 Aug 2010 13:08:59 +1000, Cameron Simpson wrote:

> The reason .bashrc gets overused for envars, aside from ignorance and
> propagated bad habits, is that in a GUI desktop the setup sequence is
> often a bit backwards. A conventional terminal/console login means you
> get a login shell that sources your .{bash_}profile. And from there one
> would start a GUI and all the .profile stuff has been run Once, as it
> should be. But when the login itself is a GUI the various terminals get
> started _before_ the .profile stuff gets sourced, because the terminal
> is started by the desktop manager. Once common "fix" for this is to
> make all new terminals run login shells. Ugh, but it does work.

Er, not really. If you don't source your ~/.profile (etc) from e.g.
~/.xsession, GUI applications don't get to see the environment settings
therein. The environment isn't just for shells.

The reason why ~/.profile is only sourced by login shells is that it's
supposed to be sourced exactly once, by the initial process of a session,
i.e. the one from which all other programs descend. For a terminal-based
login, "login" (or sshd or whatever) starts the shell as a login shell
(with argv[0][0] == '-'), and the shell sets up the environment.

For a desktop login, there is no login shell, so something else has to set
up the environment. Simple enough; well, simple enough for anyone who
understands Unix, processes, sessions, etc. But apparently too complex for
the people who create desktop environments, who seem to think that the
environment is somehow specific to shells.

So you usually need to manually configure your session script (e.g.
~/.xsession for xdm) to set up the environment before the desktop
environment gets a look-in.

One caveat: if you set LD_LIBRARY_PATH, it will be unset when running a
setuid or setgid program. This is sometimes the case for terminal
emulators[1], in which case you need to have ~/.bashrc reinstate the
setting.

[1] Allocating a BSD-style pty requires root privilege, and writing
utmp/wtmp entries requires write permission on the file. Modern systems
have Unix98 ptys and a setgid helper program to manage the utmp/wtmp
entries, so there shouldn't be any need for xterm etc to be setuid or
setgid nowadays.