Hacker News Reader

Comment by shiro | Hacker News Reader

Isn't just starting a new shell suffice? (Usually I'm lazier and just say ". ~/.bashrc", knowing that it might not be idempotent but I don't care.)

View on HN

If you place environment variables in ~/.bashrc, it would work. However, generally they are placed in ~/.profile which is read only when a login shell is launched. (And ~/.bashrc is not even read when you start a GUI session, anyways.) This is especially problematic in the GUI environment because in that case the login shell is the desktop environment itself. So you need to restart the whole environment (close all the windows, logout, and login) to load the new environment variables.

Windows gets over this problem by letting the login shell (explorer.exe) reload the environment variables in place. So, if we are to do the same thing in Linux, we might have to patch bash, zsh, and GNOME etc. to understand the environment variable change events and reload itself appropriately. I'm not sure where to start, but I believe this is the one thing that Windows did right, so I want to see it happen.

Changing how the environment works isn't a trivial change, it would have far-reaching consequences, and every program that reads the environment would need to be patched, not only the shells and display managers.

If the aim is to replicate how Windows works, only the GUI shell would need to reload environment variables (i.e. the process that forks when you start programs using whatever the desktop's idiom is).

This seems inconsistent behaviour to me. Some running processes reload the environment and others don't. Maybe in Windows they can get away with it, but that doesn't mean it's a good idea.

To be fair: The Windows way is kinda consistent: If the environment definition was changed, everyone gets a window message. It's just that no one but explorer.exe cares about that and reacts, as far as I'm aware (Raymond Chen had a recent article mentioning exactly this).

So, the OS tells everyone 'Hey, you totally could update your environment'. But your running instance of Skype or whatever just doesn't need to care.

Raymond Chen article for anyone that is interested: http://blogs.msdn.com/b/oldnewthing/archive/2015/09/15/10641...

I think that reacting to system change is opt-in.

If I change the login setting, this usually works (yeah, I have extra layer of shell but I don't care):

    $ /bin/bash -l

Environment variables in Unix isn't for changing global settings. Their effects are localized by design.

> ... I have extra layer of shell ...

Fix that by running:

    $ exec /bin/bash -l

instead.

Right!

If you made a change to your .profile why wouldn't you just apply it?

    . ~/.profile

Why logout and back in? You know which file was changed because you made the change.

As someone else mentioned down below, if you just need a new login shell with your variable changes just do this:

    exec /bin/bash -l

(the -l meaning, "act as if... invoked as a login shell")

Also a tip if you're using KDE: You don't need to logout and back in. Just do this:

    killall plasmashell
    kstart plasmashell

That should apply any changes you've made to environment variables to any applications that get launched (subsequently) via KDE's usual methods (e.g. K menu or krunnner aka Alt-F2). Your running applications will remain open!

But it doesn't take effect globally. The entire env-var system is stuck in the 60s when people would just re-launch their shell after making changes.

It never changes globally. Your shell process sets the variables for itself, and all subprocesses started afterwards inherit them.

Reply on news.ycombinator.com