1

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.

2
  • 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, 2013 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, 2013 at 16:10

2 Answers 2

1

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

0

~ 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
    env
1
  • 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, 2013 at 14:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .