Scripting - how to write a shell script

Scripting at its simplest is telling the computer what you want it to do by putting the commands you want to use into a file and running that file instead of typing the commands.

For example, lets pretend that every day you log in to your computer and do this:

cd /tmp
ls -l
rm *
df -v

Rather than typing those commands over and over every day, you could stuff them into a file and just tell the computer to look in the file to find the commands you want to run. But how do you do that?

It's actually not hard but, as usual, there are lots of different ways to accomplish the same thing. Here's the 20,000 foot view:

To create and run a script, you need to:

  • Get your text (commands) into a file.
  • Make that file executable
  • Tell the computer to run it

Three simple tasks, but lots of choices for each. I'm going to cover each step in detail.

Get your commands into a file

If you know VI or some other editor, you know how to do the first part already. If your GUI Desktop is up and running, you can use the text editor there. You can even use Windows Notepad if you have to (but read on to find out how to transfer from Windows to Unix).

If someone else has written the script, you can cut and paste from a web page right into a GUI editor. Again, if you are using Windows, you could paste right into Notepad. If you are using Windows, don't use Word or any other editor except Notepad unless you understand how to do a Save-As to create plain ASCII text.

If your typing is good, you could even just do (this is Unix, not Windows):

cat > myscript
you type your commands here
pressing ENTER after each line
and finally ending with a
CTRL-D on a line by itself.

You can save the file as any name you want, but don't use "test" or the name of any program that already exists in Unix. There's no danger to your system if you accidentally do use a name that already exists (unless, of course, you actually over wrote the Unix file that is the command), but having a unique name (like "myscsript") makes it easier to use and less confusing.

If you've created the file in Windows, you need to get it to Unix. There's lots of ways to do that: see Data Transfer for some ideas, but keep in mind that (depending on how you transfer it) you may need to use another program to convert it to Unix text format. The problem is that Windows and DOS stick in extra characters (a CTRL-M) at the end of each line. You need to get rid of them. SCO has the "dtox" command, Linux has "mcopy". For example, lets say you transferred "myscript.txt" from Windows to a SCO machine. You'd do:

dtox myscript.txt > myscript

to fix it.

J.P. Radley wrote a clever little "sed" script he calls "cr++" that works in either direction. It contains control characters, so you'd need to type it in rather than cut and paste it, but here it is:

# J.P. Radley's "cr++" script
# if using vi to create this, type CTRL-V CTRL-M where you see ^M below
# note the single ' (quote ) characters: those are NOT ` (back quotes)
: cr+-
        # adds CRs if not present, strips them if present
        # note: if you just cat this file, you miss its essence
        # if you cat -v this file, you see the _real_ ^Ms in it
        sed '

If you are just starting with Unix and scripting, you might want to ignore this script for now and come back to it later.

Make the file executable

The easiest thing to do is:

chmod 755 myscript

Actually, you don't really have to do that, though it does make things easier. For example, if you have "myscript" in /tmp, you could just run it from there by doing:

sh /tmp/myscript

but making it executable is easier. The "755" makes it executable by anyone; if you don't want other people to be able to use your script, do:

chmod 700 myscript

That's easy, isn't it?

Telling the computer to run it

This is the easiest of all. Again, let's say you put this in /tmp and called it "myscript". All you have to do is type:


(but it has to be executable; see above).

If you have "myscript" in your current directory, you may be able to type just "myscript". If that doesn't work, you'll need to use "./myscript".

If you want to be able to run it just by typing "myscript" no matter where you are, you have to put it somewhere in your PATH. What's your PATH? It's the list of directories that your system looks in to find programs. To see your PATH, type:

echo $PATH

You'll get something that looks like this (your output may be different):


That means that if I type "myscript", the system will lokk in /bin to try to find it. If it is not there, it will look in /etc amd then in /usr/bin and so on. So, if you want to just type "myscript" and have it work, you need to copy it to someplace in your PATH.

WATCH OUT! If your script is called "ls" for example, and you copy it to /bin, you'll destroy the system's own "ls" command- probably not a good idea. That's why most of us stick our own commands somewhere "safe", like /usr/local/bin.

But what if /usr/local/bin isn't in your PATH? Well, you need to get it there by editing your login files. For example, my .profile contains this line:


If I want to add a new directory to that, I can.

Note that /usr/bin isn't always the greatest place to put stuff either, especially on SCO systems. See Use and abuse of /usr/local/bin for more on that.

There's more to scripting than this, of course. There's the magic hash bang (#!) that you may see as the top line of some scripts. That's just something that tells the computer what program to use to run the script: shell scripts aren't the only kind of scripts there are. See Why can't I run this program?

If you want your script to run whenever the computer starts or whenever you login, see Automating Program Startup.

If you are just getting started, that's probably all you need to know for the moment. There's also the programming of shell scripts; the for loops, the tests, and so on. As you start to read and use other people's scripts, you'll understand more, or there are good books that will teach you all about that. Here are just a couple:

A final word: When using other people's scripts, try to understand what they do BEFORE you use them. Sometimes, improper use (especially if you are logged in as "root") can cause serious damage to your system. If you feel you don't understand, seek professional advice before proceeding.

Got something to add? Send me email.


Increase ad revenue 50-250% with Ezoic

More Articles by

Find me on Google+

© Tony Lawrence

Mon Sep 28 14:40:57 2009: 6988   Mark

Good beginners overview.

Since this is geared to beginners it might be worth pointing out something about unix shell script variants. There are several different types of shell scripts with the most common being bash - at least on modern Linux systems. There is also cshell(csh), Korn shell(ksh), Bourne shell(bsh), and others. When I was starting off in Unix, with nothing other than a few C-programming courses under my belt, I was asked what shell I wanted to use for my login shell. Not knowing any better, I figure C-shell since it's programming constructs were supposed to be similar to C. Fortunately wiser heads prevaled and moved me to Korn shell.

My point is that if you are writing a shell script, Cshell is a (link) poor choice.

I would advise a modern user, particularly on Linux, to go with the bash shell for shell scripting and a higher level language like perl, php, or python for tasks too complex to handle reasonably in a shell script. My guidelines for choosing a language is that I go with shell if I am largely just running unix commands with some decision involved(if, else, while) and I go with perl if I have a lot of complex string manipulation or need more full featured data structures like arrays, hashes, or need database communication.

I might also mention to a beginner that if they leave out the shebang (#!/bin/bash), the script will run under their current shell - whatever that is.

Mon Sep 28 14:46:24 2009: 6989   TonyLawrence


Csh and its clones are used by two kinds of people:
those who were unfortunate enough to have been exposed to it
early on and just don't want to make the effort to learn something
else (and who can blame them?) and wannabees who have the very mistaken
impression that it's "cool".

It ain't cool: it's clumsy, broken,
and a major pita. The historical rationale was that it was good
for users because of its history ability, which sh lacked. Other
than that, it was (and is) an inferior shell. Since bash and ksh
have more than adequate history AND retain and expand the superior
scripting of sh, anyone not hopelessly habituated to csh semantics
should use one of those.

Apple stupidly chose tcsh as their default shell when OS X first came out. Fortunately they quickly changed that to Bash.

Kerio Samepage

Have you tried Searching this site?

Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

I wanted to learn how to swim, so Google showed me how to turn on the water at the sink and let me splash it around a bit. They then dragged me into a helicopter, flew way out into the ocean and dumped me out. (Tony Lawrence)

This post tagged: