Difference between ./foo, . foo and source foo?

stf92 · 04-25-2014, 03:17 AM

Hi: I can run a shell script in either of three ways. Let the name of the script be foo:

1) ./foo or just foo if . is in the PATH.
2) . foo
3) source foo

What is the difference between these invocations?

kaz2100 · 04-25-2014, 06:16 AM

Hya

I am a tcsh user. 2) does not work.

cheers

kaz2100 · 04-25-2014, 06:20 AM

Hya

I am a tcsh user.

A bash script can go with situation 1), but not situation 3).

cheers

pan64 · 04-25-2014, 07:19 AM

2 and 3 are the same, it means the program will be executed by the current shell. Tcsh cannot understand 2) some other shells cannot understand 3).
1 means a new shell will be opened (child process) and that will execute foo.

The main difference is that using method 1 you can execute a script but your current shell will remain as it was before, using 2 or 3 you will be able to modify your actual environment (define functions, set variables ...)

theNbomr · 04-25-2014, 09:55 AM

The '.' notation in bash is just shorthand for 'source'. To 'source' a file is causing the current shell process to read it in mostly the same manner as if you had typed it interactively. This allows you to use that method when you need to alter the properties of the current shell session, such as changing directories or setting environment variables. When a script is 'run', as your "1)" method describes, it launches a child shell which executes the script, and then terminates. Any alteration of process properties is restricted to that child shell. Since the child shell terminates when the script completes execution, those changes vanish with it. Moreover, the child shell (like any process) is incapable of altering the properties of any other process, be it a parent, child or sibling.

stf92 · 04-25-2014, 07:55 PM

Aha... When I have just installed an O.S. I must afterwards do some settings and install some software. For instance, one thing I do, is to install two programs: autojump and ytree. To save work, I could write a script like this:

Code:

#!/bin/sh
## Linked to /bin/bash in my system.

### Pseudocode - I don't know how this is done
if ~/work does not exist
  mkdir ~/work
### Pseudocode END

cp /deb4/almacen/soft/ncd/autojump-v8.tar.gz ~/work
cp /deb4/almacen/soft/ncd/ytree-1.94.tar.gz ~/work
cd ~/work
gzip -dv autojump-v8.tar.gz
gzip -dv ytree-1.94.tar.gz
tar -xvf autojump-v8.tar
tar -xvf ytree-1.94.tar

cd joelthelion-autojump-ea68448
./install.sh

# Here I just edit ~/.bashrc and /root/.bashrc 
# when working interactively. So here I do:
echo "source /etc/profile.d/autojump.bash" >> ~/.bashrc
echo "source /etc/profile.d/autojump.bash" >> /root/.bashrc

cd ~/work/ytree-1.94
make
make install

According to what has been said, it would be exactly the same if I source this script or I directly run it (methods 3) and 1) above). Am I right?

suicidaleggroll · 04-25-2014, 10:23 PM

Yes you could use methods 1, 2, or 3 with that.

I rarely put build commands in scripts though, and I recommend against it as well. Unless you are positive your system is set up properly (all necessary dependencies), it could easily fail. The problem with scripts is, if a command fails, the script just keeps on going. For example, if your "make" fails because of a missing dependency, the script doesn't give a crap and goes straight to "make install". You should really be putting in some error checking if you want this to be a reliable tool.

pan64 · 04-26-2014, 01:04 AM

yes, you are right. In that case method 1 is preferred. (actually if you are not sure about that you ought to choose the first one).

see mkdir -p about your pseudo code
tar can handle zip files, you do not need gzip but tar xvzf