Shell script
This article needs additional citations for verification. (February 2014) |
A shell script is a
The term is also used more generally to mean the automated mode of running an operating system shell; each operating system uses a particular name for these functions including batch files (MSDos-Win95 stream,
Shells commonly present in Unix and Unix-like systems include the
Capabilities
Comments
Comments are ignored by the shell. They typically begin with the hash symbol (#
), and continue until the end of the line.[2]
Configurable choice of scripting language
The shebang, or hash-bang, is a special kind of comment which the system uses to determine what interpreter to use to execute the file. The shebang must be the first line of the file, and start with "#!
".[2] In Unix-like operating systems, the characters following the "#!
" prefix are interpreted as a path to an executable program that will interpret the script.[3]
Shortcuts
A shell script can provide a convenient variation of a system command where special environment settings, command options, or post-processing apply automatically, but in a way that allows the new script to still act as a fully normal
One example would be to create a version of ls, the command to list files, giving it a shorter command name of l
, which would be normally saved in a user's bin
directory as /home/username/bin/l
, and a default set of command options pre-supplied.
#!/bin/sh
LC_COLLATE=C ls -FCas "$@"
Here, the first line uses a
The user could then simply use l
for the most commonly used short listing.
Another example of a shell script that could be used as a shortcut would be to print a list of all the files and directories within a given directory.
#!/bin/sh
clear
ls -al
In this case, the shell script would start with its normal starting line of #!/bin/sh. Following this, the script executes the command clear which clears the terminal of all text before going to the next line. The following line provides the main function of the script. The ls -al command lists the files and directories that are in the directory from which the script is being run. The ls command attributes could be changed to reflect the needs of the user.
Batch jobs
Shell scripts allow several commands that would be entered manually at a command-line interface to be executed automatically, and without having to wait for a user to trigger each stage of the sequence. For example, in a directory with three C source code files, rather than manually running the four commands required to build the final program from them, one could instead create a script for POSIX-compliant shells, here named build
and kept in the directory with them, which would compile them automatically:
#!/bin/sh
printf 'compiling...\n'
cc -c foo.c
cc -c bar.c
cc -c qux.c
cc -o myprog foo.o bar.o qux.o
printf 'done.\n'
The script would allow a user to save the file being edited, pause the editor, and then just run ./build
to create the updated program, test it, and then return to the editor. Since the 1980s or so, however, scripts of this type have been replaced with utilities like make which are specialized for building programs.
Generalization
Simple batch jobs are not unusual for isolated tasks, but using shell loops, tests, and variables provides much more flexibility to users. A POSIX sh script to convert JPEG images to PNG images, where the image names are provided on the command-line—possibly via wildcards—instead of each being listed within the script, can be created with this file, typically saved in a file like /home/username/bin/jpg2png
#!/bin/sh
for jpg; do # use $jpg in place of each filename given, in turn
png=${jpg%.jpg}.png # construct the PNG version of the filename by replacing .jpg with .png
printf 'converting "%s" ...\n' "$jpg" # output status info to the user running the script
if convert "$jpg" jpg.to.png; then # use convert (provided by ImageMagick) to create the PNG in a temp file
mv jpg.to.png "$png" # if it worked, rename the temporary PNG image to the correct name
else # ...otherwise complain and exit from the script
printf >&2 'jpg2png: error: failed output saved in "jpg.to.png".\n'
exit 1
fi # the end of the "if" test construct
done # the end of the "for" loop
printf 'all conversions successful\n' # tell the user the good news
The jpg2png
command can then be run on an entire directory full of JPEG images with just /home/username/bin/jpg2png *.jpg
Programming
Many modern shells also supply various features usually found only in more sophisticated
The standard Unix tools
Typical POSIX scripting languages
Scripting languages commonly found on UNIX, Linux, and POSIX-compliant operating system installations include:
- KornShell (
ksh
) in several possible versions such as ksh88, Korn Shell '93 and others. - The Bourne shell (
sh
), one of the oldest shells still common in use - The C shell (
csh
) - GNU Bash (
bash
) - Tcl/Tkprogramming language.
- The wishis a GUI-based Tcl/Tk shell.
The C and Tcl shells have syntax quite similar to that of said programming languages, and the Korn shells and Bash are developments of the Bourne shell, which is based on the
Other shells that may be available on a machine or for download and/or purchase include:
- Almquist shell (
ash
) - PowerShell (
msh
) - Z shell (
zsh
, a particularly common enhanced KornShell) - The Tenex C Shell(
tcsh
).
Related programs such as shells based on Python, Ruby, C, Java, Perl, Pascal, Rexx etc. in various forms are also widely available. Another somewhat common shell is Old shell (osh
), whose manual page states it "is an enhanced, backward-compatible port of the standard command interpreter from Sixth Edition UNIX."[6]
So called remote shells such as
- a Remote Shell (
rsh
) - a Secure Shell (
ssh
)
are really just tools to run a more complex shell on a remote system and have no 'shell' like characteristics themselves.
Other scripting languages
Many powerful scripting languages have been introduced for tasks that are too large or complex to be comfortably handled with ordinary shell scripts, but for which the advantages of a script are desirable and the development overhead of a full-blown, compiled programming language would be disadvantageous. The specifics of what separates scripting languages from high-level programming languages is a frequent source of debate, but, generally speaking, a scripting language is one which requires an interpreter.
Life cycle
Shell scripts often serve as an initial stage in software development, and are often subject to conversion later to a different underlying implementation, most commonly being converted to Perl, Python, or C. The interpreter directive allows the implementation detail to be fully hidden inside the script, rather than being exposed as a filename extension, and provides for seamless reimplementation in different languages with no impact on end users.
While files with the ".sh"
Advantages and disadvantages
Perhaps the biggest advantage of writing a shell script is that the commands and syntax are exactly the same as those directly entered at the command-line. The programmer does not have to switch to a totally different syntax, as they would if the script were written in a different language, or if a compiled language were used.
Often, writing a shell script is much quicker than writing the equivalent code in other programming languages. The many advantages include easy program or file selection, quick start, and interactive debugging. A shell script can be used to provide a sequencing and decision-making linkage around existing programs, and for moderately sized scripts the absence of a compilation step is an advantage. Interpretive running makes it easy to write debugging code into a script and re-run it to detect and fix bugs. Non-expert users can use scripting to tailor the behavior of programs, and shell scripting provides some limited scope for multiprocessing.
On the other hand, shell scripting is prone to costly errors. Inadvertent typing errors such as rm -rf * /
(instead of the intended rm -rf */
) are folklore in the Unix community; a single extra space converts the command from one that deletes all subdirectories contained in the current directory, to one which deletes everything from the file system's root directory. Similar problems can transform cp
and mv
into dangerous weapons, and misuse of the >
redirect can delete the contents of a file. This is made more problematic by the fact that many UNIX commands differ in name by only one letter: cp
, cd
, dd
, df
, etc.
Another significant disadvantage is the slow execution speed and the need to launch a new process for almost every shell command executed. When a script's job can be accomplished by setting up a pipeline in which efficient filter commands perform most of the work, the slowdown is mitigated, but a complex script is typically several orders of magnitude slower than a conventional compiled program that performs an equivalent task.
There are also compatibility problems between different platforms. Larry Wall, creator of Perl, famously wrote that "It's easier to port a shell than a shell script."[11]
Similarly, more complex scripts can run into the limitations of the shell scripting language itself; the limits make it difficult to write quality code, and extensions by various shells to ameliorate problems with the original shell language can make problems worse.[12]
Many disadvantages of using some script languages are caused by design flaws within the
Interoperability among scripting languages
Different scripting languages may share many common elements, largely due to being POSIX based, and some shells offer modes to emulate different shells. This allows a shell script written in one scripting language to be adapted into another.
One example of this is Bash, which offers the same grammar and syntax as the Bourne shell, and which also provides a POSIX-compliant mode.[13] As such, most shell scripts written for the Bourne shell can be run in BASH, but the reverse may not be true since BASH has extensions which are not present in the Bourne shell. As such, these features are known as bashisms.[14]
Shell scripting on other operating systems
Interoperability software such as Cygwin, the MKS Toolkit, Interix (which is available in the Microsoft Windows Services for UNIX), Hamilton C shell, UWIN (AT&T Unix for Windows) and others allow Unix shell programs to be run on machines running Windows NT and its successors, with some loss of functionality on the MS-DOS-Windows 95 branch, as well as earlier MKS Toolkit versions for OS/2. At least three DCL implementations for Windows type operating systems—in addition to XLNT, a multiple-use scripting language package which is used with the command shell, Windows Script Host and CGI programming—are available for these systems as well. Mac OS X and subsequent are Unix-like as well.[15]
In addition to the aforementioned tools, some POSIX and OS/2 functionality can be used with the corresponding environmental subsystems of the Windows NT operating system series up to Windows 2000 as well. A third, 16-bit subsystem often called the MS-DOS subsystem uses the Command.com provided with these operating systems to run the aforementioned MS-DOS batch files.[16]
The console alternatives
Scripting languages are, by definition, able to be extended; for example, a MS-DOS/Windows 95/98 and Windows NT type systems allows for shell/batch programs to call tools like
See also
References
- ISBN 0-13-937699-2,
The shell is actually a programming language: it has variables, loops, decision-making, and so on.
- ^ ISBN 9781430219989. Retrieved September 27, 2019.
- ^ "exec(3p) – POSIX Programmer's Manual". Retrieved 2020-07-24.
- ^ Unix Shells By Example, pp 7-10,
- ^ Programming Perl, 5th Edition, preface
- ^ "osh - manned.org". manned.org. Retrieved 2019-01-16.
- ISBN 9781449313258.
- ISBN 978-1435459571.
- ISBN 9781783552375. Retrieved May 7, 2017.
Rather than using a file extension for shell scripts, it's preferred to keep a filename without extension and let an interpreter identify the type by looking into shebang(#!).
- ISBN 9781593276027. Retrieved May 7, 2017.
Shell scripts don't need a special file extension, so leave the extension blank (or you can add the extension .sh if you prefer, but this isn't required.
- ^ Larry Wall (January 4, 1991). "Finding the last arg". Newsgroup: comp.unix.shell. Retrieved January 5, 2023.
- ^ Christiansen, Tom. "Csh Programming Considered Harmful".
- ^ "Major Differences From The Bourne Shell".
- ^ "24 Bashism To Avoid for POSIX-Compliant Shell Scripts". 18 May 2022.
- ^ MSDN[not specific enough to verify]
- ^ Windows NT 4 Workstation Resource Kit