I am writing a bash script to attempt to automate initial setup on Ubuntu, and I have run into an issue I do not understand. If I run the following code:

sudo apt-get -y update && sudo apt-get -y upgrade
sudo apt-get -y install curl git-core build-essential openssl sqlite3 apache2-prefork-dev mysql-client
git clone git://github.com/sstephenson/rbenv.git ~/.rbenv
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(rbenv init -)"' >> ~/.bashrc
source ~/.bashrc
git clone git://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build
rbenv install -v 1.9.3-p392

then the script finishes, but most of the commands fail, as rbenv is undefined (tested after script finishes with rbenv -v). If I then run source ~/.bashrc, rbenv becomes defined.

However, if I run the exact same code but replace source ~/.bashrc with source /home/username/.bashrc, then rbenv is defined and the script completes without problems. Can someone explain this discrepancy? Understanding when and why relative pathing doesn't work I suspect will be very useful in the future.

  • Debian (and presumably Ubuntu too) has a native "automated install" system (I'n not too familiar with either, so I can't give more details). Use that, instead of cooking up something yourself. – vonbrand Apr 11 '13 at 15:05
  • While FAI does look interesting (I'm assuming that's the "automated install" system you were talking about), it's beyond what I'm working on. Thanks for the tip though, may use in the future. Now if I can get this issue with source understood... – IanL Apr 11 '13 at 16:10

You don't really need the "$(rbenv init -)" invocation during your initial setup. That part helps later, when using rbenv in interactive environments and may add some opacity when debugging a script.

Try adding before the actual rbenv invocation:

export PATH="$HOME/.rbenv/bin:$PATH"

In fact, to use rbenv in scripts it's enough adding that one and the shims directories to your path.

As for the the 'source' failing, source is a bashism. If you are assuming bash is the default shell and using #!/bin/sh as hashbang, then ubuntu can be playing some tricks on you (defaults to dash IIRC).

| improve this answer | |

~ and $HOME should always refer to the same path, so I'd expect that something else was missed.

Possible problems:

  • Are you running this script with sudo? If so, $HOME may be root's home.
  • Is $HOME not /home/username/ ? While /home/username is the standard path for your home directory, it can be configured other ways. Try echo $HOME to verify.

To get a better idea of what's going on:

  • Throw in a line
    set -ex
    at the top. The -e makes it exit on the first failure, and the -x makes it print what's going on as it executes.
  • Add
    echo "$(env)"
    at the top to get it to print out the environment, or if you have set -x or set -ex above, simply add
| improve this answer | |
  • The script isn't being run with sudo, and echo $HOME confirms /home/ubuntu. I may have try to run with ~, $HOME, and /home/username all on fresh instances, see what happens. – IanL Apr 12 '13 at 14:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.