6 ms·

What's even more inexplicable is that you can't do the same on Linux. For all the developer-friendliness of the platform, nothing infuriates me more than having

by anon4 11y ago

What's even more inexplicable is that you can't do the same on Linux. For all the developer-friendliness of the platform, nothing infuriates me more than having to edit my PATH/LD_LIBRARY_PATH/etc. by editing my .bashrc and then having to log out and back in again. Not to mention that programs you start from the GUI launcher don't source that file so if you need a program to start with one of them set, you actually need to edit .profile... wait no that doesn't work, I mean /etc/profile.d/99-my-path.conf... no actually it's /etc/environment... or is it /etc/profile... oh fuck this I'll just write a small shell script that sets PATH and launches what I want. Like... in Windows motherfucking NINETY-FIVE you could edit your PATH variable without having to restart, why do I have to log out and back in in 2015 for Linux to accept those changes. Why do I have to mess around with random scripts that may or may not be executed by one of the many steps launching my session. What is this madness.

shiro 11y ago
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.)
- anon4 11y ago
  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.
  - andor 11y ago
    It never changes globally. Your shell process sets the variables for itself, and all subprocesses started afterwards inherit them.
- yokohummer7 11y ago
  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.
  - lottin 11y ago
    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.
    - barrkel 11y ago
      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).
      - lottin 11y ago
        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.
        darklajid 11y ago
        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.
        zastrowm 11y ago
        Raymond Chen article for anyone that is interested: http://blogs.msdn.com/b/oldnewthing/archive/2015/09/15/10641604.aspx http://blogs.msdn.com/b/oldnewthing/archive/2015/09/15/10641...
        majkinetor 11y ago
        I think that reacting to system change is opt-in.
Majestic121 11y ago
You don't have to log out and back in to update your bashrc, you can type "source .bashrc" to reload it.
- anon4 11y ago
  And then when I click on my IDE icon on my desktop it will launch with the new PATH? It won't. That was a rhetorical question. You can tell by the way it stipulates a modicum of usability out of desktrap loonix.
  - mikegioia 11y ago
    I mean, what is your workflow that you're updating your PATH this often? I've managed "loonix" for 10 years and I must edit the PATH like once a year.
switch007 11y ago
1) Click desktop icon to launch shell 2) /opt/myfirstgui/run.sh & disown 3) Close shell
- cosarara97 11y ago
  I didn't know disown existed, thank you!
lottin 11y ago
It can be confusing but it isn't that complicated. Basically you have to options, either let pam set the environment or use your shell of choice (in which case the shell start-up file should be sourced from the X session script as well). Having to log out and back in may be inconvenient but it's unavoidable and a small price to pay in my opinion.
- joosters 11y ago
  It's not unavoidable / impossible. We (can) have the technology! 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)
  - riskable 11y ago
    To add specificity to this tip... To restart popular desktops/launchers without logging out: KDE killall plasmashell kstart plasmashell Gnome killall -3 gnome-shell Unity unity --replace &> /dev/null & disown XFCE killall -HUP xfdesktop
  - ratboy666 11y ago
    So... 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/environ.html http://pubs.opengroup.org/onlinepubs/9699919799/functions/en... http://pubs.opengroup.org/onlinepubs/9699919799/functions/getenv.html 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
riskable 11y ago
I'm going to pull a Jedi mind trick here... <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
majkinetor 11y ago
Meh... GUI sux for this anyway, Windows is ahead of this generally then other Linux like OSes. 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 ';' Setting the var in the system is equally fast and you can make stuff even better - for instance my POSH function keeps backup of old env var value, i.e. if i change the PATH today I would also have PATH_2015_10_26 with old value. 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 ..)
- ygra 11y ago
  PS> $Env:Path - split ';' The operator is -split, without the space. In any case, it won't work, because the path can contain quoted items that contain a semicolon.
  - majkinetor 11y ago
    Wow, in what universe that happens ? :) I mean, yeah, sure, it can happen once in a lifetime... Even so, its easy to fix.

by anon4 11y ago

shiro 11y ago

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.)

anon4 11y ago
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.
- andor 11y ago
  It never changes globally. Your shell process sets the variables for itself, and all subprocesses started afterwards inherit them.
yokohummer7 11y ago
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.
- lottin 11y ago
  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.
  - barrkel 11y ago
    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).
    - lottin 11y ago
      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.
      - darklajid 11y ago
        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.
        zastrowm 11y ago
        Raymond Chen article for anyone that is interested: http://blogs.msdn.com/b/oldnewthing/archive/2015/09/15/10641604.aspx http://blogs.msdn.com/b/oldnewthing/archive/2015/09/15/10641...
      - majkinetor 11y ago
        I think that reacting to system change is opt-in.

Majestic121 11y ago

You don't have to log out and back in to update your bashrc, you can type "source .bashrc" to reload it.

anon4 11y ago
And then when I click on my IDE icon on my desktop it will launch with the new PATH? It won't. That was a rhetorical question. You can tell by the way it stipulates a modicum of usability out of desktrap loonix.
- mikegioia 11y ago
  I mean, what is your workflow that you're updating your PATH this often? I've managed "loonix" for 10 years and I must edit the PATH like once a year.

switch007 11y ago

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

cosarara97 11y ago
I didn't know disown existed, thank you!

lottin 11y ago

It can be confusing but it isn't that complicated. Basically you have to options, either let pam set the environment or use your shell of choice (in which case the shell start-up file should be sourced from the X session script as well). Having to log out and back in may be inconvenient but it's unavoidable and a small price to pay in my opinion.

joosters 11y ago
It's not unavoidable / impossible. We (can) have the technology! 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)
- riskable 11y ago
  To add specificity to this tip... To restart popular desktops/launchers without logging out: KDE killall plasmashell kstart plasmashell Gnome killall -3 gnome-shell Unity unity --replace &> /dev/null & disown XFCE killall -HUP xfdesktop
- ratboy666 11y ago
  So... 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/environ.html http://pubs.opengroup.org/onlinepubs/9699919799/functions/en... http://pubs.opengroup.org/onlinepubs/9699919799/functions/getenv.html 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

riskable 11y ago

I'm going to pull a Jedi mind trick here... <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

majkinetor 11y ago

Meh... GUI sux for this anyway, Windows is ahead of this generally then other Linux like OSes. 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 ';' Setting the var in the system is equally fast and you can make stuff even better - for instance my POSH function keeps backup of old env var value, i.e. if i change the PATH today I would also have PATH_2015_10_26 with old value. 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 ..)

ygra 11y ago
PS> $Env:Path - split ';' The operator is -split, without the space. In any case, it won't work, because the path can contain quoted items that contain a semicolon.
- majkinetor 11y ago
  Wow, in what universe that happens ? :) I mean, yeah, sure, it can happen once in a lifetime... Even so, its easy to fix.