Why doesn't my ~/.bash_profile work?
Clash Royale CLAN TAG#URR8PPP
up vote
26
down vote
favorite
I'm using Linux Mint. My login shell (cat /etc/passwd | grep myUserName
) is bash.
After I start my graphical desktop environment and run a terminal emulator from it, I can see that .bash_profile
is not sourced (environment vars that are export
ed in it are unset). But if I log in from a text console (ctrl+alt+F1) or manually run bash -l
from the terminal emulator, .bash_profile
works fine.
Am I wrong when I think that .bash_profile
should be sourced when X starts and all export
'ed vars should be available in the terminal, running from X?
P.S. Placing everything in .bashrc
and sourcing it from .bash_profile
is not good idea (https://stackoverflow.com/questions/902946/): environment stuff should be sourced only once.
bash shell login profile
add a comment |Â
up vote
26
down vote
favorite
I'm using Linux Mint. My login shell (cat /etc/passwd | grep myUserName
) is bash.
After I start my graphical desktop environment and run a terminal emulator from it, I can see that .bash_profile
is not sourced (environment vars that are export
ed in it are unset). But if I log in from a text console (ctrl+alt+F1) or manually run bash -l
from the terminal emulator, .bash_profile
works fine.
Am I wrong when I think that .bash_profile
should be sourced when X starts and all export
'ed vars should be available in the terminal, running from X?
P.S. Placing everything in .bashrc
and sourcing it from .bash_profile
is not good idea (https://stackoverflow.com/questions/902946/): environment stuff should be sourced only once.
bash shell login profile
add a comment |Â
up vote
26
down vote
favorite
up vote
26
down vote
favorite
I'm using Linux Mint. My login shell (cat /etc/passwd | grep myUserName
) is bash.
After I start my graphical desktop environment and run a terminal emulator from it, I can see that .bash_profile
is not sourced (environment vars that are export
ed in it are unset). But if I log in from a text console (ctrl+alt+F1) or manually run bash -l
from the terminal emulator, .bash_profile
works fine.
Am I wrong when I think that .bash_profile
should be sourced when X starts and all export
'ed vars should be available in the terminal, running from X?
P.S. Placing everything in .bashrc
and sourcing it from .bash_profile
is not good idea (https://stackoverflow.com/questions/902946/): environment stuff should be sourced only once.
bash shell login profile
I'm using Linux Mint. My login shell (cat /etc/passwd | grep myUserName
) is bash.
After I start my graphical desktop environment and run a terminal emulator from it, I can see that .bash_profile
is not sourced (environment vars that are export
ed in it are unset). But if I log in from a text console (ctrl+alt+F1) or manually run bash -l
from the terminal emulator, .bash_profile
works fine.
Am I wrong when I think that .bash_profile
should be sourced when X starts and all export
'ed vars should be available in the terminal, running from X?
P.S. Placing everything in .bashrc
and sourcing it from .bash_profile
is not good idea (https://stackoverflow.com/questions/902946/): environment stuff should be sourced only once.
bash shell login profile
edited Mar 20 at 14:29
psmears
43528
43528
asked Aug 25 '13 at 8:09
AntonioK
5422726
5422726
add a comment |Â
add a comment |Â
5 Answers
5
active
oldest
votes
up vote
30
down vote
accepted
The file ~/.bash_profile
is read by bash when it is a login shell. That's what you get when you log in in text mode.
When you log in under X, the startup scripts are executed by /bin/sh
. On Ubuntu and Mint, /bin/sh
is dash, not bash. Dash and bash both have the same core features, but dash sticks to these core features in order to be fast and small whereas bash adds a lot of features at the cost of requiring more resources. It is common to use dash for scripts that don't need the extra features and bash for interactive use (though zsh has a lot of nicer features).
Most combinations of display manager (the program where you type your user name and password) and desktop environment read ~/.profile
from the login scripts in /etc/X11/Xsession
, /usr/bin/lightdm-session
, /etc/gdm/Xsession
or whichever is applicable. So put your environment variable definitions in ~/.profile
. Make sure to use only syntax that dash supports.
So what should you put where?
A good
.bash_profile
loads.profile
, and loads.bashrc
if the shell is interactive.. ~/.profile
if [[ $- == *i* ]]; then . ~/.bashrc; fiIn
.profile
, put environment variable definitions, and other session settings such asulimit
.- In
.bashrc
, put bash interactive settings such as aliases, functions, completion, key bindings (that aren't in.inputrc
), â¦
See also Difference between Login Shell and Non-Login Shell? and Alternative to .bashrc.
many things learnt from single answer :)
â mtk
Jul 24 '16 at 20:31
add a comment |Â
up vote
14
down vote
.bash_profile
is the startup configuration script of bash. There exists no standard mandating X to source .bash_profile
.
What you are thinking of is rather .profile
. Originally it was the startup configuration file of the bourne shell (sh). Today many distributions have their desktop environment set up to source .profile
. Note that this is also not a standard, but it seems to be a convention.
Debian used to source .profile
at graphical login (wiki page as of 2013) now it doesn't (wiki page as of 2016).
Arch sources .xprofile
at graphical login (wiki page as of 2013).
Ubuntu used to discourage using .profile
(wiki page as of 2013) now it doesn't discourage anymore (wiki page as of 2016).
Regarding your other question: Why doesn't my ~/.bash_profile work? That is the expected behaviour.
The behaviour, in short, is as follows:
- bash started as an interactive login shell: reads
~/.profile
- bash started as an interactive non-login shell: reads
~/.bashrc
For more details see my answer to a similar question in askubuntu: https://askubuntu.com/questions/132276/configure-gnome-terminal-to-start-bash-as-a-login-shell-doesnt-read-bashrc/132319#132319
1
Some of this is correct, but âÂÂalways read~/.bashrc
â is bad advice: you should only read.bashrc
from an interactive shell. You've missed the core problem here which is that when logging in under X, there is no login instance of bash (under most display manager/desktop environment combinations, including evidently AntonioK's).
â Gilles
Aug 25 '13 at 22:45
Thank you for your feedback. I hope I updated my answer well enough to resolve your complaints. Regarding my advice to "always read.bashrc
", I meant always for an interactive shell. I have clarified that part. I hope it is not misleading anymore.
â lesmana
Aug 26 '13 at 2:21
2
"Ubuntu specifically discourages using.profile
(link)" The wiki did once (absurdly) discourage that; that's been fixed. (Note/etc/profile
does remain discouraged for systemwide assignments, in preference for adding scripts to/etc/profile.d
.) Per-user.profile
files are now presented as one of the recommended ways to set per-user environment variables: "Suitable files for environment variable settings that should affect just a particular user (rather than the system as a whole) are ~/.pam_environment and ~/.profile."
â Eliah Kagan
Oct 4 '14 at 2:37
The linked page about Debian specifies that Debian does not read~/.profile
for graphical login and~/.xsessionrc
should be used instead.
â karora
Mar 20 at 11:29
thanks for noticing. the wiki page got updated. i linked to the versions as they were at time of answer.
â lesmana
Mar 21 at 8:38
add a comment |Â
up vote
1
down vote
In your question, you refer to https://stackoverflow.com/questions/902946/ as recommending not to source, when the accepted answer prescribes to
- Put my PATH setup into a .profile file (because I sometimes use other shells)
- Put my Bash aliases and functions into my .bashrc file
Then use this [EDITED: snip code-comments]:
.bash_profile
:#!/bin/bash
# echo "Loading $HOME/.bash_profile"
source ~/.profile # Get the paths
source ~/.bashrc # get aliases
Putting it all in .profile
did not work for me on Linux Mint. Using .bashrc
worked fine.
add a comment |Â
up vote
1
down vote
A couple of issues arise when trying to reload/source ~/.profile file.
[This refers to Ubuntu linux - in some cases the details of the commands will be different]
- Are you running this directly in terminal or in a script?
- How do you run this in a script?
Ad. 1)
Running this directly in terminal means that there will be no subshell created. So you can use either two commands:
source ~/.bash_profile
or
. ~/.bash_profile
In both cases this will update the environment with the contents of .profile file.
Ad 2) You can start any bash script either by calling
sh myscript.sh
or
. myscript.sh
In the first case this will create a subshell that will not affect the environment variables of your system and they will be visible only to the subshell process. After finishing the subshell command none of the exports etc. will be applied.
THIS IS A COMMON MISTAKE AND CAUSES A LOT OF DEVELOPERS TO LOOSE A LOT OF TIME.
In order for your changes applied in your script to have effect for the global environment the script has to be run with
.myscript.sh
command.
In order to make sure that you script is not runned in a subshel you can use this function. (Again example is for Ubuntu shell)
#/bin/bash
preventSubshell()
if [[ $_ != $0 ]]
then
echo "Script is being sourced"
else
echo "Script is a subshell - please run the script by invoking . script.sh command";
exit 1;
fi
I hope this clears some of the common misunderstandings! :D
Good Luck!
add a comment |Â
up vote
0
down vote
The simple solution is to make the terminal a login terminal. For Gnome terminal under 'Tile and Command' of the default profile you can check the box "Run command as a login shell". This article explains the difference between a login shell and one that is not.
add a comment |Â
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
30
down vote
accepted
The file ~/.bash_profile
is read by bash when it is a login shell. That's what you get when you log in in text mode.
When you log in under X, the startup scripts are executed by /bin/sh
. On Ubuntu and Mint, /bin/sh
is dash, not bash. Dash and bash both have the same core features, but dash sticks to these core features in order to be fast and small whereas bash adds a lot of features at the cost of requiring more resources. It is common to use dash for scripts that don't need the extra features and bash for interactive use (though zsh has a lot of nicer features).
Most combinations of display manager (the program where you type your user name and password) and desktop environment read ~/.profile
from the login scripts in /etc/X11/Xsession
, /usr/bin/lightdm-session
, /etc/gdm/Xsession
or whichever is applicable. So put your environment variable definitions in ~/.profile
. Make sure to use only syntax that dash supports.
So what should you put where?
A good
.bash_profile
loads.profile
, and loads.bashrc
if the shell is interactive.. ~/.profile
if [[ $- == *i* ]]; then . ~/.bashrc; fiIn
.profile
, put environment variable definitions, and other session settings such asulimit
.- In
.bashrc
, put bash interactive settings such as aliases, functions, completion, key bindings (that aren't in.inputrc
), â¦
See also Difference between Login Shell and Non-Login Shell? and Alternative to .bashrc.
many things learnt from single answer :)
â mtk
Jul 24 '16 at 20:31
add a comment |Â
up vote
30
down vote
accepted
The file ~/.bash_profile
is read by bash when it is a login shell. That's what you get when you log in in text mode.
When you log in under X, the startup scripts are executed by /bin/sh
. On Ubuntu and Mint, /bin/sh
is dash, not bash. Dash and bash both have the same core features, but dash sticks to these core features in order to be fast and small whereas bash adds a lot of features at the cost of requiring more resources. It is common to use dash for scripts that don't need the extra features and bash for interactive use (though zsh has a lot of nicer features).
Most combinations of display manager (the program where you type your user name and password) and desktop environment read ~/.profile
from the login scripts in /etc/X11/Xsession
, /usr/bin/lightdm-session
, /etc/gdm/Xsession
or whichever is applicable. So put your environment variable definitions in ~/.profile
. Make sure to use only syntax that dash supports.
So what should you put where?
A good
.bash_profile
loads.profile
, and loads.bashrc
if the shell is interactive.. ~/.profile
if [[ $- == *i* ]]; then . ~/.bashrc; fiIn
.profile
, put environment variable definitions, and other session settings such asulimit
.- In
.bashrc
, put bash interactive settings such as aliases, functions, completion, key bindings (that aren't in.inputrc
), â¦
See also Difference between Login Shell and Non-Login Shell? and Alternative to .bashrc.
many things learnt from single answer :)
â mtk
Jul 24 '16 at 20:31
add a comment |Â
up vote
30
down vote
accepted
up vote
30
down vote
accepted
The file ~/.bash_profile
is read by bash when it is a login shell. That's what you get when you log in in text mode.
When you log in under X, the startup scripts are executed by /bin/sh
. On Ubuntu and Mint, /bin/sh
is dash, not bash. Dash and bash both have the same core features, but dash sticks to these core features in order to be fast and small whereas bash adds a lot of features at the cost of requiring more resources. It is common to use dash for scripts that don't need the extra features and bash for interactive use (though zsh has a lot of nicer features).
Most combinations of display manager (the program where you type your user name and password) and desktop environment read ~/.profile
from the login scripts in /etc/X11/Xsession
, /usr/bin/lightdm-session
, /etc/gdm/Xsession
or whichever is applicable. So put your environment variable definitions in ~/.profile
. Make sure to use only syntax that dash supports.
So what should you put where?
A good
.bash_profile
loads.profile
, and loads.bashrc
if the shell is interactive.. ~/.profile
if [[ $- == *i* ]]; then . ~/.bashrc; fiIn
.profile
, put environment variable definitions, and other session settings such asulimit
.- In
.bashrc
, put bash interactive settings such as aliases, functions, completion, key bindings (that aren't in.inputrc
), â¦
See also Difference between Login Shell and Non-Login Shell? and Alternative to .bashrc.
The file ~/.bash_profile
is read by bash when it is a login shell. That's what you get when you log in in text mode.
When you log in under X, the startup scripts are executed by /bin/sh
. On Ubuntu and Mint, /bin/sh
is dash, not bash. Dash and bash both have the same core features, but dash sticks to these core features in order to be fast and small whereas bash adds a lot of features at the cost of requiring more resources. It is common to use dash for scripts that don't need the extra features and bash for interactive use (though zsh has a lot of nicer features).
Most combinations of display manager (the program where you type your user name and password) and desktop environment read ~/.profile
from the login scripts in /etc/X11/Xsession
, /usr/bin/lightdm-session
, /etc/gdm/Xsession
or whichever is applicable. So put your environment variable definitions in ~/.profile
. Make sure to use only syntax that dash supports.
So what should you put where?
A good
.bash_profile
loads.profile
, and loads.bashrc
if the shell is interactive.. ~/.profile
if [[ $- == *i* ]]; then . ~/.bashrc; fiIn
.profile
, put environment variable definitions, and other session settings such asulimit
.- In
.bashrc
, put bash interactive settings such as aliases, functions, completion, key bindings (that aren't in.inputrc
), â¦
See also Difference between Login Shell and Non-Login Shell? and Alternative to .bashrc.
edited Apr 13 '17 at 12:36
Communityâ¦
1
1
answered Aug 25 '13 at 22:43
Gilles
508k12010031533
508k12010031533
many things learnt from single answer :)
â mtk
Jul 24 '16 at 20:31
add a comment |Â
many things learnt from single answer :)
â mtk
Jul 24 '16 at 20:31
many things learnt from single answer :)
â mtk
Jul 24 '16 at 20:31
many things learnt from single answer :)
â mtk
Jul 24 '16 at 20:31
add a comment |Â
up vote
14
down vote
.bash_profile
is the startup configuration script of bash. There exists no standard mandating X to source .bash_profile
.
What you are thinking of is rather .profile
. Originally it was the startup configuration file of the bourne shell (sh). Today many distributions have their desktop environment set up to source .profile
. Note that this is also not a standard, but it seems to be a convention.
Debian used to source .profile
at graphical login (wiki page as of 2013) now it doesn't (wiki page as of 2016).
Arch sources .xprofile
at graphical login (wiki page as of 2013).
Ubuntu used to discourage using .profile
(wiki page as of 2013) now it doesn't discourage anymore (wiki page as of 2016).
Regarding your other question: Why doesn't my ~/.bash_profile work? That is the expected behaviour.
The behaviour, in short, is as follows:
- bash started as an interactive login shell: reads
~/.profile
- bash started as an interactive non-login shell: reads
~/.bashrc
For more details see my answer to a similar question in askubuntu: https://askubuntu.com/questions/132276/configure-gnome-terminal-to-start-bash-as-a-login-shell-doesnt-read-bashrc/132319#132319
1
Some of this is correct, but âÂÂalways read~/.bashrc
â is bad advice: you should only read.bashrc
from an interactive shell. You've missed the core problem here which is that when logging in under X, there is no login instance of bash (under most display manager/desktop environment combinations, including evidently AntonioK's).
â Gilles
Aug 25 '13 at 22:45
Thank you for your feedback. I hope I updated my answer well enough to resolve your complaints. Regarding my advice to "always read.bashrc
", I meant always for an interactive shell. I have clarified that part. I hope it is not misleading anymore.
â lesmana
Aug 26 '13 at 2:21
2
"Ubuntu specifically discourages using.profile
(link)" The wiki did once (absurdly) discourage that; that's been fixed. (Note/etc/profile
does remain discouraged for systemwide assignments, in preference for adding scripts to/etc/profile.d
.) Per-user.profile
files are now presented as one of the recommended ways to set per-user environment variables: "Suitable files for environment variable settings that should affect just a particular user (rather than the system as a whole) are ~/.pam_environment and ~/.profile."
â Eliah Kagan
Oct 4 '14 at 2:37
The linked page about Debian specifies that Debian does not read~/.profile
for graphical login and~/.xsessionrc
should be used instead.
â karora
Mar 20 at 11:29
thanks for noticing. the wiki page got updated. i linked to the versions as they were at time of answer.
â lesmana
Mar 21 at 8:38
add a comment |Â
up vote
14
down vote
.bash_profile
is the startup configuration script of bash. There exists no standard mandating X to source .bash_profile
.
What you are thinking of is rather .profile
. Originally it was the startup configuration file of the bourne shell (sh). Today many distributions have their desktop environment set up to source .profile
. Note that this is also not a standard, but it seems to be a convention.
Debian used to source .profile
at graphical login (wiki page as of 2013) now it doesn't (wiki page as of 2016).
Arch sources .xprofile
at graphical login (wiki page as of 2013).
Ubuntu used to discourage using .profile
(wiki page as of 2013) now it doesn't discourage anymore (wiki page as of 2016).
Regarding your other question: Why doesn't my ~/.bash_profile work? That is the expected behaviour.
The behaviour, in short, is as follows:
- bash started as an interactive login shell: reads
~/.profile
- bash started as an interactive non-login shell: reads
~/.bashrc
For more details see my answer to a similar question in askubuntu: https://askubuntu.com/questions/132276/configure-gnome-terminal-to-start-bash-as-a-login-shell-doesnt-read-bashrc/132319#132319
1
Some of this is correct, but âÂÂalways read~/.bashrc
â is bad advice: you should only read.bashrc
from an interactive shell. You've missed the core problem here which is that when logging in under X, there is no login instance of bash (under most display manager/desktop environment combinations, including evidently AntonioK's).
â Gilles
Aug 25 '13 at 22:45
Thank you for your feedback. I hope I updated my answer well enough to resolve your complaints. Regarding my advice to "always read.bashrc
", I meant always for an interactive shell. I have clarified that part. I hope it is not misleading anymore.
â lesmana
Aug 26 '13 at 2:21
2
"Ubuntu specifically discourages using.profile
(link)" The wiki did once (absurdly) discourage that; that's been fixed. (Note/etc/profile
does remain discouraged for systemwide assignments, in preference for adding scripts to/etc/profile.d
.) Per-user.profile
files are now presented as one of the recommended ways to set per-user environment variables: "Suitable files for environment variable settings that should affect just a particular user (rather than the system as a whole) are ~/.pam_environment and ~/.profile."
â Eliah Kagan
Oct 4 '14 at 2:37
The linked page about Debian specifies that Debian does not read~/.profile
for graphical login and~/.xsessionrc
should be used instead.
â karora
Mar 20 at 11:29
thanks for noticing. the wiki page got updated. i linked to the versions as they were at time of answer.
â lesmana
Mar 21 at 8:38
add a comment |Â
up vote
14
down vote
up vote
14
down vote
.bash_profile
is the startup configuration script of bash. There exists no standard mandating X to source .bash_profile
.
What you are thinking of is rather .profile
. Originally it was the startup configuration file of the bourne shell (sh). Today many distributions have their desktop environment set up to source .profile
. Note that this is also not a standard, but it seems to be a convention.
Debian used to source .profile
at graphical login (wiki page as of 2013) now it doesn't (wiki page as of 2016).
Arch sources .xprofile
at graphical login (wiki page as of 2013).
Ubuntu used to discourage using .profile
(wiki page as of 2013) now it doesn't discourage anymore (wiki page as of 2016).
Regarding your other question: Why doesn't my ~/.bash_profile work? That is the expected behaviour.
The behaviour, in short, is as follows:
- bash started as an interactive login shell: reads
~/.profile
- bash started as an interactive non-login shell: reads
~/.bashrc
For more details see my answer to a similar question in askubuntu: https://askubuntu.com/questions/132276/configure-gnome-terminal-to-start-bash-as-a-login-shell-doesnt-read-bashrc/132319#132319
.bash_profile
is the startup configuration script of bash. There exists no standard mandating X to source .bash_profile
.
What you are thinking of is rather .profile
. Originally it was the startup configuration file of the bourne shell (sh). Today many distributions have their desktop environment set up to source .profile
. Note that this is also not a standard, but it seems to be a convention.
Debian used to source .profile
at graphical login (wiki page as of 2013) now it doesn't (wiki page as of 2016).
Arch sources .xprofile
at graphical login (wiki page as of 2013).
Ubuntu used to discourage using .profile
(wiki page as of 2013) now it doesn't discourage anymore (wiki page as of 2016).
Regarding your other question: Why doesn't my ~/.bash_profile work? That is the expected behaviour.
The behaviour, in short, is as follows:
- bash started as an interactive login shell: reads
~/.profile
- bash started as an interactive non-login shell: reads
~/.bashrc
For more details see my answer to a similar question in askubuntu: https://askubuntu.com/questions/132276/configure-gnome-terminal-to-start-bash-as-a-login-shell-doesnt-read-bashrc/132319#132319
edited Mar 21 at 8:37
answered Aug 25 '13 at 8:44
lesmana
13.7k105569
13.7k105569
1
Some of this is correct, but âÂÂalways read~/.bashrc
â is bad advice: you should only read.bashrc
from an interactive shell. You've missed the core problem here which is that when logging in under X, there is no login instance of bash (under most display manager/desktop environment combinations, including evidently AntonioK's).
â Gilles
Aug 25 '13 at 22:45
Thank you for your feedback. I hope I updated my answer well enough to resolve your complaints. Regarding my advice to "always read.bashrc
", I meant always for an interactive shell. I have clarified that part. I hope it is not misleading anymore.
â lesmana
Aug 26 '13 at 2:21
2
"Ubuntu specifically discourages using.profile
(link)" The wiki did once (absurdly) discourage that; that's been fixed. (Note/etc/profile
does remain discouraged for systemwide assignments, in preference for adding scripts to/etc/profile.d
.) Per-user.profile
files are now presented as one of the recommended ways to set per-user environment variables: "Suitable files for environment variable settings that should affect just a particular user (rather than the system as a whole) are ~/.pam_environment and ~/.profile."
â Eliah Kagan
Oct 4 '14 at 2:37
The linked page about Debian specifies that Debian does not read~/.profile
for graphical login and~/.xsessionrc
should be used instead.
â karora
Mar 20 at 11:29
thanks for noticing. the wiki page got updated. i linked to the versions as they were at time of answer.
â lesmana
Mar 21 at 8:38
add a comment |Â
1
Some of this is correct, but âÂÂalways read~/.bashrc
â is bad advice: you should only read.bashrc
from an interactive shell. You've missed the core problem here which is that when logging in under X, there is no login instance of bash (under most display manager/desktop environment combinations, including evidently AntonioK's).
â Gilles
Aug 25 '13 at 22:45
Thank you for your feedback. I hope I updated my answer well enough to resolve your complaints. Regarding my advice to "always read.bashrc
", I meant always for an interactive shell. I have clarified that part. I hope it is not misleading anymore.
â lesmana
Aug 26 '13 at 2:21
2
"Ubuntu specifically discourages using.profile
(link)" The wiki did once (absurdly) discourage that; that's been fixed. (Note/etc/profile
does remain discouraged for systemwide assignments, in preference for adding scripts to/etc/profile.d
.) Per-user.profile
files are now presented as one of the recommended ways to set per-user environment variables: "Suitable files for environment variable settings that should affect just a particular user (rather than the system as a whole) are ~/.pam_environment and ~/.profile."
â Eliah Kagan
Oct 4 '14 at 2:37
The linked page about Debian specifies that Debian does not read~/.profile
for graphical login and~/.xsessionrc
should be used instead.
â karora
Mar 20 at 11:29
thanks for noticing. the wiki page got updated. i linked to the versions as they were at time of answer.
â lesmana
Mar 21 at 8:38
1
1
Some of this is correct, but âÂÂalways read
~/.bashrc
â is bad advice: you should only read .bashrc
from an interactive shell. You've missed the core problem here which is that when logging in under X, there is no login instance of bash (under most display manager/desktop environment combinations, including evidently AntonioK's).â Gilles
Aug 25 '13 at 22:45
Some of this is correct, but âÂÂalways read
~/.bashrc
â is bad advice: you should only read .bashrc
from an interactive shell. You've missed the core problem here which is that when logging in under X, there is no login instance of bash (under most display manager/desktop environment combinations, including evidently AntonioK's).â Gilles
Aug 25 '13 at 22:45
Thank you for your feedback. I hope I updated my answer well enough to resolve your complaints. Regarding my advice to "always read
.bashrc
", I meant always for an interactive shell. I have clarified that part. I hope it is not misleading anymore.â lesmana
Aug 26 '13 at 2:21
Thank you for your feedback. I hope I updated my answer well enough to resolve your complaints. Regarding my advice to "always read
.bashrc
", I meant always for an interactive shell. I have clarified that part. I hope it is not misleading anymore.â lesmana
Aug 26 '13 at 2:21
2
2
"Ubuntu specifically discourages using
.profile
(link)" The wiki did once (absurdly) discourage that; that's been fixed. (Note /etc/profile
does remain discouraged for systemwide assignments, in preference for adding scripts to /etc/profile.d
.) Per-user .profile
files are now presented as one of the recommended ways to set per-user environment variables: "Suitable files for environment variable settings that should affect just a particular user (rather than the system as a whole) are ~/.pam_environment and ~/.profile."â Eliah Kagan
Oct 4 '14 at 2:37
"Ubuntu specifically discourages using
.profile
(link)" The wiki did once (absurdly) discourage that; that's been fixed. (Note /etc/profile
does remain discouraged for systemwide assignments, in preference for adding scripts to /etc/profile.d
.) Per-user .profile
files are now presented as one of the recommended ways to set per-user environment variables: "Suitable files for environment variable settings that should affect just a particular user (rather than the system as a whole) are ~/.pam_environment and ~/.profile."â Eliah Kagan
Oct 4 '14 at 2:37
The linked page about Debian specifies that Debian does not read
~/.profile
for graphical login and ~/.xsessionrc
should be used instead.â karora
Mar 20 at 11:29
The linked page about Debian specifies that Debian does not read
~/.profile
for graphical login and ~/.xsessionrc
should be used instead.â karora
Mar 20 at 11:29
thanks for noticing. the wiki page got updated. i linked to the versions as they were at time of answer.
â lesmana
Mar 21 at 8:38
thanks for noticing. the wiki page got updated. i linked to the versions as they were at time of answer.
â lesmana
Mar 21 at 8:38
add a comment |Â
up vote
1
down vote
In your question, you refer to https://stackoverflow.com/questions/902946/ as recommending not to source, when the accepted answer prescribes to
- Put my PATH setup into a .profile file (because I sometimes use other shells)
- Put my Bash aliases and functions into my .bashrc file
Then use this [EDITED: snip code-comments]:
.bash_profile
:#!/bin/bash
# echo "Loading $HOME/.bash_profile"
source ~/.profile # Get the paths
source ~/.bashrc # get aliases
Putting it all in .profile
did not work for me on Linux Mint. Using .bashrc
worked fine.
add a comment |Â
up vote
1
down vote
In your question, you refer to https://stackoverflow.com/questions/902946/ as recommending not to source, when the accepted answer prescribes to
- Put my PATH setup into a .profile file (because I sometimes use other shells)
- Put my Bash aliases and functions into my .bashrc file
Then use this [EDITED: snip code-comments]:
.bash_profile
:#!/bin/bash
# echo "Loading $HOME/.bash_profile"
source ~/.profile # Get the paths
source ~/.bashrc # get aliases
Putting it all in .profile
did not work for me on Linux Mint. Using .bashrc
worked fine.
add a comment |Â
up vote
1
down vote
up vote
1
down vote
In your question, you refer to https://stackoverflow.com/questions/902946/ as recommending not to source, when the accepted answer prescribes to
- Put my PATH setup into a .profile file (because I sometimes use other shells)
- Put my Bash aliases and functions into my .bashrc file
Then use this [EDITED: snip code-comments]:
.bash_profile
:#!/bin/bash
# echo "Loading $HOME/.bash_profile"
source ~/.profile # Get the paths
source ~/.bashrc # get aliases
Putting it all in .profile
did not work for me on Linux Mint. Using .bashrc
worked fine.
In your question, you refer to https://stackoverflow.com/questions/902946/ as recommending not to source, when the accepted answer prescribes to
- Put my PATH setup into a .profile file (because I sometimes use other shells)
- Put my Bash aliases and functions into my .bashrc file
Then use this [EDITED: snip code-comments]:
.bash_profile
:#!/bin/bash
# echo "Loading $HOME/.bash_profile"
source ~/.profile # Get the paths
source ~/.bashrc # get aliases
Putting it all in .profile
did not work for me on Linux Mint. Using .bashrc
worked fine.
edited May 23 '17 at 12:40
Communityâ¦
1
1
answered Apr 6 '16 at 7:50
serv-inc
374111
374111
add a comment |Â
add a comment |Â
up vote
1
down vote
A couple of issues arise when trying to reload/source ~/.profile file.
[This refers to Ubuntu linux - in some cases the details of the commands will be different]
- Are you running this directly in terminal or in a script?
- How do you run this in a script?
Ad. 1)
Running this directly in terminal means that there will be no subshell created. So you can use either two commands:
source ~/.bash_profile
or
. ~/.bash_profile
In both cases this will update the environment with the contents of .profile file.
Ad 2) You can start any bash script either by calling
sh myscript.sh
or
. myscript.sh
In the first case this will create a subshell that will not affect the environment variables of your system and they will be visible only to the subshell process. After finishing the subshell command none of the exports etc. will be applied.
THIS IS A COMMON MISTAKE AND CAUSES A LOT OF DEVELOPERS TO LOOSE A LOT OF TIME.
In order for your changes applied in your script to have effect for the global environment the script has to be run with
.myscript.sh
command.
In order to make sure that you script is not runned in a subshel you can use this function. (Again example is for Ubuntu shell)
#/bin/bash
preventSubshell()
if [[ $_ != $0 ]]
then
echo "Script is being sourced"
else
echo "Script is a subshell - please run the script by invoking . script.sh command";
exit 1;
fi
I hope this clears some of the common misunderstandings! :D
Good Luck!
add a comment |Â
up vote
1
down vote
A couple of issues arise when trying to reload/source ~/.profile file.
[This refers to Ubuntu linux - in some cases the details of the commands will be different]
- Are you running this directly in terminal or in a script?
- How do you run this in a script?
Ad. 1)
Running this directly in terminal means that there will be no subshell created. So you can use either two commands:
source ~/.bash_profile
or
. ~/.bash_profile
In both cases this will update the environment with the contents of .profile file.
Ad 2) You can start any bash script either by calling
sh myscript.sh
or
. myscript.sh
In the first case this will create a subshell that will not affect the environment variables of your system and they will be visible only to the subshell process. After finishing the subshell command none of the exports etc. will be applied.
THIS IS A COMMON MISTAKE AND CAUSES A LOT OF DEVELOPERS TO LOOSE A LOT OF TIME.
In order for your changes applied in your script to have effect for the global environment the script has to be run with
.myscript.sh
command.
In order to make sure that you script is not runned in a subshel you can use this function. (Again example is for Ubuntu shell)
#/bin/bash
preventSubshell()
if [[ $_ != $0 ]]
then
echo "Script is being sourced"
else
echo "Script is a subshell - please run the script by invoking . script.sh command";
exit 1;
fi
I hope this clears some of the common misunderstandings! :D
Good Luck!
add a comment |Â
up vote
1
down vote
up vote
1
down vote
A couple of issues arise when trying to reload/source ~/.profile file.
[This refers to Ubuntu linux - in some cases the details of the commands will be different]
- Are you running this directly in terminal or in a script?
- How do you run this in a script?
Ad. 1)
Running this directly in terminal means that there will be no subshell created. So you can use either two commands:
source ~/.bash_profile
or
. ~/.bash_profile
In both cases this will update the environment with the contents of .profile file.
Ad 2) You can start any bash script either by calling
sh myscript.sh
or
. myscript.sh
In the first case this will create a subshell that will not affect the environment variables of your system and they will be visible only to the subshell process. After finishing the subshell command none of the exports etc. will be applied.
THIS IS A COMMON MISTAKE AND CAUSES A LOT OF DEVELOPERS TO LOOSE A LOT OF TIME.
In order for your changes applied in your script to have effect for the global environment the script has to be run with
.myscript.sh
command.
In order to make sure that you script is not runned in a subshel you can use this function. (Again example is for Ubuntu shell)
#/bin/bash
preventSubshell()
if [[ $_ != $0 ]]
then
echo "Script is being sourced"
else
echo "Script is a subshell - please run the script by invoking . script.sh command";
exit 1;
fi
I hope this clears some of the common misunderstandings! :D
Good Luck!
A couple of issues arise when trying to reload/source ~/.profile file.
[This refers to Ubuntu linux - in some cases the details of the commands will be different]
- Are you running this directly in terminal or in a script?
- How do you run this in a script?
Ad. 1)
Running this directly in terminal means that there will be no subshell created. So you can use either two commands:
source ~/.bash_profile
or
. ~/.bash_profile
In both cases this will update the environment with the contents of .profile file.
Ad 2) You can start any bash script either by calling
sh myscript.sh
or
. myscript.sh
In the first case this will create a subshell that will not affect the environment variables of your system and they will be visible only to the subshell process. After finishing the subshell command none of the exports etc. will be applied.
THIS IS A COMMON MISTAKE AND CAUSES A LOT OF DEVELOPERS TO LOOSE A LOT OF TIME.
In order for your changes applied in your script to have effect for the global environment the script has to be run with
.myscript.sh
command.
In order to make sure that you script is not runned in a subshel you can use this function. (Again example is for Ubuntu shell)
#/bin/bash
preventSubshell()
if [[ $_ != $0 ]]
then
echo "Script is being sourced"
else
echo "Script is a subshell - please run the script by invoking . script.sh command";
exit 1;
fi
I hope this clears some of the common misunderstandings! :D
Good Luck!
edited Oct 23 '17 at 16:23
answered Oct 23 '17 at 15:43
twboc
1112
1112
add a comment |Â
add a comment |Â
up vote
0
down vote
The simple solution is to make the terminal a login terminal. For Gnome terminal under 'Tile and Command' of the default profile you can check the box "Run command as a login shell". This article explains the difference between a login shell and one that is not.
add a comment |Â
up vote
0
down vote
The simple solution is to make the terminal a login terminal. For Gnome terminal under 'Tile and Command' of the default profile you can check the box "Run command as a login shell". This article explains the difference between a login shell and one that is not.
add a comment |Â
up vote
0
down vote
up vote
0
down vote
The simple solution is to make the terminal a login terminal. For Gnome terminal under 'Tile and Command' of the default profile you can check the box "Run command as a login shell". This article explains the difference between a login shell and one that is not.
The simple solution is to make the terminal a login terminal. For Gnome terminal under 'Tile and Command' of the default profile you can check the box "Run command as a login shell". This article explains the difference between a login shell and one that is not.
edited May 23 '17 at 12:40
Communityâ¦
1
1
answered Nov 1 '14 at 13:36
driftingprogrammer
11
11
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f88106%2fwhy-doesnt-my-bash-profile-work%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password