Classic Shell Scripting - Arnold Robbins [2]
B.6.2. File Timestamps
B.6.3. File Links
B.6.4. File Size and Timestamp Variations
B.6.5. Other File Metadata
B.7. Unix File Ownership and Privacy Issues
B.8. Unix File Extension Conventions
B.9. Summary
C. Important Unix Commands
C.1. Shells and Built-in Commands
C.2. Text Manipulation
C.3. Files
C.4. Processes
C.5. Miscellaneous Programs
16. Bibliography
16.1. Unix Programmer's Manuals
16.2. Programming with the Unix Mindset
16.3. Awk and Shell
16.4. Standards
16.5. Security and Cryptography
16.6. Unix Internals
16.7. O'Reilly Books
16.8. Miscellaneous Books
Classic Shell Scripting
Arnold Robbins
Nelson H. F. Beebe
Editor
Allison Randal
Editor
Tatiana Apandi
Copyright © 2008 O'Reilly Media, Inc.
O'Reilly Media
* * *
A Note Regarding Supplemental Files
Supplemental files and examples for this book can be found at http://examples.oreilly.com/9780596005955/. Please use a standard desktop web browser to access these files, as they may not be accessible from all ereader devices.
All code files or examples referenced in the book will be available online. For physical books that ship with an accompanying disc, whenever possible, we’ve posted all CD/DVD content. Note that while we provide as much of the media content as we are able via free download, we are sometimes limited by licensing restrictions. Please direct any questions or concerns to booktech@oreilly.com.
Foreword
Surely I haven't been doing shell scripting for 30 years?!? Well, now that I think about it, I suppose I have, although it was only in a small way at first. (The early Unix shells, before the Bourne shell, were very primitive by modern standards, and writing substantial scripts was difficult. Fortunately, things quickly got better.)
In recent years, the shell has been neglected and underappreciated as a scripting language. But even though it was Unix's first scripting language, it's still one of the best. Its combination of extensibility and efficiency remains unique, and the improvements made to it over the years have kept it highly competitive with other scripting languages that have gotten a lot more hype. GUIs are more fashionable than command-line shells as user interfaces these days, but scripting languages often provide most of the underpinnings for the fancy screen graphics, and the shell continues to excel in that role.
The shell's dependence on other programs to do most of the work is arguably a defect, but also inarguably a strength: you get the concise notation of a scripting language plus the speed and efficiency of programs written in C (etc.). Using a common, general-purpose data representation—lines of text—in a large (and extensible) set of tools lets the scripting language plug the tools together in endless combinations. The result is far more flexibility and power than any monolithic software package with a built-in menu item for (supposedly) everything you might want. The early success of the shell in taking this approach reinforced the developing Unix philosophy of building specialized, single-purpose tools and plugging them together to do the job. The philosophy in turn encouraged improvements in the shell to allow doing more jobs that way.
Shell scripts also have an advantage over C programs—and over some of the other scripting languages too (naming no names!)—of generally being fairly easy to read and modify. Even people who are not C programmers, like a good many system administrators these days, typically feel comfortable with shell scripts. This makes shell scripting very important for extending user environments and for customizing software packages.
Indeed, there's a "wheel of reincarnation" here, which I've seen on several software projects. The project puts simple shell scripts in key places, to make it easy for users to customize aspects of the software. However, it's so much easier for the project to solve problems by working in those shell scripts than in the surrounding C code, that the scripts steadily get more complicated. Eventually