Return to Answer

It depends on the content of the shell script and the used shell. A shell script might contain boilerplate code, called a shebang, like the following:

#!/usr/bin/env bash 

The special sequence '#!' instructs the exec() kernel system call to use the program defined right after it as the interpreter. This means that you'll have to look into the file to see what program will be used to execute it if you're using your second style of execution.

Also, from the bash manual (bash -c "help set")

-x Print commands and their arguments as they are executed. 

What your command should be doing - if you are using bash, see note below - is print out each line in your script and execute it. Oddly, this should cause your first command to be slower than the second, instead of the other way around (again: if the interpreter used in both cases is the same). It is much more common to run the shell without the -x, unless, of course, you want to do debugging.

Bottom line: for reasons described here use the shebang with the env program in (as recommended here) and use your second style of execution. This is the most platform independent way of doing things and is the preferred way.

Note: Another thing that complicates things is that the actual interpreter that is behind /bin/sh varies from system to system. In many cases this is actually bash and this is what I have assumed.

It depends on the content of the shell script and the used shell. A shell script might contain boilerplate code, called a shebang, like the following:

#!/usr/bin/env bash 

The special sequence '#!' instructs the exec() kernel system call to use the program defined right after it as the interpreter. This means that you'll have to look into the file to see what program will be used to execute it if you're using your second style of execution.

Also, from the bash manual (bash -c "help set")

-x Print commands and their arguments as they are executed. 

What your command should be doing - if you are using bash, see note below - is print out each line in your script and execute it. Oddly, this should cause your first command to be slower than the second, instead of the other way around (again: if the interpreter used in both cases is the same). It is much more common to run the shell without the -x, unless, of course, you want to do debugging.

Bottom line: for reasons described here use the shebang with the env program in (as recommended here) and use your second style of execution. This is the most platform independent way of doing things and is the preferred way.

Note: Another thing that complicates things is that the actual interpreter that is behind /bin/sh varies from system to system. In many cases this is actually bash and this is what I have assumed.

It depends on the content of the shell script and the used shell. A shell script might contain boilerplate code, called a shebang, like the following:

#!/usr/bin/env bash 

The special sequence '#!' instructs the exec() kernel system call to use the program defined right after it as the interpreter. This means that you'll have to look into the file to see what program will be used to execute it if you're using your second style of execution.

Also, from the bash manual (bash -c "help set")

-x Print commands and their arguments as they are executed. 

What your command should be doing - if you are using bash, see note below - is print out each line in your script and execute it. Oddly, this should cause your first command to be slower than the second, instead of the other way around (again: if the interpreter used in both cases is the same). It is much more common to run the shell without the -x, unless, of course, you want to do debugging.

Bottom line: for reasons described here use the shebang with the env program in (as recommended here) and use your second style of execution. This is the most platform independent way of doing things and is the preferred way.

Note: Another thing that complicates things is that the actual interpreter that is behind /bin/sh varies from system to system. In many cases this is actually bash and this is what I have assumed.

It depends on the content of the shell script and the used shell. A shell script might contain boilerplate code, called a shebang, like the following:

#!/usr/bin/env bash 

The special sequence '#!' instructs the exec() kernel system call to use the program defined right after it as the interpreter. This means that you'll have to look into the file to see what program will be used to execute it if you're using your second style of execution.

Also, from the bash manual (bash -c "help set")

-x Print commands and their arguments as they are executed. 

What your command should be doing - if you are using bash, see note below - is print out each line in your script and execute it. Oddly, this should cause your first command to be slower than the second, instead of the other way around (again: if the interpreter used in both cases is the same). It is much more common to run the shell without the -x, unless, of course, you want to do debugging.

Bottom line: for reasons described here use the shebang with the env program in (as recommended here) and use your second style of execution. This is the most platform independent way of doing things and is the preferred way.

Note: Another thing that complicates things is that the actual interpreter that is behind /bin/sh varies from system to system. In many cases this is actually bash and this is what I have assumed.

It depends on the content of the shell script and the used shell. A shell script might contain boilerplate code, called a shebang, like the following:

#!/bin/bash 

The special sequence '#!' instructs the exec() kernel system call to use the program defined right after it as the interpreter. This means that you'll have to look into the file to see what program will be used to execute it if you're using your second style of execution.

Also, from the bash manual (bash -c "help set")

-x Print commands and their arguments as they are executed. 

What your command should be doing - if you are using bash, see note below - is print out each line in your script and execute it. Oddly, this should cause your first command to be slower than the second, instead of the other way around (again: if the interpreter used in both cases is the same).

  It is much more common to run the shell without the -x, unless, of course, you want to do debugging.

Note: Another thing that complicates things is that the actual interpreter that is behind /bin/sh varies from system to system. In many cases this is actually bash and this is what I have assumed.

It depends on the content of the shell script and the used shell. A shell script might contain boilerplate code, called a shebang, like the following:

#!/usr/bin/env bash 

The special sequence '#!' instructs the exec() kernel system call to use the program defined right after it as the interpreter. This means that you'll have to look into the file to see what program will be used to execute it if you're using your second style of execution.

Also, from the bash manual (bash -c "help set")

-x Print commands and their arguments as they are executed. 

What your command should be doing - if you are using bash, see note below - is print out each line in your script and execute it. Oddly, this should cause your first command to be slower than the second, instead of the other way around (again: if the interpreter used in both cases is the same). It is much more common to run the shell without the -x, unless, of course, you want to do debugging.

Bottom line: for reasons described here use the shebang with the env program in (as recommended here) and use your second style of execution. This is the most platform independent way of doing things and is the preferred way.

Note: Another thing that complicates things is that the actual interpreter that is behind /bin/sh varies from system to system. In many cases this is actually bash and this is what I have assumed.