CONTENTS Chapter 36 Shell Programming for the Initiated 36.1 Beyond the Basics 36.2 The Story of : # #! 36.3 Don't Need a Shell for Your Script? Don't Use One 36.5 The exec Command 36.6 The Unappreciated Bourne Shell ":" Operator 36.7 Parameter Substitution 36.8 Save Disk Space and Programming: Multiple Names for a Program 36.9 Finding the Last Command-Line Argument 36.10 How to Unset All Command-Line Parameters 36.11 Standard Input to a for Loop 36.12 Making a for Loop with Multiple Variables 36.13 Using basename and dirname 36.14 A while Loop with Several Loop Control Commands 36.15 Overview: Open Files and File Descriptors 36.16 n>&m: Swap Standard Output and Standard Error 36.17 A Shell Can Read a Script from Its Standard Input, but 36.18 Shell Scripts On-the-Fly from Standard Input 36.19 Quoted hereis Document Terminators: sh Versus csh 36.20 Turn Off echo for "Secret" Answers 36.21 Quick Reference: expr 36.22 Testing Characters in a String with expr 36.23 Grabbing Parts of a String 36.24 Nested Command Substitution 36.25 Testing Two Strings with One case Statement 36.26 Outputting Text to an X Window 36.27 Shell Lockfile 36.1 Beyond the Basics This chapter has a bunch of tricks and techniques for programming with the Bourne shell Some of them are documented but hard to find; others aren't documented at all Here is a summary of this chapter's articles: The first group of articles is about making a file directly executable with #! on the first line On many versions of Unix, an executable file can start with a first line like this: #!/path/to/interpreter The kernel will start the program named in that line and give it the file to read Chris Torek's Usenet classic, Section 36.2, explains how #! started Section 36.3 explains that your "shell scripts" may not need a shell at all The next bunch of articles are about processes and commands The exec command, Section 36.5, replaces the shell with another process; it can also be used to change input/output redirection (see below) The : (colon) operator evaluates its arguments and returns a zero status — Section 36.6 explains why you should care Next are techniques for handling variables and parameters Parameter substitution, explained in Section 36.7, is a compact way to test, set, and give default values for variables You can use the $0 parameter and Unix links to give the same script multiple names and make it do multiple things; see Section 36.8 Section 36.9 shows the easy way to get the last commandline argument Section 36.10 has an easy way to remove all the commandline arguments Four articles cover sh loops A for loop usually reads a list of single arguments into a single shell variable Section 36.11 shows how to make the for loop read from standard input Section 36.12 has techniques for making a for loop set more than one variable The dirname and basename commands can be used to split pathnames with a loop; see Section 36.13 A while loop can have more than one command line at the start; see Section 36.14 Next is an assortment of articles about input/output Section 36.15 introduces open files and file descriptors — there's more to know about standard input/output/error than you might have realized! Section 36.16 has a look at file-descriptor handling in the Bourne shell, swapping standard output and standard error The shell can read commands directly from a shell script file As Section 36.17 points out, a shell can also read commands from its standard input, but that can cause some problems Section 36.18 shows one place scripts from stdin are useful: writing a script that creates another script as it goes Next are two articles about miscellaneous I/O One gotcha with the heredocument operator (for redirecting input from a script file) is that the terminators are different in the Bourne and C shells; Section 36.19 explains Section 36.20 shows how to turn off echoing while your script reads a "secret" answer such as a password Two articles — Section 36.22 and Section 36.23 — show uses for the versatile expr expression-handling command Section 36.21 is a quick reference to expr Section 36.24 covers multiple command substitution (Section 28.14) Section 36.25 shows a trick for making one case statement (Section 35.10) test two things at once Finally, Section 36.27 has a simple technique for getting exclusive access to a file or other system resource — JP 36.2 The Story of : # #! Once upon a time, there was the Bourne shell Since there was only "the" shell, there was no trouble deciding how to run a script: run it with the shell It worked, and everyone was happy Along came progress and wrote another shell The people thought this was good, for now they could choose their own shell So some chose the one, and some the other, and they wrote shell scripts and were happy But one day someone who used the "other" shell ran a script by someone who used the "other other" shell, and alas! it bombed spectacularly The people wailed and called upon their Guru for help "Well," said the Guru, "I see the problem The one shell and the other are not compatible We need to make sure that the shells know which other shell to use to run each script And lo! the one shell has a `comment' called :, and the other a true comment called # I hereby decree that henceforth, the one shell will run scripts that start with :, and the other those that start with #." And it was so, and the people were happy But progress was not finished This time he noticed that only shells ran scripts and thought that if the kernel too could run scripts, this would be good, and the people would be happy So he wrote more code, and now the kernel could run scripts but only if they began with the magic incantation #!, and if they told the kernel which shell ran the script And it was so, and the people were confused For the #! looked like a "comment." Though the kernel could see the #! and run a shell, it would not do so unless certain magic bits were set And if the incantation were mispronounced, that too could stop the kernel, which, after all, was not omniscient And so the people wailed, but alas! the Guru did not respond And so it was, and still it is today Anyway, you will get best results from a 4BSD machine by using #! /bin/sh or: #! /bin/csh as the first line of your script #! /bin/csh -f is also helpful on occasion, and it's usually faster because csh won't read your cshrc file (Section 3.3) — CT 36.3 Don't Need a Shell for Your Script? Don't Use One If your Unix understands files that start with: #!/interpreter/program (and nearly all of them do by now) you don't have to use those lines to start a shell, such as #!/bin/sh If your script is just starting a program like awk, Unix can start the program directly and save execution time This is especially useful on small or overloaded computers, or when your script has to be called over and over (such as in a loop) First, here are two scripts Both scripts print the second word from each line of text files One uses a shell; the other runs awk directly: % cat with_sh #!/bin/sh awk ' { print $2 } ' $* % cat no_sh #!/usr/bin/awk -f { print $2 } % cat afile one two three four five Let's run both commands and time (Section 26.2) them (This is running on a very slow machine On faster systems, this difference may be harder to measure — though the difference can still add up over time.) % time with_sh afile two 0.1u 0.2s 0:00 26% % time no_sh afile two 0.0u 0.1s 0:00 13% One of the things that's really important to understand here is that when the kernel runs the program on the interpreter line, it is given the script's filename as an argument If the intepreter program understands a file directly, like /bin/sh does, nothing special needs to be done But a program like awk or sed requires the -f option to read its script from a file This leads to the seemingly odd syntax in the example above, with a call to awk -f with no following filename The script itself is the input file! One implication of this usage is that the interpreter program needs to understand # as a comment, or the first interpreter-selection line itself will be acted upon (and probably rejected by) the interpreter (Fortunately, the shells, Perl, sed, and awk, among other programs, do recognize this comment character.) [One last comment: if you have GNU time or some other version that has a verbose mode, you can see that the major difference between the two invocations is in terms of the page faults each requires On a relatively speedy Pentium III/450 running RedHat Linux, the version using a shell as the interpreter required more than twice the major page faults and more than three times as many minor page faults as the version calling awk directly On a system, no matter how fast, that is using a large amount of virtual memory, these differences can be crucial So opt for performance, and skip the shell when it's not needed — SJC] —JP and SJC As Section 36.3 explains, you can use #!/path/name to run a script with the interpreter located at /path/name in the filesystem The problem comes if a new version of the interpreter is installed somewhere else or if you run the script on another system that has a different location It's usually not a problem for Bourne shell programmers: /bin/sh exists on every Unix-type system I've seen But some newer shells — and interpreters like Perl — may be lurking almost anywhere (although this is becoming more and more standardized as Perl and other tools like it become part of standard Linux distributions and the like) If the interpreter isn't found, you'll probably get a cryptic message like scriptname: Command not found, where scriptname is the name of the script file The env command will search your PATH (Section 35.6) for an interpreter, then execute (exec (Section 24.2), replace itself) with the interpreter If you want to try this, type env ls; env will find and run ls for you This is pretty useless when you have a shell around to interpret your commands — because the shell can do the same thing without getting env involved But when the kernel interprets an executable file that starts with #!, there's no shell (yet!) That's where you can use env For instance, to run your script with zsh, you could start its file with: #!/usr/bin/env zsh zsh script here The kernel execs /usr/bin/env, then env finds and execs the zsh it found Nice trick, eh? What do you think the problem is? (You have ten seconds tick, tick, tick ) The catch is: if the env command isn't in /usr/bin on your system, this trick won't work So it's not as portable as it might be, but it's still handy and probably still better than trying to specify the pathname of a less common interpreter like zsh Running an interpreter this way can also be a security problem Someone's PATH might be wrong; for instance, it might execute some random command named zsh in the user's bin directory An intruder could change the PATH to make the script use a completely different interpreter with the same name One more problem worth mentioning: you can't specify any options for the interpreter on the first line Some shell options can be set later, as the script starts, with a command like set, shopt, and so on — check the shell's manual page Finally, understand that using env like this pretty much erases any performance gains you may have achieved using the trick in the previous article —JP and SJC 36.5 The exec Command The exec command executes a command in place of the current shell; that is, it terminates the current shell and starts a new process (Section 24.3) in its place Historically, exec was often used to execute the last command of a shell script This would kill the shell slightly earlier; otherwise, the shell would wait until the last command was finished This practice saved a process and some memory (Aren't you glad you're using a modern system? This sort of conservation usually isn't necessary any longer unless your system limits the number of processes each user can have.) exec can be used to replace one shell with another shell: % exec ksh $ without incurring the additional overhead of having an unused shell waiting for the new shell to finish exec also manipulates file descriptors (Section 36.16) in the Bourne shell When you use exec to manage file descriptors, it does not replace the current process For example, the following command makes the standard input of all commands come from the file formfile instead of the default place (usually, your terminal): exec < formfile —ML and JP 36.6 The Unappreciated Bourne Shell ":" Operator Some people think that the Bourne shell's : is a comment character It isn't, really It evaluates its arguments and returns a zero exit status (Section 35.12) Here are a few places to use it: Replace the Unix true command to make an endless while loop (Section 35.15) This is more efficient because the shell doesn't have to start a new process each time around the loop (as it does when you use while true): while : commands done (Of course, one of the commands will probably be break, to end the loop eventually This presumes that it is actually a savings to have the break test inside the loop body rather than at the top, but it may well be clearer under certain circumstances to do it that way.) When you want to use the else in an if ( Section 35.13) but leave the then empty, the : makes a nice "do-nothing" place filler: if something then : else commands fi If your Bourne shell doesn't have a true # comment character (but nearly all of them do nowadays), you can use : to "fake it." It's safest to use quotes so the shell won't try to interpret characters like > or | in your "comment": : 'read answer and branch if < 3 or > 6' Finally, it's useful with parameter substitution (Section 35.7) like ${var?} or ${var=default} For instance, using this line in your script will print an error and exit if either the USER or HOME variables aren't set: : ${USER?} ${HOME?} The versions of Unix developed at the University of California, Berkeley BSD (Berkeley Software Distribution) Unix has been dominant in academia and has historically had some features more advanced than System V: BSD introduced virtual memory, TCP/IP networking, and the "fast filesystem" to the Unix community It is also the system on which Sun OS was based System V Release 4 and some vendors' earlier System V versions also have Berkeley features buffer A temporary storage place such as a file or an area of the computer's memory Most text editors store the file you're editing in a buffer; when you're done editing, the edited buffer is copied over (i.e., replaces) the original file command line The text you type at a shell prompt A Unix shell reads the command line, parses it to find the command name (which is usually the first word on the command line, though it can be a variable assignment), and executes the command A command line may have more than one command joined by operators such as semicolons (;), pipes (|), or doubleampersands (&&) control character A character you make by holding down the keyboard CTRL (Control) key while pressing a letter or another character key core file, core dump The file made when a program terminates abnormally The core file can be used for debugging This comes from ancient "core" memory, where the contents of memory were stored in a magnetized ferrite core See also Section 15.4 .cshrc file See Section 3.3 daemon A program that is invisible to users but provides important system services Daemons manage everything from paging to networking to notification of incoming mail See also Section 1.10 data switch Hardware that is something like a telephone switchboard A data switch connects many terminals to two or more computers The user, on a terminal or through a modem, tells the data switch to which computer she wants a connection A data switch is also called a terminal multiplexor Computers without data switches usually have one terminal connected to each tty port; characteristics like the terminal type can be set in system files Conversely, computers with data switches can't know in advance what sort of terminal is connected to each tty port default In a program that gives you more than one choice, the one you get by not choosing The default is usually the most common choice As an example, the default file for many Unix programs is the standard input If you don't give a filename on the command line, a program will read its standard input dot (.) files (.cshrc, login, profile) Files that are read when you start a program (including when you log in and start a shell) These set up your environment and run any other Unix commands (for instance, tset) If your account uses the C shell, it will read cshrc and login Accounts that use the Bourne shell and shells like it read profile See also Section 3.6 double quote The " character This isn't the same as two single quotes ('') together The " is used around a part of a Unix command line where the shell should do variable and command substitution (and, on the C shell, history substitution), but no other interpretation See also Section 27.12 and Section 27.13 escape Using escape on a character or a string of characters is a way to change how it is interpreted This can take away its special meaning, as in shell quoting; or it can add special meaning, as in terminal escape sequences flag In programming, a flag variable is set to signal that some condition has been met or that something should be done For example, a flag can be set ("raised") if the user has entered something wrong; the program can test for this flag and not continue until the problem has been fixed flame A heated or irrational statement Free Software Foundation (FSF) A group that develops the freely available GNU software Their address is: 675 Massachusetts Avenue, Cambridge, MA 02139 USA full-duplex Communications between a terminal and a computer where data flows in both directions at the same time Half-duplex communications, where data flows in only one direction at a time, are unusual these days GNU Gnu's Not Unix, a system of software planned eventually to be a freely available substitute for Unix gotcha A "catch," difficulty, or surprise in the way that a program works hardcoded In general, a value that can't be changed For example, in a shell script with the command grep jane, the value jane is hardcoded; grep will always search for jane But in the command grep $USER, the text that grep searches for is not hardcoded; it's a variable value hash table Hashing data into the format of a hash table lets specially designed programs search for data quickly A hash table assigns a special search code to each piece of data For example, the C shell uses a hash table to locate commands more quickly; the rehash command rebuilds the hash table after you add a new command I/O Input/output of text from software or hardware inode A data structure that describes a file Within any filesystem, the number of inodes, and hence the maximum number of files, is set when the filesystem is created i-number A Unix file has a name (for people to identify it) and an i-number (for Unix to identify it) Each file's i-number is stored in a directory, along with the filename, to let Unix find the file that you name job One Unix command It is easy to be sloppy and use the terms job, process, and program interchangeably I do it, and I'm sure you do, too Within Unix documentation, though, the word "job" is usually used to mean one, and only one, command line Note that one command line can be complex For example: pic a.ms | tbl | eqn | troff -ms is one command, and hence one job, that is formed from four processes job number Shells with job control assign a job number to every command that is stopped or running in the background You can use job numbers to refer to your own commands or groups of commands Job numbers are generally easier to use than process IDs; they are much smaller (typically between 1 and 10) and therefore easier to remember The C-shell jobs command displays job numbers See also Section 23.2 kernel The part of the Unix operating system that provides memory management, I/O services, and all other low-level services The kernel is the "core" or "heart" of the operating system See also Section 1.10 kludge A program or a solution to a problem that isn't written carefully, doesn't work as well as it should, doesn't use good programming style, and so on library function Packages of system calls (and of other library functions) for programmers in C and other languages In general (though not always), a library function is a "higher-level operation" than a system call load average A measure of how busy the CPU is The load average is useful, though imprecise It is defined as the average number of jobs in the run queue plus the average number of jobs that are blocked while waiting for disk I/O The uptime command shows the load average .login file See the "dot (.) files (.cshrc, login, profile)" entry in this glossary and Section 3.4 mode In Unix, an octal number that describes what access a file's owner, group, and others have to the file See also Section 1.17 modulo Think back to your fourth grade arithmetic When you divide two numbers, you have a dividend (the number on top), a divisor (the number on the bottom), a quotient (the answer), and a remainder (what's left over) In computer science, this kind of division is very important However, we're usually more interested in the remainder than in the quotient When we're interested in the remainder, we call the operation a modulus (or modulo, or mod) For instance, one of the examples in your fourth grade arithmetic text might have been 13 ÷ 3 = 4 (with a remainder of 1) As computer users, we're more interested in 13 mod 3 = 1 It's really the same operation, though Modulo is also used in expressions like "modulo wildcards," which means "everything but wildcards." N - Z NFS Network File System NFS allows Unix systems and many non-Unix systems to share files via a TCP/IP network Subject to certain security restrictions, systems are allowed complete access to another system's files See also Section 1.21 and Section 44.9 newline The character that marks the end of a line of text in most Unix files (This is a convention, not a requirement.) Usually expressed as "\n" or LF null Empty, zero-length, with no characters — for example, a null string This is not the same as an ASCII NUL character octal number The base 8 numbering system Octal numbers are made with the digits 0 through 7,and begin with O For example, the decimal (base 10) number 12 is the same as the octal number 14 ASCII character codes are often shown as octal numbers option switch Typed on a command line to modify the way that a Unix command works Usually starts with a dash (-) The terms option and switch are more or less interchangeable An option may have several settings, but a switch usually has two settings: on or off, enabled or disabled, yes or no, etc panic Unix jargon for a "crash." A panic is really a special kind of a crash Panics occur when Unix detects some irreconcilable inconsistency in one of its internal data structures The kernel throws up its hands and shuts the system down before any damage can be done As it is going down, it prints a "panic" message on the console parse To split into pieces and interpret partition A portion of a disk drive Unix disk drives typically have eight partitions, although not all are in use path, search See Section 35.6 pipe A Unix mechanism for sending the output of one program directly to the input of another program, without using an intermediate file All Unix systems support pipes System V and Sun OS also provide "named pipes," which are FIFO (first-in/first-out) buffers that have names and can be accessed via the filesystem portable A program that's portable can be used on more than one version of Unix or with more than one version of a command POSIX POSIX is not an OS, but a standard for how Unix-like OSes should behave at various levels As an effort to counter the balkanization of Unix from vendor to vendor, POSIX defines the ways in which Unix-like OSes should expose their interfaces, from the kernel up to program- and shell-argument level priority A number that determines how often the kernel will run a process A higherpriority process will run more often — and, therefore, will finish faster — than a low-priority process process A lot of the time, a process is nothing more than another name for a program that is running on the system But there is a more formal definition: a process is a single execution thread or a single stream of computer instructions One job may be built from many different processes For example, a command line with pipes starts two or more processes See also Section 24.3 process ID (PID) Unix assigns every process an ID number (called a PID) when it starts See also Section 24.3 This number allows you to refer to a process at a later time If you need to kill a runaway program, you refer to it by its process ID The ps command displays process IDs .profile file See Section 3.4 prompt How a program asks you for information: by printing a short string like Delete afile? to the terminal and waiting for a response See also "shell prompt" in this glossary pseudo-code A way to write out program text, structured like a program, without using the actual programming language Pseudo-code usually explains a program read-only filesystem Filesystems are usually set up to allow write access to users who have the proper permissions The system administrator can mount a filesystem readonly; then no user can make changes to files there recursive A program or routine that re-executes itself or repeats an action over and over For example, the find program moves through a directory tree recursively, doing something in each directory reverse video On a video display, reversed foreground and background colors or tones Reverse video is used to highlight an area or to identify text to be used or modified For instance, if text is usually shown with black letters on a white background, reverse video would have white letters on a black background SCSI Small Computer Systems Interface, a standard interface for disk and tape devices now used on many Unix (and non-Unix) systems search path A list of directories that the shell searches to find the program file you want to execute See also Section 17.29 and Section 35.6 shell A program that reads and interprets command lines and also runs programs See also Section 27.3 shell prompt A signal from a shell (when it's used interactively) that the shell is ready to read a command line By default, the percent sign (%) is the default C-shell prompt and the dollar sign ($) is the default Bourne-shell prompt The default bash-shell prompt is also the dollar sign ($) slash The character / It separates elements in a pathname See also Section 1.16 single quote The ' character This isn't the same as a backquote (`) The single quote is used around a part of a Unix command line where the shell should do no interpretation (except history substitution in the C shell) See also Section 27.12 and Section 27.13 special file An entity in the filesystem that accesses I/O devices There is a special file for every terminal, every network controller, every partition of every disk drive, and every possible way of accessing every tape drive See also Section 1.19 string A sequence of characters subdirectory A directory within a directory See also Section 1.16 and Section 7.7 swapping A technique that the Unix kernel uses to clean up physical memory The kernel moves pages from memory to disk and then reassigns the memory to some other function Processes that have been idle for more than a certain period of time may be removed from memory to save space Swapping is also used to satisfy extreme memory shortages When the system is extremely short of memory, active processes may be "swapped out." system call The lowest-level access to the Unix operating system Everything else in Unix is built on system calls System V Unix A version of Unix from AT&T The most recent Release of System V is Release 4, known as V.4 or SVR4 TCP/IP Transmission Control Protocol/Internet Protocol A network protocol that is commonly used for communications via an Ethernet TCP/IP is also called the "Internet protocol." It is also common to use TCP/IP over leased lines for long-distance communications termcap Stands for terminal capabilities, an early (and still common) way to describe terminals to Unix terminal emulator A program that makes a computer display emulate (act like) a terminal For example, many terminal-emulator programs emulate the Digital Equipment Corporation VT100 terminal terminfo A newer way to describe terminal capabilities to Unix the Net A term for two particular networks: Usenet and Internet For instance, "I read it on the Net" or "You can get that file on the Net." timestamp The Unix filesystem stores the times that each file was last modified, accessed, or had a change to its inode These times — especially the modification time — are often called timestamps truncate To cut, to shorten — for example, "truncate a file after line 10" means to remove all lines after line 10 uuencode, uudecode Utilities that encode files with binary (8-bit) characters into an ASCII (7bit) format and decode them back into the original binary format This is used for transferring data across communications links that can't transfer binary (8-bit) data See also Section 39.2 VAX/VMS A popular computer operating system from the Digital Equipment Corporation wedged A terminal or program is wedged when it's "frozen" or "stuck." The normal activity stops and often can't be restarted without resetting the terminal or killing the program whitespace A series of one or more space or TAB characters word Similar to a word in a spoken language like English, a word is a unit made up of one or more characters But unlike English, words in Unix can contain whitespace; they can also have no characters (a zero-length word) XENIX One of the first versions of Unix to run on IBM PCs, and one of the few that will run on 80286 systems XENIX descends from Version 7 Unix, a version developed by AT&T in the late 1970s It has many resemblances to BSD Unix Over time, XENIX has been rewritten as a variant of System V.2 zombies Dead processes that have not yet been deleted from the process table Zombies normally disappear almost immediately However, at times it is impossible to delete a zombie from the process table, so it remains there (and in your ps output) until you reboot Aside from their slot in the process table, zombies don't require any of the system's resources See also Section 24.20 CONTENTS CONTENTS Colophon Our look is the result of reader comments, our own experimentation, and feedback from distribution channels Distinctive covers complement our distinctive approach to technical topics, breathing personality and life into potentially dry subjects The image on the cover of Unix Power Tools, Third Edition, is an AC DynoMite DC drill made by the Millers Falls Company, circa 1950 Jeffrey Holcomb was the production editor for Unix Power Tools, Third Edition Leanne Soylemez and Jeffrey Holcomb were the copyeditors Mary Brady, Linley Dolby, and Claire Cloutier provided quality control Genevieve d'Entremont, Julie Flanagan, Andrew Savikas, Brian Sawyer, and Sue Willing were the compositors Ellen Troutman-Zaig wrote the index Edie Freedman designed the cover of this book Emma Colby produced the cover layout with QuarkXPress 4.1 using Adobe's ITC Garamond font David Futato designed the interior layout This book was converted to FrameMaker 5.5.6 with a format conversion tool created by Erik Ray, Jason McIntosh, Neil Walls, and Mike Sierra that uses Perl and XML technologies The text font is Linotype Birka; the heading font is Adobe Helvetica Neue Condensed; and the code font is LucasFont's TheSans Mono Condensed The illustrations that appear in the book were produced by Robert Romano and Jessamyn Read using Macromedia FreeHand 9 and Adobe Photoshop 6 This colophon was written by Jeffrey Holcomb The online edition of this book was created by the Safari production group (John Chodacki, Becki Maisch, and Madeleine Newell) using a set of Frame-to-XML conversion and cleanup tools written and maintained by Erik Ray, Benn Salter, John Chodacki, and Jeff Liggett CONTENTS ... needs a complete and exact description, read a book on Unix programming Unix shells let you redirect the input and output of programs with operators such as > and | How does that work? How can you use it better? Here's an overview When the Unix kernel starts any process (Section 24.3) — for example, grep, ls,... Bourne shell programmers: /bin/sh exists on every Unix- type system I've seen But some newer shells — and interpreters like Perl — may be lurking almost anywhere (although this is becoming more and more standardized as Perl and other tools like it become part of standard Linux distributions and the like)... and it's usually faster because csh won't read your cshrc file (Section 3.3) — CT 36.3 Don't Need a Shell for Your Script? Don't Use One If your Unix understands files that start with: #!/interpreter/program (and nearly all of them do by now) you don't have to use those lines to start a