Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have written a simple script. When I runsh <>, i got the correct output, but when I run ./<>, I got an error.

What is difference between when I do sh and ./?

share|improve this question
Instead of just saying, "I get an error", it would help if you pasted in what the error said. – SpashHit Jan 23 '11 at 20:35
up vote 53 down vote accepted

When you run any script by passing the filename to the script interpreter program, you are running the interpreter program with the script as an argument passed into it. For example this would look like the process 'sh' with the argument ''. The sh interpreter is opening the file.

On the other hand if you run the script itself, the system calls out to the interpreter program specified and feeds in the scripts contents. In this case the process looks like '' with no arguments.

You should make sure you have a bang line:

# bash script here

A bang line is the very first line in the script and starts with the same two characters #!, these are what the system reads when it tries to execute the script and then the system passes the the script to the program immediately after. Note that this line isn't anything to do with bash and works just as well for python and perl, even though they're very different languages. You would use #!/usr/bin/python for example and then follow it with python code.

Once you have your script, make sure you have set execute permissions:

chmod a+x

Then you can run the script as its own process:


Or put the file into a known location with a nice program name, like /usr/sbin and run from anywhere:

sudo cp /usr/sbin/program-name

And this is really the practical benefit of using the bang line with the right permissions - it's all about deployment. It's very hard to get users to run a script if they have to remember what program to run the script with. Remember to give a full path to the script every time they want to run it. Where as putting it in /usr/local/bin for example, and making it executable, can save an awful lot of grief for people trying to use your script. These programs then become available to all users on the your computer.

It's also good for identification. If you go into the top program, a script run without the bang line will just have the name of the interpreter i.e. bash, perl or python. But if a script is run with the right permissions, then the name of the script shows.

Note: If you want to distribute a script that's accessible to everyone, then please create a man page and a deb package to install it. We need to reduce the number of random scripts online and increase the number of debs which can be uninstalled.

share|improve this answer
You can also use a personal bin folder: create a bin folder to your home folder log out and log in back and you should then be able run any scripts in that folder without sh or ./ . – papukaija Jan 23 '11 at 16:46
Of course, but adding your home folder to your PATH can be seen to be a bit of a headache. Better get things installed. Although there was some talk of adding ~/.local/bin to the path by default to allow local user installs of packages. – Martin Owens -doctormo- Jan 23 '11 at 17:28
Note that the default interpreter is bash, not sh. – Nathan Osman Jan 24 '11 at 2:13
Don't put extensions on scripts, especially not when you put it in PATH. – geirha Jan 24 '11 at 7:46
For a noob like me... could you explain the PRACTICAL differences between both situations? In other words.... what can I do with one method that I can't with the other, and vice versa? – luri Jan 24 '11 at 9:03

The short version:

  • sh is the command line interpreter (dash).
    Running sh my_script makes dash interpret the script.

  • ./ tries to find out which interpreter to use, by looking at the first line. E.g. #!/bin/bash, or even #!/bin/ruby (as oppsed to running ruby my_script).

share|improve this answer
It's not really ./ which finds anything, it's the system execution method which looks at the first two bytes of the file. – Martin Owens -doctormo- Jan 23 '11 at 16:08
Absolutely. Here's a very long explanation of it all. I'm being pragmatic :) – Stefano Palazzo Jan 23 '11 at 16:18
+1 for dash reference and pragmatic concision. – belacqua Jan 23 '11 at 22:42

There are three main reasons you might be getting an error:

  • the file is not executable
    run chmod +x <> to fix that
  • the partition does not allow running scripts (is mounted "noexec")
    copy the script to /usr/local/bin
  • the #! line has an error
    make sure the first line is #!/bin/sh or #!/bin/bash

If your first line looks right, but still isn't working, make sure the file doesn't have DOS line endings.

The error would look something like this:

$ ./
bash: ./ /bin/bash^M: bad interpreter: No such file or directory

You can fix it by running dos2unix <>, or if you don't have that,
perl -p -i -e 's/\r\n$/\n/' <>.

share|improve this answer

The difference you do is,

  • with sh, you're running a program that will interpret the lines in your script just as it you would have typed them on the interactive prompt of the terminal,

  • with ./ you're making a shortcut assuming that the script is just right here in the current directory you're sitting in AND it will be executable (because for instance you issued chmod +x, saving you invaluable time for future times :-)

share|improve this answer
+1 for being the only one to concisely state that the file must be executable. – Mikel Feb 3 '11 at 22:04

And the answer is that sh is name for very popular shell. But outdated and replaced by others. Nowadays sh is linked to others shells installed on machine. e.g. I have bash putted there. Running any shell from sh usually trigger some 'compatibility' mode with original 'shell' behavior.

So solution is quite simple. Look what's behind sh command (ls -al /bin/sh), and put #!/bin/whatever_you_find_there as first line (or if there is something like that in your script edit it).

And alternatively there may be some bug in script itself. Like dependence that is met by sh, but not interpreter that is actually used.

share|improve this answer
mkdir ~/bin ; cp ~/bin/

echo "export PATH="$PATH:/home/$USER/bin" >> ~/.profile ; source ~/.profile ; 

Not /usr/sbin, that's for non-essential administrative tools, /usr/local/bin is a better choice if you don't want to have a ~/bin/, but avoiding sudo as much as possible is advisable.

share|improve this answer
On Ubuntu, the default ~/.profile already has code for adding ~/bin, if it exists, to PATH. On another note, don't put extensions on scripts. – geirha Jan 24 '11 at 7:44
I was referencing the <>, but what is the rationale for not putting extensions on scripts? I usually do because having the plain text files visible like that keeps me from trying to edit binaries that I also keep in ~/bin/. (ls ~/bin/|wc -l = 428) I put a lot of stuff in there ;) – Joey1978 Jan 24 '11 at 8:01
Imagine you write a script to achieve a specific task. Then you realize writing this particular script in python will make it much more efficient, so you rewrite it in python. Now you have two choices. 1) Leave the now very misleading .sh-extension, or 2) rename the script and search and replace all uses of the script to use the new name. If you look at the scripts in /bin and /usr/bin you'll see they don't use extensions. – geirha Feb 2 '11 at 8:49

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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