Every time I log into my VPS I must run source ~/.bashrc before I can run any rvm, ruby, or gem commands.
Why is this? Can't make it load by default?
ssh deployer#xxx
ruby -v
-bash: ruby: command not found
source ~/.bashrc
ruby -v
ruby 1.9.3p429 (2013-05-15 revision 40747) [i686-linux]
I installed rvm under deployer.
I have ~/.bash_pofile which is empty. I also have ~/.profile which has the following in it:
if [ -n "$BASH_VERSION" ]; then
# include .bashrc if it exists
if [ -f "$HOME/.bashrc" ]; then
. "$HOME/.bashrc"
fi
fi
# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
PATH="$HOME/bin:$PATH"
fi
My ~/.bashrc has this at the top:
[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm"
From the bash man page:
When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable.
So in your case, the (empty) ~/.bash_profile is being executed, and your ~/.profile (and thus your ~/.bashrc) are ignored. To solve this, you'll either need to delete your ~/.bash_profile, or else move the contents of ~/.profile into ~/.bash_profile.
When you log in, if Bash can find a file named .bash_profile in your home directory it will execute it and do not even search for a .profile file. Thus you have two choices, either remove the empty .bash_profile file or copy the contents of .profile to .bash_profile.
Moving the information from .bashrc to the other files, as suggested by others is one way to do it.
Otherwise, this snippet of code will do the same thing, without needing to move the contents, or remove the file. Depending on the ways you have things set up, you may not want to delete a file, if it has relevant information in it for other tasks, other than interactive login.
# if running bash
if [ -n "$BASH_VERSION" ]; then
# include .bashrc if it exists
if [ -f "$HOME/.bashrc" ]; then
. "$HOME/.bashrc"
fi
fi
Though using the files as they are intended to be used by reading the documentation can definitely alleviate some frustration.
Related
I have tried using this code in both .bashrc and .bash_profile:
if [ -f /etc/bashrc ]; then
. /etc/bashrc
fi
export TMPDIR=/tmp
export SUBJECTS_DIR=/mindhive/nklab3/projects/ellison_on_nklab3/zfMRI
but when I write echo $SUBJECTS_DIR in the terminal, it returns a completely different filepath.
I have done source .bashrc, source .bash_profile, and restarted my ssh login, but none of these have changed anything, echo just continues giving the wrong directory. I have also tried writing the SUBJECTS_DIR filepath in quotes, writing it with :$SUBJECTS_DIR at the end, and a bunch of other configurations that I've found from looking around on the internet for ages to find what the problem might be, but no way of writing it has changed anything so far either. What do I do?
/etc/bashrc is supposed to be source'd by /etc/profile or autoloaded by bash depending on how Bash was built by the distro. I think what you want to do is this; placed in ~/.bash_profile:
if [[ -f ~/.bashrc ]]; then
. ~/.bashrc
fi
export TMPDIR=/tmp
export SUBJECTS_DIR=/mindhive/nklab3/projects/ellison_on_nklab3/zfMRI
Read Bash Startup Files.
I read this page from the bash reference manual, which tells me that bash reads /etc/profile then my home directory. I wasn't able to find an environment variable to tell bash to read some subdirectory, ie ~/.bash.d. I suspect that I need to put some line in /etc/profile along the lines of:
BASHENVIRONMENTVARIABLE="~/.bash.d"
ie. for zsh that variable is ZDOTDIR.
/etc/profile has the following description:
if [ -d /etc/profile.d ]; then
for i in /etc/profile.d/*.sh; do
if [ -r $i ]; then
. $i
fi
done
unset i
fi
How about writing a script to read files under ~/.bash.d as same as this?
if [ -d ~/.bash.d ]; then
for i in ~/.bash.d/*; do
if [ -r $i ]; then
. $i
fi
done
unset i
fi
Or maybe you can do it with eval command.
eval $(cat ~/.bash.d/*)
The startup scripts (~/.bashrc, ~/.bash_profile, ~/.bash_login, etc) are all expected to be located in the home folder.
To source the startup from a different folder, simply add a source (or .) command to the "official", and place all the setting in the desired location (~/.bash.d)
# This is ~/.bashrc
source ~/.bash.d/.bashrc
# This is ~/.bash_login
source ~/.bash.d/.bash_login
Note that the 'BASH_ENV' will usually include absolute path, to allow it to work regardless of the directory where bash in invoked.
I have a bash script where at some point, I want to source the ${HOME}/.profile file which should add ${HOME}/.local/bin to the $PATH. But when I check the path with echo $PATH, ${HOME}/.local/bin is absent as if the source did not happen. What am I doing wrong?
if command -v pip3 &>/dev/null; then
echo "Pip is already installed."
else
echo "Pip is not installed. Installing Pip..."
cd ${HOME}/Downloads
curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py
su -c "python3 get-pip.py --user" "$SUDO_USER"
cat <<-'EOT' >> "${HOME}/.profile"
# set PATH so it includes user's private .local/bin if it exists
if [ -d "$HOME/.local/bin" ] ; then
PATH="$HOME/.local/bin:$PATH"
fi
EOT
source "${HOME}/.profile" #this is not happening!!!
rm ${HOME}/Downloads/get-pip.py
echo "Pip has been installed."
fi
Thanks in advance.
EDIT: Fixed the script syntax as suggest by Kusalananda.
A script can't modify the environment of the shell from whence it was executed.
Sourcing ~/.profile in the script will not set the path in the interactive shell that originally started the script. To do that, you would have to source your script.
Also, your here-document would need to be quoted, or the current values of HOME and PATH would be inserted into the .profile file:
cat <<'PROFILE_END' >> "$HOME/.profile"
# set PATH so it includes user's private .local/bin if it exists
if [ -d "$HOME/.local/bin" ] ; then
PATH="$HOME/.local/bin:$PATH"
fi
PROFILE_END
Also note that if the user is a bash user with an existing ~/.bash_profile file, then the ~/.profile file will be ignored for that user when a new login shell is started.
I'm further unsure why you su to $USER. It seems like an unnecessary step.
I am trying to extend my bash history size from 1000 commands to 10000 commands.
I am trying to follow this tutorial to extend my bash history from 1000 commands to 10000. In the first paragraph, it says to append the following three lines to my 'bash init.'
export HISTCONTROL=erasedups
export HISTSIZE=10000
shopt -s histappend
Google lead me to the bash beginner guide and I can't read it, since Bash isn't my first language. I think the following excerpt answers my question, but I'm not sure.
When invoked interactively with the --login option or when invoked as sh, Bash reads the /etc/profile instructions. These usually set the shell variables PATH, USER, MAIL, HOSTNAME and HISTSIZE.
Questions I have:
Am I reading this right when I assume that /etc/profile is the same as a bash initialize?
How can I test if this worked? /etc/profile currently looks like this:
export HISTSIZE=10000
shopt -s histappend
# System-wide .profile for sh(1)
if [ -x /usr/libexec/path_helper ]; then
eval `/usr/libexec/path_helper -s`
fi
if [ "${BASH-no}" != "no" ]; then
[ -r /etc/bashrc ] && . /etc/bashrc
fi
Update: putting those commands in the bashrc didn't seem to do anything, but following this add timestamps to bash history tutorial, I put the commands in /etc/bashrc . My history now has timestamps. Is it safe to assume that .bash_history now saves 100000 commands as well?
Bash may read several different files. Since these are bash specific options that don't work for sh, you should put them in ~/.bashrc and make sure you have a line source ~/.bashrc in ~/.bash_profile.
You can test it by opening a new terminal and running echo $HISTCONTROL and shopt histappend to see whether they have the expected values ("erasedups" and "on").
What startup scripts—in the order that they are called—set the PATH variable when opening a BASH shell in Terminal.app on OS X?
I've found the culprit. The secret sauce was /usr/libexec/path_helper it looks in the file /etc/paths and in the directory /etc/paths.d/.
First bash sources /etc/profile which executes the following code:
if [ -x /usr/libexec/path_helper ]; then
eval `/usr/libexec/path_helper -s`
# The above line is the secret sauce, so to say...
# First is adds default PATH values from the file /etc/paths
# Then all files in the /etc/paths.d/ directory are read and directories listed
# in each file (one per line) are appended to PATH
fi
if [ "${BASH-no}" != "no" ]; then
[ -r /etc/bashrc ] && . /etc/bashrc
fi
Next bash looks for ~/.bash_profile, ~/.bash_login, and ~/.profile.
Listing these steps out, PATH is built as follows:
Directories in the file /etc/paths are added to PATH
Directories listed in the files in the directory /etc/paths.d/ are appended to PATH — Note, that these are appended versus being prepended.
Various PATH={DIR_2_ADD}:"${PATH}" statements in my ~/.bash_profile and ~/.bashrc files are prepend PATH