execute .sh issue
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:
Code:
. file Code:
source file When you do: Code:
/path/to/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. Code:
file 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: Code:
#!/bin/bash Similarly, files starting with Code:
#!/usr/bin/perl 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. |
Quote:
Code:
rw-r--r-- 3 username group 352 Jan 9 2006 script.sh 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. |
All times are GMT -5. The time now is 04:12 PM. |