Hi all,

I just don't get this though.

I have .sh file and when I executed using ./file.sh, it doesn't work; however, if I do . file.sh and it worked just fine.

any suggestions?

It is all about where the file is...

If the path to an executable file is in your $PATH variable, then you simply use <filename>
Otherwise, you have to specify the full path, or go to the directory where the file is

./<filename> means "run the file in the directory where I am now"--ie don't look in the $PATH variable.
"." is Linux-speak for "current directory"

what do you mean by "it doesn't work".

In general you have 2 types of files: executable script (they contains the shebang, are executable and don't have a particular name) and sourced scripts (they are not executable, don't contain a shebang (#!/bin/sh) and by convention end with .sh because there is no way to know how to execute them)
. script will execute the script in the CURRENT shell (meaning exports are done in the current shell and will stay after script end)
./script launches a subshell defined in the shebang line (though bash has exeptions) When you get out of the script, all the environment of the child is lost (exports for example)

man bash, go to section source

thanks for your response,

I was in the directory when I execute the file, all along I have been doing ./file.sh and it worked just fine.


for this file ./file.sh doesn't work and I have to do .<SPACE>file.sh and it worked

why?
thanks

New one on me---what happens if you add the path to $PATH? (or just move the file to one of the directories already in $PATH)

to see what's in $PATH: "echo $PATH"

to change it: "export PATH = "$PATH:<newpathname>" newpathname might be--eg--/home/username/

I agree with nx5000. Just saying "it doesn't work" isn't very helpful. When posting a problem, please specify what you did (you did, in this case), what happened (e.g. error messages) and what you expected instead.

Having said all that, the ./file.sh syntax instructs the kernel to execute a file called "file.sh" located in your current directory. In order for this to work, you have to have "read" and "execute" permission for the file. Also, if the file is a shell script, it should start with "#!/bin/sh". If any of this is incorrect then it will "not work", though with different error messages.

The . file.sh syntax instructs your current shell to read the file and execute the commands in them as if you had typed them yourself. For this to work, you need only "read" permission on the file. A drawback of this approach is that the file can mess up your shell's environment.

So, what have you been doing, what happened, what are the permissions of file.sh, and what is the content of file.sh?

Groetjes,

Kees-Jan

When you do:
or
The contents of that file are read as input to the current interactive shell. Since the file is just being read, the execute permission set does not need to be set - just the read permission.

When you do:
If /path/to/file has the execute permission, Linux will try to execute the file.

Note that ./file is a way to specify "file" in the current working directory ("." is a name for the current directory, like ".." is a name for the parent of the current working directory).

If you don't specify a path, e.g.
...the PATH environment variable is used as a list of directories (: separated) in which to search for "file". If "file" is found in one of these directories and the permissions are set such that the user may execute it, it is executed, else it is ignored and the next directory in the PATH is checked.

For Linux to execute a file, the execute permission must be set. This means the file's permission must be set so the current user can use the execute permission. Note that if the filesystem on which the file resides is mounted with the "noexec" option, it over-rides the file's permissions and you will not be able to execute it.

Assuming the file is executable by the current user, and the filesystem is not mounted with noexec option, Linux will proceed with execution. Linux supports several binary executable formats (depending on how the kernel was compiled). The most common is ELF, although many systems support the a.out format as well.

In addition to these binary formats, Linux will check to see if the file begins with a shabang, "#!". If it does the rest of the line is read and if it is the path to an executable program, that program will be executed and the rerst of the file used as input to that program.

So when you see:
At the start of a file, /bin/bash is executed, and fed the rest of the file as input. What it does with this input is bash's own business.

Similarly, files starting with
Will cause the /usr/bin/perl program to be started and fed the rest of the file as input. What Perl does with the input is Perl's business.

This mechanism is a nice way to add interpreters to the system without requiring users to know what interpreter a given program file is written in - they just execute the file, and Linux figures out what program to interpret the file with. When a script is to be processed in this way it must have the execute and read permission available to the current user.

It does not work because your script file is not executable by you. If you type "ls -l" you will see something like
The characters stand for the permissions of the owner (specified by username), the group and all others. In the above example, the owner has Read and Write permissions, his group and all others have only read rights.
Thus, nobody can execute the script (*). If you want to do that, type chmod u+x script.sh. This will give the owner (u) execute rights (x). Now you can start the script with ./script.sh

type "man chmod" to see the detailed description.

(*)you can, however, source the script by typing ". script.sh". This works just as if you had typed the contents of the file on the command line.