<waves hand> There is no problem with editing environment variables in Linux.

<waves hand> You're going to go back to your terminal and re-think how you use environment variables.

Seriously, nobody has this problem on Linux desktops because folks usually--if they're going to mess with environment variables at all--they're going to do it right after getting a new home directory (i.e. a new desktop where logging out and back in one time isn't a concern) or they're going to set them in a script of some sort. As in, start_server.sh or, "oh fuck this I'll just write a small shell script that sets PATH and launches what I want" which is perfectly normal and reasonable; if your application needs certain environment variables set to function properly why would you want to leave such things to chance? Just set it in the script that launches your app.

Unlike Windows, a Linux desktop has no mandatory distinction between a shell script and a binary in order for it to be executed. If it's set as executable it's executable; simple as that. The user probably won't know or care that /usr/bin/yourapp is really a shell script that sets up some environment variables before launching /opt/you/bin/youractualapp

Not only that but you don't have to log out and log back in--that's just the cop-out, "I'm lazy" way of applying such changes to your desktop. You could just restart your launcher. I use KDE's Plasma desktop so that would be:

killall plasmashell kstart plasmashell

If you're SSH'd into your Linux box it's even easier: . ~/.bashrc

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.

    . ~/.profile

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

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

    killall plasmashell
    kstart plasmashell

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.

    $ /bin/bash -l

Fix that by running:

    $ exec /bin/bash -l

  1) Click desktop icon to launch shell  
  2) /opt/myfirstgui/run.sh & disown
  3) Close shell

This drives me nuts on Linux: env. vars aren't systemically available as on Windows where you even have an option to broadcast change so that even running applications can update. I wonder why there isn't POSIX standard for this, perhaps /etc/environment would be good choice if standardized.

On Windows, you don't really need any than that. To get PATH env var the way it is now in Win 10 just do in any windows

  PS>  $Env:Path -split ';' 

So please Windows admins, stop being fucking clickzor n00bs and start using Powershell. Its embarrassing.

As a related note, the most awesome of all editors on Windows is Total Commander "Environment Variables" plugin - you can do all kinds of stuff there (regex search/replace, backup/restore as simple file copy, fuzzy search, bookmarks ..)

    PS>  $Env:Path - split ';' 

I mean, yeah, sure, it can happen once in a lifetime... Even so, its easy to fix.

If you want a new environment variable added, or one altered, it needs to be sent out to the UI process that starts new tasks (like shells, applications and so on). To be extra clever, this new environment message could also be passed to running terminal emulators as well (so that if you open a new tab in a running app, the shell started in there will also obtain the new variables)

Environment change to send (something) to UI process(es). Plural here -- these could be window manager, shell, or applications. Since application subsumes window manager and shell, we will ignore that. Unless the application is forced to say "I am interested" to (say) systemd. Or dbus.

Then, accept the environment changes. But, those will have to be filtered -- this could be user input. Indeed, the application may have an application starter, and one the jobs of the application starter may be to filter the environment. The application starter may never expect an environment change, but the application started may (in our "new world" API). This could result in security holes (especially for large daemon processes). Interestingly, the main purpose of this change would be to allow the environment to change dynamically for those daemons.

The "extra clever" is the easy case -- make changes in .bashrc This will get read by new tabs in your terminal emulator.

Having an application starter that is responsible for the environment is the (current) solution. Of course, this does not permit environment changes. But these are impossible anyway -- int main(int ac, char av, char envp) implies that the environment passed to main must not be altered. Of course SUSv3 doesn't specify it, and getenv() putenv() should be used. Hoever, extern char environ; is allowed, which is the same as char envp.

http://pubs.opengroup.org/onlinepubs/9699919799/functions/en...

http://pubs.opengroup.org/onlinepubs/9699919799/functions/ge...

So, an application can do char path = getenv("PATH"); to obtain the PATH. After which, char path will not change (as long as getenv(), setenv, unsetenv() or putenv() is not called, and environ is not written).

Which means that it is very difficult to "inject" a PATH change -- it should be impossible. Another mechanism must be put into place for this, but POSIX semantics should be maintained.

In my code, I tend to do strdup(getenv("PATH")) or something along those lines (note that getenv() may invalidate a previous getenv() so it is not safe to store the result char* of getenv()).

Ratboy

To restart popular desktops/launchers without logging out:

KDE

    killall plasmashell
    kstart plasmashell

    killall -3 gnome-shell

    unity --replace &> /dev/null & disown

    killall -HUP xfdesktop