Re: How To Permanently Add-to a Users PATH Statement in the Bash Shell
* On 2020 08 Jul 08:38 -0500, Greg Wooledge wrote: > There are lots of choices here. And this is with only the login shell > layer involved -- no X11 or Wayland. Good points and it must be emphasized that ~/.profile or ~/.bash_profile are for *login* shells only. Ordinarily shells started from a GUI terminal emulator are not login shells though there is usually an option that can be ticked to invoke the shell as a login shell. > That's interesting, but I'm not sure I fully trust that test you > performed. I don't know whether the "Run Command dialog" is doing > something secretly. I'd prefer to check the actual starting environment > of one of the GNOME processes. I don't know what their names are, but > assuming you can find one that looks like it was started at the time > you logged in, grab its PID and then do something like this: > > tr \\0 \\n < /proc/its_pid_here/environ | grep your_variable_here > > That will show you the initial environment of that process, without > letting "Run Command" get involved to do any tricky stuff. > > If it turns out that the Wayland session really does dot in ~/.profile, > that's yet another reason why you need to ensure that it remains > shell-neutral. I would imagine that Wayland dots it in from a POSIX > shell (the same way the Debian X11 session dots in ~/.xsessionrc from > a POSIX shell). My test was not exhaustive, but I did run your command and with Gnome on Wayland and any variables I had set in ~/.profile appeared in the environment of processes running as my username such as gnome-shell. Trying the same on a Buster VM with Xfce on Xorg showed that variables set in ~/.profile did not appear in the environment of a running process such as xfce4-panel or xfdesktop. Most likely Debian uses dash to source the ~/.profile and ~/.xsessionrc files A quick test shows that Gnome on Wayland does not source ~/.xsessionrc, however Gnome on Xorg does appear to source both ~/.profile and ~/.xsessionrc (tested from a cold start). In this case it is my guess that it is Gnome that is sourcing ~/.profile independent of the GUI environment it is running on. I think this is as far down this road as I care to go! - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: How To Permanently Add-to a Users PATH Statement in the Bash Shell
On Wed, Jul 08, 2020 at 07:53:53AM -0500, Nate Bargmann wrote: > https://noah.meyerhans.us/2020/07/07/setting-environment-variables-for-gnome-session/ > As I read it, where an environment variable should be set depends on the > intended scope of the variable. One comment in response to the blog > post states that ~/.profile should be used to set such variables and > that even Gnome on Wayland will read this file (I've not tried it yet > myself). I've heard this also, but I have no evidence for or against it. If it's true, it's *unique* to the Wayland session, because that sure as hell is false for X11 sessions. > There is a caveat! Isn't there always? The comments at the top of > /etc/skel/.profile note: > > # ~/.profile: executed by the command interpreter for login shells. > # This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login > # exists. You're over-thinking this. > For whatever historical reason I do have ~/.bash_profile which does > nothing other than source ~/.bashrc when Bash is invoked as a login > shell. I think I'll move it out of the way and use ~/.profile instead. Set aside all of the X11 and Wayland and display manager and X session stuff, and look ONLY at the shell. When bash is invoked as a login shell (e.g. when you log in via ssh, or on the console), it reads one of the following files: ~/.bash_profile ~/.bash_login ~/.profile It searches for them in that order, and the first one that it finds is what it reads. Let's call this file "the profile". YOU, the end user, are expected to configure "the profile" so that it dots in (or sources, if you're sure you're in bash) the ~/.bashrc file so that you also get your aliases, functions, and so forth, in your login shell. So, in a standard console-only setup, we might have the following files: === ~/.profile === export PATH=$HOME/bin:$PATH:/sbin:/usr/sbin export EDITOR=vim export VISUAL=vim test "$BASH_VERSION" && . ~/.bashrc == === ~/.bashrc === set -o vi set +o histexpand alias ll='ls -l' == Note that the standard Debian profile (/etc/skel/.profile) uses a similar test to dot in ~/.bashrc and prepend ~/bin to PATH, so if you're using the standard profile, it's pretty similar to what I wrote here. The reason there's more than one possible filename for the profile is largely historical, but it also ties into the fact that your home directory can be *shared* across multiple systems. And you might have different login shells on different systems. (Or, you might be the kind of person who switches your login shell from time to time, and you want to make sure you can still login with a mostly-sane environment regardless of which shell is currently selected.) The ~/.profile file is the traditional profile used by the Bourne shell, the POSIX shell, and the Korn shell. Bash reads it for compatibility. However, bash has a lot of extensions that these other shells may not offer, so you aren't supposed to put bash-specific syntax into ~/.profile, because some day, it might be read by a different login shell. With that in mind, bash offers the alternatives ~/.bash_profile and ~/.bash_login (the latter with csh refugees in mind). Bash is the only shell that will read either of those files, so if you use one of those, you're safe to put bash syntax in it. In a multi-shell environment (NFS shared home, or frequent use of chsh), you might choose to put most of your environment variable in ~/.profile, where they will be read by every file. Then, you might choose to have ~/.bash_profile dot in ~/.profile, and then perform a bunch of bash-specific tasks, and then finally dot in ~/.bashrc. Or, you might choose to retain only ~/.profile and keep it shell-neutral. There are lots of choices here. And this is with only the login shell layer involved -- no X11 or Wayland. > Okay, having tried that I see that it works! Set a variable in > ~/.profile, restart the Gnome session (I did a warm restart and cold > boot) and using the "Run Command" dialog (Alt-F2 in Gnome) run: > > 'sh -c "env > /tmp/env" > > and then see if your custom variable is set. In my case with the laptop > running Bullseye it does work. I now see several things that I dumped > in ~/.bashrc that aren't Bash specific and would be better put in > ~/.profile. Good thread. That's interesting, but I'm not sure I fully trust that test you performed. I don't know whether the "Run Command dialog" is doing something secretly. I'd prefer to check the actual starting environment of one of the GNOME processes. I don't know what their names are, but assuming you can find one that looks like it was started at the time you logged in, grab its PID and then do something like this: tr \\0 \\n < /proc/its_pid_here/environ | grep your_variable_here That will show you the initial environment of that process, without letting "Run Command" get involved to do any tricky stuff. If it turns out that the Wayland session really does dot in ~/.profile, th
Re: How To Permanently Add-to a Users PATH Statement in the Bash Shell
* On 2020 07 Jul 08:58 -0500, Stephen P. Molnar wrote: > The Subject line is the problem with my Debian Buster platform. Now from > Google I see that there has been a change in the way Debian handles this > problem. > > My user path statement is: > > comp@AbNormal:~$ echo $PATH > /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games > > Now I have a number of applications that have multiple executable in the app > /bin subdirectory. Hence the need to add to the users PATH statement > > As an example I have: > > /home/comp/Apps/ADFRsuite-1.0/bin > > which I would like to add to the PATH statement and: > > export PATH=$PATH:'/home/comp/Apps/ADFRsuite-1.0/bin' > > This works unless I open a new Terminal, in which case it is no longer in > the PATH. > > How do I make the addition persistent? I just saw a related blog post from the Debian Planet blog aggregator (https://planet.debian.org/): https://noah.meyerhans.us/2020/07/07/setting-environment-variables-for-gnome-session/ The post does not reference this thread but may have been inspired by it or not. Regardless, the author is trying to solve a similar problem with Gnome on Wayland. As I read it, where an environment variable should be set depends on the intended scope of the variable. One comment in response to the blog post states that ~/.profile should be used to set such variables and that even Gnome on Wayland will read this file (I've not tried it yet myself). There is a caveat! Isn't there always? The comments at the top of /etc/skel/.profile note: # ~/.profile: executed by the command interpreter for login shells. # This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login # exists. # see /usr/share/doc/bash/examples/startup-files for examples. # the files are located in the bash-doc package. For whatever historical reason I do have ~/.bash_profile which does nothing other than source ~/.bashrc when Bash is invoked as a login shell. I think I'll move it out of the way and use ~/.profile instead. Okay, having tried that I see that it works! Set a variable in ~/.profile, restart the Gnome session (I did a warm restart and cold boot) and using the "Run Command" dialog (Alt-F2 in Gnome) run: 'sh -c "env > /tmp/env" and then see if your custom variable is set. In my case with the laptop running Bullseye it does work. I now see several things that I dumped in ~/.bashrc that aren't Bash specific and would be better put in ~/.profile. Good thread. - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: How To Permanently Add-to a Users PATH Statement in the Bash Shell
On Wed, Jul 08, 2020 at 07:39:40AM -0400, Greg Wooledge wrote: > On Wed, Jul 08, 2020 at 10:44:39AM +1000, Zenaan Harkness wrote: > > - XFCE acts as, or uses, Dash or something that does not propagate shell > > functions in the parent env > > There are many layers involved. Assuming you're logging in with a "Debian > X session", a POSIX shell (sh) is used to read most of the config files > for the Xsession stuff. Bash extensions like exporting functions won't > be possible at that point. > > > - so launch startx, figuring out over many failures to start "modern" > > "sessions" > > Yeah, as I keep saying to others on this list, the entire login paradigm > is different when you use startx vs. a display manager. Testing one by > using the other is not going to work. > > With a console+startx login, your session is begun by an interactive > login shell (probably bash). Tricks like exporting functions into the > environment with the intent to make them available in all of your future > xterms *will* work from here. > > They *won't* work from a display manager login, though. > > With a DM login, you have a bunch of sh scripts (which aren't even login > shells) that can export variables but *not* functions. You don't get > a bash shell until you actually open a terminal. > > None of your shell's dot files are used at all, until you open a terminal, > and then *only* .bashrc gets read (unless you configure your terminal > to run a login shell -- which some people do, just to make things even > *more* difficult to explain and diagnose). > > > - but alas, XFCE would not propagate shell functions > > It's not XFCE per se. It's the fact that a display manager was used for > the initial login. Even if you configure it to run a single gigantic > xterm and nothing else. > > On Wed, Jul 08, 2020 at 08:24:56AM +0300, Andrei POPESCU wrote: > > On Mi, 08 iul 20, 10:44:39, Zenaan Harkness wrote: > > > - so try somewhere in the session startup apps - nope, courdn't > > > figure it out at least > > > > For Debian you want ~/.xsessionrc > > Do note, as I mentioned on the wiki, that ~/.xsessionrc is read by > a POSIX shell, and you can't use bashisms in it. > > unicorn:~$ grep -r USERXSESSIONRC /etc/X11 > /etc/X11/Xsession.d/40x11-common_xsessionrc:if [ -r "$USERXSESSIONRC" ]; then > /etc/X11/Xsession.d/40x11-common_xsessionrc: . "$USERXSESSIONRC" > /etc/X11/Xsession:USERXSESSIONRC=$HOME/.xsessionrc > > See, the ~/.xsessionrc file is dotted in (by a POSIX shell). It's not > executed as a program. So you can't just change the shebang on it, or > anything like that. > > If the goal is to export bash functions into the environment for the > entire session, honestly, sticking with console + startx is the best > approach. Some useful hints there, thank you. But, snigger moan, xfce-session is "special". No dice on the bashisms (admittedly, about 4 yrs since I looked). You see, XFCE Just Wurked™©® for a number of things, and I like that nostalgic WindowsXP feel it gives (I know, I know, brown paper bag firmly planted on head...).
Re: How To Permanently Add-to a Users PATH Statement in the Bash Shell
On Wed, Jul 08, 2020 at 10:44:39AM +1000, Zenaan Harkness wrote: > - XFCE acts as, or uses, Dash or something that does not propagate shell > functions in the parent env There are many layers involved. Assuming you're logging in with a "Debian X session", a POSIX shell (sh) is used to read most of the config files for the Xsession stuff. Bash extensions like exporting functions won't be possible at that point. > - so launch startx, figuring out over many failures to start "modern" > "sessions" Yeah, as I keep saying to others on this list, the entire login paradigm is different when you use startx vs. a display manager. Testing one by using the other is not going to work. With a console+startx login, your session is begun by an interactive login shell (probably bash). Tricks like exporting functions into the environment with the intent to make them available in all of your future xterms *will* work from here. They *won't* work from a display manager login, though. With a DM login, you have a bunch of sh scripts (which aren't even login shells) that can export variables but *not* functions. You don't get a bash shell until you actually open a terminal. None of your shell's dot files are used at all, until you open a terminal, and then *only* .bashrc gets read (unless you configure your terminal to run a login shell -- which some people do, just to make things even *more* difficult to explain and diagnose). > - but alas, XFCE would not propagate shell functions It's not XFCE per se. It's the fact that a display manager was used for the initial login. Even if you configure it to run a single gigantic xterm and nothing else. On Wed, Jul 08, 2020 at 08:24:56AM +0300, Andrei POPESCU wrote: > On Mi, 08 iul 20, 10:44:39, Zenaan Harkness wrote: > > - so try somewhere in the session startup apps - nope, courdn't > > figure it out at least > > For Debian you want ~/.xsessionrc Do note, as I mentioned on the wiki, that ~/.xsessionrc is read by a POSIX shell, and you can't use bashisms in it. unicorn:~$ grep -r USERXSESSIONRC /etc/X11 /etc/X11/Xsession.d/40x11-common_xsessionrc:if [ -r "$USERXSESSIONRC" ]; then /etc/X11/Xsession.d/40x11-common_xsessionrc: . "$USERXSESSIONRC" /etc/X11/Xsession:USERXSESSIONRC=$HOME/.xsessionrc See, the ~/.xsessionrc file is dotted in (by a POSIX shell). It's not executed as a program. So you can't just change the shebang on it, or anything like that. If the goal is to export bash functions into the environment for the entire session, honestly, sticking with console + startx is the best approach.
Re: How To Permanently Add-to a Users PATH Statement in the Bash Shell
On Mi, 08 iul 20, 10:44:39, Zenaan Harkness wrote: > > - so try somewhere in the session startup apps - nope, courdn't > figure it out at least For Debian you want ~/.xsessionrc Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: How To Permanently Add-to a Users PATH Statement in the Bash Shell
On Mi, 08 iul 20, 09:59:52, Zenaan Harkness wrote: > On Tue, Jul 07, 2020 at 10:29:47AM -0400, Greg Wooledge wrote: > > > > $HOME/bin is placed into the user's default PATH by Debian's ~/.profile > > (the one in /etc/skel/.profile) if it exists at the time the ~/.profile > > is read, if the ~/.profile is read at all. > > > > As I keep saying, of course, what dot files actually get read depends > > on how one logs in. > > That souds mildly disconcerting - when does `~/.profile` _not_ get read? In addition to what others mentioned, when you start an X session via most (all?) display managers. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: How To Permanently Add-to a Users PATH Statement in the Bash Shell
On Tue 07 Jul 2020 at 20:20:11 (-0400), Roberto C. Sánchez wrote: > On Wed, Jul 08, 2020 at 09:59:52AM +1000, Zenaan Harkness wrote: > > On Tue, Jul 07, 2020 at 10:29:47AM -0400, Greg Wooledge wrote: > > > On Tue, Jul 07, 2020 at 03:17:37PM +0100, Jonathan Dowland wrote: > > > > On Tue, Jul 07, 2020 at 04:14:16PM +0200, Nicolas George wrote: > > > > > cd ~/bin > > > > > ln -s ../opt/something/bin/something > > > > > > > > Not in the default PATH either. > > > > > > $HOME/bin is placed into the user's default PATH by Debian's ~/.profile > > > (the one in /etc/skel/.profile) if it exists at the time the ~/.profile > > > is read, if the ~/.profile is read at all. > > > > > > As I keep saying, of course, what dot files actually get read depends > > > on how one logs in. > > > > That souds mildly disconcerting - when does `~/.profile` _not_ get read? > > > When the shell is invoked non-interactively, or when it is invoked > interactively with --noprofile. Note that the --login option will cause > a non-interactive shell to read ~/.profile (along with other > configuration files). Some of us use ~/.bash_profile (and even ~/.bash_login) which will override ~/.profile being read. Of course, you're best reading man bashfor a fuller story of bash's machinations. Cheers, David.
Re: How To Permanently Add-to a Users PATH Statement in the Bash Shell
On Tue, Jul 07, 2020 at 10:16:21AM -0400, Greg Wooledge wrote: > Gods, I am so tired of this question and having to repeat my demands > for BASIC information over and over. > > Here are some resources for those of you who refuse to reveal any of > the necessary background information to get answers, and would rather > hoard all of your details under the guise of "privacy" or whatever. > > https://wiki.debian.org/Xsession > https://wiki.debian.org/EnvironmentVariables > https://mywiki.wooledge.org/DotFiles > > That is nowhere NEAR a comprehensive overveiw of every possible piece > of every possible configuration, but it's a starting point. I faced this issue a few years back, doing a Linux console login (manual crypt bindmount for $HOME), setting some env functions in BASH, and very naievely thinking they would appear in my Bash shells within a manually launched XFCE __session__! The complexity of this is interesting: - XFCE acts as, or uses, Dash or something that does not propagate shell functions in the parent env - this is despite that functions are essentially "fancy vars" which are `eval`ed - so launch startx, figuring out over many failures to start "modern" "sessions" - eventually `dbus`es, keyboards, USB disks and everything works at least marginally - discover that your initial default session, spanning 2 monitors, 9 desktops, and with an official gazillion terms, is a little slow, to start - decide that the best way to speed things up is to reduce your 600+ shell function env init overhead - which was hitting twice for every term, because TMUX :D - and since we're doing a pre-X Linux console based initial login, what better reduction than to have a single environment inherited by all sub processes including shells? - but alas, XFCE would not propagate shell functions - so try somewhere in the session startup apps - nope, courdn't figure it out at least - ended up bypassing the session entirely and learning how to ride the "bash handles your multiple Xorg monitors" bronco, beautifully laying out those "official gazillion" terms - with one Master Of The Bash Universe (MOTBU) wielding the all powerful One Term to Rule Them All - or at least, that's how it felt :) And the One Term (naturally shortened of course to just The One) loaded up it's env with all those juicy functions _before_ launching all the others - as a bonus, this Uber One Term get up, would be usable in any desktop session, not limited to the XFCE I was using It shall be tidied up and drip fed in a torrent of git lollies to the screaming hoards, hopefully not too far away ;) Create your world,
Re: How To Permanently Add-to a Users PATH Statement in the Bash Shell
On Wed, Jul 08, 2020 at 09:59:52AM +1000, Zenaan Harkness wrote: > On Tue, Jul 07, 2020 at 10:29:47AM -0400, Greg Wooledge wrote: > > On Tue, Jul 07, 2020 at 03:17:37PM +0100, Jonathan Dowland wrote: > > > On Tue, Jul 07, 2020 at 04:14:16PM +0200, Nicolas George wrote: > > > > cd ~/bin > > > > ln -s ../opt/something/bin/something > > > > > > Not in the default PATH either. > > > > $HOME/bin is placed into the user's default PATH by Debian's ~/.profile > > (the one in /etc/skel/.profile) if it exists at the time the ~/.profile > > is read, if the ~/.profile is read at all. > > > > As I keep saying, of course, what dot files actually get read depends > > on how one logs in. > > > That souds mildly disconcerting - when does `~/.profile` _not_ get read? > When the shell is invoked non-interactively, or when it is invoked interactively with --noprofile. Note that the --login option will cause a non-interactive shell to read ~/.profile (along with other configuration files). Regards, -Roberto -- Roberto C. Sánchez
Re: How To Permanently Add-to a Users PATH Statement in the Bash Shell
Ahh, asked too soon. Thanks Greg. On Tue, Jul 07, 2020 at 10:16:21AM -0400, Greg Wooledge wrote: > On Tue, Jul 07, 2020 at 09:57:34AM -0400, Stephen P. Molnar wrote: > > The Subject line is the problem > > Yeah. The Subject: line reveals the problem: you believe that PATH is > set primarily by your shell. > > It's not. It's set primarily by your method of login, and then by your > session tools, whether those be a shell or a desktop environment. A > shell may have the final word in some setups, but in many cases, > most of your environment is set before a shell is even executed. ...
Re: How To Permanently Add-to a Users PATH Statement in the Bash Shell
On Tue, Jul 07, 2020 at 10:29:47AM -0400, Greg Wooledge wrote: > On Tue, Jul 07, 2020 at 03:17:37PM +0100, Jonathan Dowland wrote: > > On Tue, Jul 07, 2020 at 04:14:16PM +0200, Nicolas George wrote: > > > cd ~/bin > > > ln -s ../opt/something/bin/something > > > > Not in the default PATH either. > > $HOME/bin is placed into the user's default PATH by Debian's ~/.profile > (the one in /etc/skel/.profile) if it exists at the time the ~/.profile > is read, if the ~/.profile is read at all. > > As I keep saying, of course, what dot files actually get read depends > on how one logs in. That souds mildly disconcerting - when does `~/.profile` _not_ get read?
Re: How To Permanently Add-to a Users PATH Statement in the Bash Shell
Jonathan Dowland (12020-07-07): > Not in the default PATH either. No, but probably one of the first things anybody who has non-elementary use will have configured anyway. Regards, -- Nicolas George signature.asc Description: PGP signature
Re: How To Permanently Add-to a Users PATH Statement in the Bash Shell
On Tue, Jul 07, 2020 at 03:17:37PM +0100, Jonathan Dowland wrote: > On Tue, Jul 07, 2020 at 04:14:16PM +0200, Nicolas George wrote: > > cd ~/bin > > ln -s ../opt/something/bin/something > > Not in the default PATH either. $HOME/bin is placed into the user's default PATH by Debian's ~/.profile (the one in /etc/skel/.profile) if it exists at the time the ~/.profile is read, if the ~/.profile is read at all. As I keep saying, of course, what dot files actually get read depends on how one logs in.
Re: How To Permanently Add-to a Users PATH Statement in the Bash Shell
On Tue, Jul 07, 2020 at 04:14:16PM +0200, Nicolas George wrote: cd ~/bin ln -s ../opt/something/bin/something Not in the default PATH either. -- 👱🏻 Jonathan Dowland ✎j...@debian.org 🔗 https://jmtd.net
Re: How To Permanently Add-to a Users PATH Statement in the Bash Shell
On Tue, Jul 07, 2020 at 09:57:34AM -0400, Stephen P. Molnar wrote: > The Subject line is the problem Yeah. The Subject: line reveals the problem: you believe that PATH is set primarily by your shell. It's not. It's set primarily by your method of login, and then by your session tools, whether those be a shell or a desktop environment. A shell may have the final word in some setups, but in many cases, most of your environment is set before a shell is even executed. > with my Debian Buster platform. Now from > Google I see that there has been a change in the way Debian handles this > problem. Huh? What did you type into Google? What random page on the entire freaking Internet did you read? What did you pick up from it? Is it true or a lie? > [[blah blah blah nothing about how you log in]] > This works unless I open a new Terminal, in which case it is no longer in > the PATH. The only detail you've given us is that you have something you call a "Terminal", with a capital T. Is that the actual name of the terminal emulator you run? Maybe someone else who reads this message can figure out "Oh, he said Terminal with a capital T, that must mean he's running Desktop." If you actually want to understand how your environment is set during login, you have to reveal the necessary details, and that starts with *HOW* you log in (console login + startx, gdm3, sddm, lightdm, ssh, or something else). We also need to know if you run a Desktop Environment, and if so, which one. On top of that, it would be useful to know what terminal emulator you're using to *TRY* to verify the PATH variable, and what options were given to it. Believe it or not, the PATH variable you see in a terminal emulator may not be the same as the one used by your window manager, etc. Gods, I am so tired of this question and having to repeat my demands for BASIC information over and over. Here are some resources for those of you who refuse to reveal any of the necessary background information to get answers, and would rather hoard all of your details under the guise of "privacy" or whatever. https://wiki.debian.org/Xsession https://wiki.debian.org/EnvironmentVariables https://mywiki.wooledge.org/DotFiles That is nowhere NEAR a comprehensive overveiw of every possible piece of every possible configuration, but it's a starting point.
Re: How To Permanently Add-to a Users PATH Statement in the Bash Shell
Roberto C. Sánchez (12020-07-07): > You should add the export command to ~/.bashrc (for it to only be in > effect for that user) Except ~/.bashrc is only sourced for interactive shells, it will not be run when applications are executed by a GUI, for example. (Also, for some reason, the bash authors thought it was a good idea to have login interactive shells not run ~/.bashrc; better use a saner shell and put the environment in ~/.zshenv, which is sourced by all shells.) But adding the application bin directory to the $PATH environment is entirely the wrong way of going at it. It results in huge $PATH, which increase the cost of running everything and makes the system more fragile. The right way of going at it is to make the application entry points appear in the directories that are already in $PATH. cd ~/bin ln -s ../opt/something/bin/something (relative paths are to be preferred in these cases) Regards, -- Nicolas George signature.asc Description: PGP signature
Re: How To Permanently Add-to a Users PATH Statement in the Bash Shell
On Tue, Jul 07, 2020 at 09:57:34AM -0400, Stephen P. Molnar wrote: > The Subject line is the problem with my Debian Buster platform. Now from > Google I see that there has been a change in the way Debian handles this > problem. > I'm not sure what change you are referring to, but from what you describe below I find it unlikely that anything has changed in the observed behavior. > My user path statement is: > > comp@AbNormal:~$ echo $PATH > /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games > > Now I have a number of applications that have multiple executable in the app > /bin subdirectory. Hence the need to add to the users PATH statement > > As an example I have: > > /home/comp/Apps/ADFRsuite-1.0/bin > > which I would like to add to the PATH statement and: > > export PATH=$PATH:'/home/comp/Apps/ADFRsuite-1.0/bin' > > This works unless I open a new Terminal, in which case it is no longer in > the PATH. > Opening a new terminal spawns a new process. If the parent of the new process is not the shell in which you executed the 'export' command, then when the PATH variable is set based on the system and user configuration files it will lack the additional value from the 'export'. > How do I make the addition persistent? > You should add the export command to ~/.bashrc (for it to only be in effect for that user) or to /etc/bash.bashrc (for it to be in effect for all users on the system). Regards, -Roberto -- Roberto C. Sánchez
