executing shell script without calling sh implicit

Question

I was wondering if it is possible to make a "link" in usr/bin (i.e.) that leads to a shell-script.

But I want just to write

% shellscript

instead of

% sh shellscript.sh

kinda like an alias.

Is this possible?

Answer 1

Yes. You can use ln to create a link to shellscript.sh named shellscript. You will then need to make it executable, but after that (assuming /usr/bin is on your path) you can run it with shellscript.

Answer 2

Make the first line of the script

#!/bin/sh

Then make it executable by typing the command:

chmod +x shellscript.sh

If you now place the script in a bin folder that is on your system's PATH variable and you will be able to run it directly. To see the folders in your path, type:

echo $PATH

I usually use /home/[my username]/bin for scripts that I have written so that they don't interfere with other users on the system. If I want them to be for all users, I use /usr/local/bin which is supplied empty on most distributions.

The .sh on the end of the script's filename is only a convention to help you remember what kind of file it is. It will still work if you rename it to just shellscript, for example, which will complete your requirements.

Answer 3

You can make the shell script executable (chmod +x shellscript.sh). Then you can link to it from /usr/bin (ln -s shellscript.sh /usr/bin/shellscript).

Answer 4

I pondered this question of using filename extensions in Unix/MacOSX and the best answer I can provide is a paste from my development comments in some code I wrote years ago to automate the whole tedious process of updating scripts I write for inclusion into /usr/local/bin.

I have begun to
change how I develop code for my contributions to
/ usr / local / bin. In the past I would always leave the development
file without an extension and depend on the shebang
#!/usr/bin/env ...) line. The flaw with using this approach
exclusively is it does not allow me to utilize the code colorizing
capabilities I have available for programming languages as deftly
as I might. Also allot of development environments do not
understand shebang and so see the code as plain text. Nor are the
contents of files without file extensions accessible via the MacOSX
QuickLook feature...

In short, my automation code (rather to much to post here) 'sudo' inserts an executable extension-less copy of the program in /usr/local/bin but the file in the development directory keeps it's script/program language extension in place. Both copies have the same shebang line at the top of the file. Myriad other repetitive tasks are automated in this automation code as well of course. But the ultimate reward is the 'overhead' associated with the process of writing new 'commands' or tweaking existing /usr/local/bin 'commands' takes a couple keystrokes now.

I remain on Snow Leopard and remain wary of Lion. So if things are different on Lion I apologize for any confusion. Also if your OS doesn't have the equivalent of QuickLook some of what I've said may be lost on you but I think any Linux/Unix user can still benefit from code colorizing via the vim/less (http://www-zeuthen.desy.de/~friebel/unix/less/README) commands.

An example of some of my automated boilerplate colorizing code output that facilitates QuickLooking thru code in the development directory:

/usr/bin/highlight --syntax sh --style neon -i "/Users/pcs/Projects  /Shell/Bash/findpdftext/findpdftext.sh" >| "/Users/pcs/Projects/Shell /Bash/findpdftext/findpdftext.sh.html" 

Generating this boilerplate html costs me nothing and is prettier in QuickLook than the man pages that are auto generated as well. Another little example gob of automated output that goes into the script in the program's development directory which will be run when I'm ready to commit any changes to the script in question to the 'command' copy in /usr/local/bin:

##################################### REWIRE findpdftext.sh: 
chmod 777 "/Users/pcs/Projects/Shell/Bash/findpdftext/findpdftext.sh" 
cp -f "findpdftext.sh" "findpdftext" 
sudo ln -f "findpdftext" /usr/local/bin 
cp -f "findpdftext" "/Users/pcs/man/cat1/findpdftext.1" 

############### SYMBOLIC-LINK-NAMES supplied from command-line: 
##### fpdf is a symbolic link to findpdftext 
sudo ln -s -f "/usr/local/bin/findpdftext" "/usr/local/bin/fpdf" 
cp -f "/usr/local/bin/findpdftext" "/Users/pcs/man/cat1/fpdf.1" 

############### SYMBOLIC-LINK-NAMES supplied from command-line: 
##### fpt is a symbolic link to findpdftext 
sudo ln -s -f "/usr/local/bin/findpdftext" "/usr/local/bin/fpt" 
cp -f "/usr/local/bin/findpdftext" "/Users/pcs/man/cat1/fpt.1" 

In conclusion, for me there are reasons for using both file naming styles.

Answer 5

In addition to making the script executable and linking it into /usr/bin, as others have suggested, you will also want to add the "shebang" line to the top of the script:

#!/bin/sh

# your commands here

This lets you specify which shell interpreter (bash, bourne shell, c-shell, perl, python...) should be used to execute your script.