13

Are there any actual differences between running a script with

[sudo] sh ./<script>.run

instead of

[sudo] chmod +x ./<script>.run
[sudo] ./<script>.run

5 Answers 5

18

If you use

sh ./<script>.run

/bin/sh (usually a Bourne shell) will used to run the script. Of course this only works if the script is written for Bourne shell. Sometimes shell scripts for Linux require Bash instead of Bourne shell, so this may not work even if it is a shell script.

If you use

./<script>.run

the kernel looks at the shebang line to find out which program to use to run the program. So this works even if it is a Bash, Perl, Python or some other script.

Thus this is usually the preferred way to run a script.

1
  • 1
    As I said in olis answer: I checked the executable I run the shebang its /bin/sh so its probably fine, ill wait and see if anyone has any other info and then accept an answer
    – user36976
    Jun 23, 2014 at 9:55
7

As long as it's a sh (Dash, or equivalent) shell script, no, there's no outward difference.

The problem is .run doesn't guarantee that's the case. It could be binary. It could be Bash or Python or PHP or whatever; they all have a shell script hash-bang. If you blindly force it through sh, who knows what could happen. It'll probably error-out but it could accidentally run harmful code before getting that far.

By chmodding it (to enable the execution permission bit) and then running it ./script.run, you give it the best possible possibility of running. If it's a shell script, its hash-bang will be parsed properly and if it's a binary executable, it'll just run natively.

1
  • Ah didnt know that thanks for the answer, just checked the executable I run the hash-bang is /bin/sh so I think its fine
    – user36976
    Jun 23, 2014 at 9:41
1

The two methods can often act the same but are very different.

sh ./script runs the sh command with an argument ./script, which happens to execute the given script.. even if the script is not actually a sh script (bad)

./script executes the given file. It does this by looking for the "shebang" line to determine what command to run. If unspecified it uses sh (this the two methods act the same sometimes), but often a different interpreter is specified..

For example, if filename contains the following:

#!/usr/bin/python

print "This is a Python script!"

..then the two commands are very different:

$ sh script
script: line 3: print: command not found
$ chmod +x script
$ ./script
This is a Python script!

If there is no shebang line, the two are the same:

$ cat script
echo "This is an sh script"
$ sh ./script
This is an sh script
$ ./script
This is an sh script
1

One important difference is if your hashbang line has parameters. For example, if the script starts with

#!/bin/bash -e

...and you run it externally using sh or bash, that line will be interpreted as a comment and ignored, so the -e parameter (exit on failure) won't be processed. So, given the following script:

#!/bin/bash -e
echo Hello
false
echo goodbye

The output for ./script will be just "Hello", but the output for sh script will be Hello followed by goodbye, which was probably not intended.

This, by the way, is why you should always use a separate set -e statement (it's a good idea anyway - more often than not, if there's a problem mid-script, you wouldn't want it to be ignored).

0

No

[sudo] chmod +x ./<scrupt>.run makes the script executable so you can run it with ./<script>.run.
With [sudo] sh ./<script>.run you can run it, even if it is not executable.

0

You must log in to answer this question.

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