Why is it some systems will run a .sh file just by specifying the file name without extension and others require name plus extension? In my case I'm trying to write a series of commands following these instructions.
I'm specifying the extension now but being able to run the commands without .sh would be preferable.
You're confused. The .sh extension is only a hint to humans, and has absolutely NO effect on how the system handles the file. Unix/Linux did not make the Windows' Secrets.pdf.exe blunder.
Here is what happens when you type foo:
Redirection for STDIN, STDOUT and STDERR are set up.
The shell checks its internal hash table to see if it already knows a $PATH entry for foo. If none exists, the shell searches the directories in $PATH, looking for a file called foo that has the Execute bit set in it's file permissions. First foo wins.
If the first two bytes of the file foo are #!, the next string is the name of an interpreter to run. Thus #!/bin/bash introduces a Bash script, #!/usr/bin/perl introduces a Perl script, etc.
If the file starts with \177ELF, it's a binary executable, and ld.so starts it.
Read man execve and man ld.so for a more detailed explanation.
chmod +x) pretty much solves this, right?
– wchargin
Apr 28 '16 at 15:35
x bit on everything) and where the file came from (any process with control of the directory could be tricked into setting the permissions). So, it mitigates it, but I wouldn't say it solves it.
– IMSoP
Apr 28 '16 at 16:39
/bin/sh as the interpreter (see "Sepcial semantics in man 3 exec).
– muru
Apr 29 '16 at 02:59
Secrets.pdf.exe because I always disable the stupid hide file extension feature
– phuclv
Apr 29 '16 at 03:35
Key point is this: Extensions are irrelevant in any Unix-like system system.A filename is just name and has no effect on whether or not script or compiled executable can run. A programmer may add a .sh extension to designate that a file is shell script, or .py for python script, but unlike Windows , any unix doesn't care about naming, it cares about permissions.
What matters is the executable permission granted to a file. Which you can check with
ls -l /path/to/file
To run script there are generally several ways.
./my_script_name . The . means current directory. /home/user/bin/my_script_name(The above two methods rely on having executable permission set ; whether or not file is part of $PATH variable is irrelevant. Presence of #! line also matters; without it, it the script will be executed by the current shell you have open. If I have csh script without that line, and try to run it in bash with ./my_script.csh , it will fail)
$PATH variable, you can run it just by calling the name. You can call chmod command in command line just by typing its name because it's in /bin folder. /bin is always part of $PATH variable. In this case executable permissions and location of the script matter. filename.sh or source filename.sh will make the script be treated as if it was keyboard input, i.e. as if it was typed into command line directly. In this case executable permissions and location don't matterExample #1 , running with interpreter, to exec permissions
$-> ls -l abc.py
-rw-rw-r-- 1 xieerqi xieerqi 44 Apr 27 22:39 abc.py
$-> python abc.py
a
b
c
Example #2, running with ./ executable permission set, shebang line set.
$-> cat abc.py
#!/usr/bin/env python
for letter in 'a' 'b' 'c' :
print letter
$-> ls -l abc.py
-rwxrwxr-x 1 xieerqi xieerqi 66 Apr 27 23:02 abc.py*
$-> ./abc.py
a
b
c
Example #3, running without shebang line set (fails, because bash can't read python scripts ; no shebang line assumes current shell as interpreter )
$-> cat abc.py
for letter in 'a' 'b' 'c' :
print letter
$-> ./abc.py
./abc.py: 2: ./abc.py: Syntax error: word unexpected (expecting "do")
Example #4 , running script that has executable permissions set form folder that is part of $PATH variable
# /home/xieerqi/bin is part of my path variable
$-> echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/opt/microchip/xc16/v1.25/bin:/opt/microchip/xc32/v1.40/bin:/opt/microchip/xc8/v1.35/bin:/home/xieerqi/bin:/home/xieerqi/bin/sh
$-> # current directory is /home/xieerqi
$-> pwd
/home/xieerqi
$-> # move the file to ~/bin
$-> mv ~/abc.py ~/bin/abc.py
$-> # now I can run it just by calling the name
$-> abc.py
/home/xieerqi/bin/abc.py: 2: /home/xieerqi/bin/abc.py: Syntax error: word unexpected (expecting "do")
$-> # Syntax error because again, no interpreter specified.
$-> # must add #!/usr/bin/env python
$-> vi /home/xieerqi/bin/abc.py
$-> # after adding the line with vi text editor, we can run
$-> abc.py
a
b
c
Example #5, removing extension, still runs because extensions don't matter, but it has permissions and is part of $PATH :
$-> mv ~/bin/abc.py ~/bin/abc
$-> abc
a
b
c
PATH ?
– Sergiy Kolodyazhnyy
Apr 28 '16 at 04:43
Good explanations here already. I just wanted to add that ideally you shouldn't use file extensions for executables.
Usually you need to accomplish something relatively easy and you start with a little shell script. Over time you start adding more and more functionality to your script, until it arrives some time that it becomes unmaintainable or you need some functionality that you can't accomplish easily with a shell script and think about rewriting this shell script in another language (python, perl, ... ?).
Rewriting from scratch is usually considered an error, but for scripts it may make sense because usually they are not that large or have lots of functionality. But let's assume that it is feasible to rewrite from scratch in some other language, maintaining the functionality and params/flags of the initial shell script.
Users of this script do not need to be aware of this language change, they will keep executing the same command and it will continue working.
If your script was named do-something.sh, it can continue being do-something.sh, but now it is written in python (for example), and so your initial hint is now a totally misleading one.
To run files without an extension you normaly dont need to do much, just make sure you have (in case of bash scripts) the proper shebang line at the very first line:
#!/bin/bash
then you aswell need tho make the file executable for the system by
chmod 755 yourfilename
This is the same as using chmod +x yourfilename the numbers are easy explained.
It is a number triple of added octals, the first number stands for the user, the second one for the group, and the third one for others, more on that you can find here.
And if you are in the same directory as your script dont forget to use ./ like this:
./yourfilename
The .sh suffix can actually get in the way, because then to run it you have to type myscript.sh instead of just myscript which won't work. Better to just call it "myscript" without the .sh suffix, and a quick use of the "file" command will tell you if it's a binary executable (ELF format on linux) or a shell script, or whatever other kind of script.
QDOS (Quick and Dirty Operating System, later renamed to "DOS" by IBM after mirosoft pirated it and illegally sold it to them) and other cheap ripoffs of CP/M, including windows, mix all of this up because on those systems there's no such thing as execute permissions on files. This has resulted in countless security f'ups in the past 30-40 years. Actually just a few minutes ago i just got several junk mails with a booby trapped zip file renamed to MYPICTURE.JPG.zip :)
.shas an extension is in many circumstances considered bad practice: It's contrary to how other commands are named (you don't runls.elf), it's often misleading (if yourfoo.shstarts with#!/bin/bash, then runningsh foo.shwill run it with a different interpreter than it's built for), and if you rewritefoo.shto be a Python program, using that extension means you need to choose between keeping the now-misleading name and rewriting every program that calls it. – Charles Duffy Apr 28 '16 at 21:39+xset -- wherefoo.shis a library that can be sourced into any POSIX shell,foo.bashcan be sourced into bash,foo.kshinto ksh, etc. – Charles Duffy Apr 28 '16 at 21:39