Slashdot Mirror
Unix Shell Programming, Third Edition
Now that we have languages such as Perl and Python, much of shell scripting has been forgotten. The need still arises for the times and places where running Perl would be just that little bit too much overhead; cron jobs, process start and stop scripts, even machine start and stop scripts. For these we could best go back to the old ways. Combining the power of the common Unix tools, pipes and scripts in a fairly obscure and slightly arcane syntax is not easy to pick up, though the language's simplicity does, in some ways, make it easier than more complex ones such as Perl. This book does a good job at introducing shell programming and I found it an excellent book when I needed a refresher.
I don't want to sell this volume short: you won't just learn about shell programming. The first ninety or so pages provide an excellent guide to getting the best out of the shell, and the last chapter is devoted to the features specific to an interactive shell such as command-line editing and using the history.
The authors have chosen to use the POSIX standard Bourne shell ('bash', available on many *nix systems, is a superset of the POSIX standard). That seems the right decision, given that it is so universally available and usually the default shell.
The book is well structured, starting out with a brief look at *nix operating systems before introducing the shell followed by some basic tools; cut, paste, sed, tr, grep, sort and uniq. One minor quibble, the book explains how to redirect STDOUT to a file and STDERR to a file, but not how to redirect both to the same file. That aside, these few chapters provide a good introduction to the shell.
The text goes on to systematically explore shell programming starting with variables and arithmetic. The chapters are kept short, in a good order and have a number of exercises at the end of each. The structure of the book and the order each new concept is introduced is well thought out; at each stage small examples are given that only use material already introduced and are complete in performing a task. In early chapters they are fairly trivial but by the end there is a fairly complete rolodex program written in shell script that would be a good model for anything you wished to do.
There is also a good summary of the shell syntax and common commands in Appendix A and good 'Further Information' in Appendix B. Kudos must go to the authors for a list of books for further reading that is not ashamed of mentioning other publishers, indeed they say "One of the best sources of books on Unix-related topics is O'Reilly and Associates" and list volumes from them before mentioning their own publishers.
There are some small typographic errors in the text but I did not find any in the script examples I tried. I found it to be well written and readable throughout, perhaps an advantage of a third edition in a slow moving technology.
You can visit the Sams web page devoted to the book which has the Table of Contents and the third chapter available for download. It has no errata or source code, I looked to see if the authors maintained a site for the book but could not find one.
I would recommend everyone read this book once or twice, it provides a comprehensive, well written tutorial on one of the most basic (and often overlooked) tools at your disposal. Even Windows users could install Cygwin and gain the benefit of a good POSIX compliant shell and this book. It also has the advantage that once purchased it will be useful for many, many years to come - the language has not changed noticeably in twenty five years and should not change in another twenty five.
You can purchase Unix Shell Programming, Third Edition from bn.com. Slashdot welcomes readers' book reviews -- to submit a review for consideration, read the book review guidelines, then visit the submission page.
JPSoft makes 4UNIX.
Shell scripting is a Lost Art. You know the True Gurus in the IT department by how comfortable they are with shell scripting. And of course, in the world of Microsoft, now one knows what you're talking about when you talk about scripting, they assume VBScript (the language of virii).
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
Now that we have languages such as Perl and Python, much of shell scripting has been forgotten. The need still arises for the times and places where running Perl would be just that little bit too much overhead; cron jobs, process start and stop scripts, even machine start and stop scripts.
Now that machines are getting much faster, can we expect shell scripting to be totally forgotten and unused? Are there movements for this already?
Froogle Link
Amazon Link
Maybe Darl could give a free copy away with every SCO-Linux license he sells....
Sunday you're Thinking Different, Monday you're a huge tool, paying too much and waiting to think like everyone else.
As the risk of being flamebait here, Bash is not the default shell on *BSDs (Is this the reason its dying?), its tsch. Neither is it the deault shell on QNX (ksh is). Perhaps the statement that bash is the default shell on most system seems overly broad.
CDE open sourced! https://sourceforge.net/projects/cdesktopenv/
I use shell scripts for many things under Windows using the free version of many Unix utilities found HERE. Scripts are fast, and don't break (short of being over-written). Many times, scripts can be written that perform the functionality of expensive Windows programs, with the advantages of being free, not easily broken, and not subject to dll version issues, continual upgrades, etc, etc, etc.
Shell Scripts are really The Cat's Pajamas.
"Would it kill you to put down the toilet seat?" -- Maya Angelou
When I first started learning about the concept of shells, I was moving from the MSDOS world.
One of the first things I remember reading was the FAQ describing the shell differences.
Imagine my surprise that the command line could hold so much control and there were other aspects of controlling a PC. I haven't looked back since, but that page really brings back some memories.
It's funny how something you read can cause one of those lightbulb moments.
Back when dinosaurs roamed the earth and NCR made Unix computers
I used to work on an AT&T 3b2. I can also script pretty well in DCL. Does that make me a sleestak?
Extra points for anyone younger than 30 who can prove they actually know DCL. Demonstrate something good - maybe set up IPC using mailboxes or something.
I cannot tell if you are being sarcastic, but it's pretty easy to see that his comment was, well, sarcastic, making fun of others that use the word.
Scripting was used as a term for the code of the 1960s Terry Winograd robot SHRDLU, that would reason about geometric objects.
Shell scripting is not the same as command line. Yes, many tasks that one does on the command line can now be done in a more friendly way with GUI, but shell scripting != command line. Think of the word "scripting" and what this means: A task that requires some steps, and my possibly be carried out automatically (perhaps with cron or some other daemon...). I would say something rude and stupid like "go back to your Win box and rejoice in your ignorance", but I probably shouldn't.
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
The LDP includes the "Advanced Bash-Scripting Guide" which is available in both HTML and PDF (1MB!) formats, and there is even a version for PalmOS! Since I found it, it's been the only reference I've *ever* needed when I've stumbled over some obscure nuance of shell scripting.
UNIX? They're not even circumcised! Savages!
Patrick's research staff contacted me two years ago and I did some minor work for him, via email (I never met him so don't go all crazy and ask for details) and was paid very well, considering it was research for a book.
Patrick's a pretty sharp guy but he outsources a lot of his research to proffesionals (makes sense) and has several staff people help him put the pieces together, as it were.
I offered my services as part of the FTEST (final tech editing service team) but Patrick didn't want a publishing pundit as much as he was looking for computer pundits. Ah well, at least now I'm in his rolodex and hopefully I'll get more chances to work with him.
Warmest regards,
--Jack
The one Amazon.com review gave this book 4 stars.
Helevius
I make my living as a Unix sysadmin, to support my hobby as a Real Programmer :-p.
Without shell scripts, I'd be lost.
Shell scripts provide the ability to leverage the work of every well-behaved perl (etc.) script, binary in /bin, and other shell script ever written. While the same can be said for perl scripts (which I happily use or write when needed), with shell scripting this is the intended paradigm.
Scripts are intrinsically open source, even if copyrighted and under a closed license. The techniques are visible, and thus instructive.
Given Unix's design attribute of easy process creation, shell scripting is often the best way for me to handle a task.
See some examples here.
sigs, as if you care.
The quote for this page when I loaded it:
"It is easier to port a shell than a shell script." -- Larry Wall
slashdot: where everyone yells sarcastic metaphors to themselves to understand the issue
It's an "observation" that many, a lot, a significan number... Are written in VBScript (a language I have made MUCH use of while employed as a MS SQL Server admin...).
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
I was just mourning the fact that the internet wayback machine's archives didn't include the collection of VMS .COM files I had set up on our campus's VMS cluster. (Running OSU's webserver for VMS)
Unfortunately, it's almost all left me, though I suppose I could still puzzle out the quoting rules to pass quoted arguments down three levels of @-signing. (Doubling the quotes each time...)
And hey, _I'm_ still under thirty (for two more years...)
Just because many shell scripts are hack jobs does not mean that this is the way they need to be. So, are you telling me that all Perl and Ruby looks like it should be put in the Louvre ? Sounds to me like either you don't know how to shell script, or you don't know how to shell script well .
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
That works just fine until some update to readline, or ncurses, or any of the other libraries the monster that is bash depends on happens to break your shell. Then, you're off to alternate boot media.
/bin/sh.
/bin/sh and a secondary root login that uses that shell.
It's fine to have bash as your everyday user shell. It's even ok to have it as your default shell for root, though having a second uid 0 login with some more minimal shell (like ash, for example) is often a good idea. However, I wouldn't make it as absolutely essential for the system as it is when it's
Personally, I take advantage of the setup provided by the Debian package sash, which provides a statically linked shell for
bookpool
UNIX(r) Shell Programming, 4th Edition
Of the same name, not related. Go figure. I got both and the one above is the better of the two, IMHO. Chapter 5 of this one is golden, lots of simple tables covering built in operaters, varibles, and control structures.
I really did not GET programming until the book above, it made it click for me. Perl came right after, as this got the concepts in my thick head.
A shell-less admin is a useless as a mermaid, and not as pretty to look at.
Never answer an anonymous letter. - Yogi Berra
Is it coincidence that the quote at the bottom of this page currently is:
"It is easier to port a shell than a shell script." -- Larry Wall
?
But apparently, you don't believe your own words enough to use your actual Slashdot account. This is the result of small testicals, but if you see a doctor, you may be able to get help.
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
And, after all, the article said that the book focused on /bin/sh, not bash.
/bin/sh. That's why startup scripts are written in /bin/sh - because it's always there.
And every unix system has some sort of
But these days as soon as I need a conditional or a loop I start thinking about doing the task in Perl or Python. These languages are so much easier to read and let you fork a process if you need to dip down into the shell.
No electrons were harmed creating this post, though some may have been subjected to electrical and/or magnetic fields.
Tell us why someone should prefer a crippled language when more advanced (and still equally easy to use) technology *) still has uses.
*) is available.
It's new years eve, wine made me do the grammatcal/semantic error.
And thanks, anonymour moderator, for the "troll" moderation. Want to silence any discussion that touches too close to the home, right?
Save your wrists today - switch to Dvorak
The shell is universally available. On some low-end systems (yes they still exist), Python and even Perl might not be installed.
Constitutionally Correct
$(( is valuable in inner loops when spawning eval repeatedly can slow down a scan of files in a list, etc. etc.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Of course, I know where to draw the line. Another sysadmin here wrote a set of backup scripts (thankfully now lost) that were over 10000 lines of sh, with embedded awk and sed. It maintained a tape database, etc. It was truly insane to debug. Anything more than about 300 lines ends up either as a set of small, easily maintained scripts (and one script that ties them together) or as a Perl or Python (depending on mood and how much of the work is raw text processing -- regex as a language intrinsic is a perl bonus.)
-30-
- Every Posix-compliant system has
/bin/sh, but not neccessarily Python or any other interpreter or compiler. Which is the reason why Python comes with a ~20000-line configure script written in sh, not a python-based one even if it probably would be nicer.
- It is the same language you use in an interactive shell. Once you figured out how to do stuff manually, you just have to put the commands you typed in a file together with a shebang line, and there is your script. Knowing shell scripting also helps when working in interactive mode, a loop or case/esac is also useful in one-liners.
- It is generally faster to start a shell than another interpreter (although bash has almost fixed that, so this is not so much of an issue on GNU systems). If you have lots of small scripts, that matters (think init, for example).
- You can source shell scripts, hence you can write a shell script that modifies the environment of your interactive session. You cannot do that with any other language.
On the other hand, nobody proposes to write something like Zope in sh. Both Shell and higher-level languages have their uses, as have lower-level languages like C or assembly. The good programmer/admin is the one who can use more than one tool productively, and knows when to use which.Programming can be fun again. Film at 11.
And free as in beer:
Advanced Bash-Scripting Guide
Never ascribe to malice that which is adequately explained by incompetence.
if I recall correctly, the plan for Longhorn is to be able to do ANYTHING from commandline. If it can be tweaked in a GUI, there's a shell command that will do the same thing.
Comment removed based on user account deletion
The other day I wrote a little utility to track referrers to my websites. I wrote the main chunk in perl. But the part that actually drives the whole process -- that sifts through config directories, calls child scripts, sends email... right back to bash. It's just so damn easy. Or maybe that's just my distaste for perl talking.
wordclock records
For one thing, launching processes or manipulating the file system (which is the only reason for a scripting language) is going to be much more verbose in Python.
os.system("mycommand a.txt")
Python will make you do incredibly stupid and redundant things like open files.
How? Could you elaborate? You don't need to do anything you don't need with shell scripts.
Secondly, injecting a filter between pipes in Python means either reading in the input entirely (waste of memory), or reading it piecemeal (verbose and unnecessary). With the shell, you inject a sub-process.
os.system() allows you to execute full pipelines. I don't see what's the problem. You slurp in the output when you need to do something more advanced that can't be done by piping it to a pre-existing command.
Save your wrists today - switch to Dvorak
I typically discard shell for anything more complex than a while/do sh loop. For anything moderately complex, sh is baroque, syntactically retarded, and feature-deficient.
The shell is universally available. On some low-end systems (yes they still exist), Python and even Perl might not be installed.
Yes, of course. Yet most of the scripts that sysadmins write are for normal systems with no such limitations.
I'm not saying shell scripts have no purpose. I'm saying that in 95% of of the cases they are used a more structured solution would have been more appropriate.
Save your wrists today - switch to Dvorak
Please, tell me what distro does not include perl or python practically by default. This is a silly argument that was irrelevant about four years ago.
. In my experience there haven't been any more bugs/maintenance problems with 30 line shell scripts compared to 30 line perl scripts.
:-).
I think that says more about Perl than shell scripts
Save your wrists today - switch to Dvorak
...In my imaginary Slashdot fantasy land. We should do lunch sometime.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
If memory concerns are truly an issue, you are not going to get relief by simply switching environments. You probably need to rethink and redesign.
Basically, if you have a *NIX like system, you are pretty much guaranteed to have a /bin/sh, and it will always work the same. Bash is common, but not universal. Ksh is proprietary, though there are open source versions (pdksh), but you won't find it everywhere. Csh is an abomination. Other shells are interesting and useful, but you'll never know if they are on any given system, or if they will run the same.
If you want a script that will run the same everywhere, then use /bin/sh.
(Of course, this isn't even getting into differences between "awk", "nawk", "gawk" and all the other tools and their various incarnations that you end up using in shell scripts, but at least you can have some hope that the underlying shell will be predictable.)
Your Servant, B. Baggins
Name three major modern unices that does not include a decent scripting language by default. Perl and Python typically do show up in most self-respecting distros or are trivially available as precompiled packages.
It is the same language you use in an interactive shell
This is basically the "legacy" argument. You can use perl or python as interactive shells, there are tools to aid in this.
It is generally faster to start a shell than another interpreter
When all else fails, cite efficiency. I would ask you to provide one useful example where avoiding the startup time of perl has been a requirement for getting a job done.
You can source shell scripts, hence you can write a shell script that modifies the environment of your interactive session. You cannot do that with any other language.
This is categorically false. Sorry.
Do you have an interactive debugger for sh? Thought not. Do you have language-level features for dumping and evaluating data structures in sh at run-time as inspectable structures? Thought not.
Please don't mention NCR! It's been almost 3 years since I quit as a field engineer and I still have nightmares...
All of these I can do by hand and on machines where the scripts are borked I do. I then replace the IF WHEN WHILE bits of the scripting language with my brain. In fact that is how I write scripts. I write down into code what I have been doing each time.
So speed of cpu is meaningless. It is all done to help lazy sysadmins.
You might mean, because cpu is more powerfull can't we use other languages. Well yes. There is nothing really stopping you from replacing a lot of shell scripts with say perl. EXCEPT. Perl may not always be there or working. You need something simple and lowlevel for simple and lowlevel tasks. I don't see this changing. Hell MS is talking of adding stuff like this to longhorn.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
language has not changed noticeably in twenty five years and should not change in another twenty five
Is this a good thing? I mean don't we sometimes have to abandon the ideas of old in order to progress? How has English evolved over the past 50 years? Besides the branch of American English and the ones the UK speaks and writes. Maybe not much but how about 300 years? As technology progresses further than a Moore breaking speed should the language not evolve as well?
I agree that Unix language is solid and has been around for a while, but should we choose the permanent language based on technology first conceived 25 years ago?
This SIG pulled due to lack of funding. (This damn war is costing too much!)
Which is the reason why Python comes with a ~20000-line configure script written in sh,
Techically it's not 'written', it's an autoconf script.
Knowing shell scripting also helps when working in interactive mode, a loop or case/esac is also useful in one-liners.
This is true. Especially for loop comes in handy in interactive sessions.
Knowing shell scripts is good, even necessary for sysadmins. Writing shell scripts is what should be discouraged.
You can source shell scripts, hence you can write a shell script that modifies the environment of your interactive session. You cannot do that with any other language.
Right. This is one of the defendable reasons for using shell scripts. The other one is "shorcut"-like functionality, i.e. using the script as an alias for a program w/ some arguments, perhaps changing the values of environment variables beforehand.
Save your wrists today - switch to Dvorak
I don't know what "practically by default" is supposed to mean, but I'll tell you what Unices (even beyond your Linux "distros") don't have Perl or Python: the ones where /usr is unavailable at the time you need to do something.
When I was a kid, we only had one Darth.
This book is irrelevant because anyone sane already knows the futility in trying to do anything non-trivial in sh.
I disagree and refer you to an example of a significant shell application that is complex and useful: Enhanced Network Scanjet 5 (I'm the author).
This is about 2,400 lines of Bourne shell (runs under BSD sh or Bash) that reimplements the HP Network Scanjet 5 functionality, with many improvements, particularly the fact that is is completely standalone.
This application was originally written in about five working days, and I firmly beleive that it would have been just about impossible in that time in any other language but shell. The ease with which other utilities such as Sane and Ghostscript were integrated was a huge feature of sh.
Reading through this thread, I am wondering- am I the only one who uses shell scripts, then breaks into perl whenever something more complicated is needed?
Sure, you can do everything with awk and sed if you want to, but having perl -e in the middle of all those pipes is not a sin, and it makes otherwise tedious proccesses go by quickly.
-- 'The' Lord and Master Bitman On High, Master Of All
What exactly is more powerful and less fragile about Python in comparison to a sh script?
If you are serious, you need to freshen up your computing skills a little bit. Shell scripts tend to fail in unpredictable ways, often with no clue what went wrong. Python script raises an exception that immediately tells where the problem is.
Programming languages are for writing programs to do things, sh scripts are for tying things together in an automated way.
You don't realize that things have changed from the time sh was developed. Better languages for the job exist now. Some of us can recognize superior technology - others repeat obsolete tautologies like mantras, with zero understanding of technological realities.
Python is a nightmare to do nearly anything complex with for me.
I'm not sure what that sentence means.
It requires way too many dependencies, is less reliable than good old "${SHELL}", and typically requires more overhead from my CPU and memory.
I'm not sure what kind of boxen you work with, but they certainly sound pretty broken and underpowered. Buy some p5, they should go for pretty low prices these days and have enough power to run these "heavy" tools.
Happy New Year, troll.
I think this underlines your mentality. Mod down and flame, instead of sticking to technical issues. The technical points you present sound pretty childish to me, and showcase a profound lack of understanding of the issues involved w/ complex systems. You should really catch up w/ the times, or be buried w/ the obsolete Unix boxen you currently maintain.
BTW, if I notice something postworthy I post w/ my real name and skip moderation. Disagreeing with someone doesn't mean it's a troll.
Save your wrists today - switch to Dvorak
Get black people to stop using that word, then we'll talk. The notion that only certain people can use that word is racist too.
Another (free) resource is the very readable, very thorough Advanced Bash-Scripting Guide [http://www.tldp.org/LDP/abs/html/]. Mendel Cooper has done an excellent job with this project. If a person wished to learn more about Bash, I would direct them here *first*.
Well.. almost anyway...
Personally, I prefer shell scripts due to their ease and speed - most of my scripting is of the "I have N tons of data, find some piece of information & correlation" type. If I'm automating tasks, I'll use a shell script to tie together a series of perl & expect scripts...
Need Geek Rock? Try The Franchise!
Here's a clue: there's more to *nix than Linux.
But the question really is, which flavors of Unix have both Perl and Python installed by default. Once can count on having the Bourne shell (or something compatible) on virtually any Unix installation. If one is to target Perl or Python, one cannot count on it being there.
Windows NT scripting is "very functional" but Perl is bloat. Wow, funniest thing I've heard all year.
"The world only exists in your eyes. You can make it as big or as small as you want." - F Scott Fitzgerald
NetBSD.
Constitutionally Correct
For two, believe it or not, outside of Linux, Python doesn't necessarily come with a Unix system by default, and no, where I work (a huge financial company), they won't let you compile an external package on a production host. Nor does Python come with the default OpenBSD installation that I run on an old Pentium which I happily use as a router/firewall at home. Granted, it's not a big deal to install Python on OpenBSD, but really, it takes more time and probably effort than piping find to xargs, and that's about the most advanced "program" that I ever write on that OpenBSD machine.
To summarize, I believe that these two reasons (less verbose and always available) make shell a very viable scripting tool even today, in the presence of Python and Perl. And no, a shell script is not necessarily a mess when written by a good developer, just as Python code is not necessarily all clean and readable when written by a moron.
My only problem with Microsoft is the severity of bugs in their software.
Steve Bourne calls them shell procedures not shell scripts. I figure since he created the shell named after him, he should know. So I call them that too.
All the comments about how powerfull shell scripting is, miss an important point:
The vast majority of shell scripts rely on other commands to do alot of the work. For example, how many shell scripts use awk, sed, find, cut, head, tail and so on. Without all the "external" commands the shell is much less useful.
In addition, there is considerable overhead due to the fork/exec of these external commands.
With languages like perl/python/ruby you may have to actually write a little more but it all executes within a single process.
import os /usr")
:)
os.system("mount
i'm not even a python user and i know you can do that
====
Crudely Drawn Games
Here's a script for that nicely written post. Happy New Year!
e `whoami`
GET http://www.perfidious.org/award|\
sed '1!G;h;$!d'|sed '/\n/!G;s/\(.\)\(.*\n\)/&\2\1/;//D;s/.//'|\
writ
MoFscker
You have to do a check to see what platform you're on
Well, the situation is not buch better with shell scripts on windows - cygwin just doesn't work like it should.
On Python I have to write a wrapper function just to make things usable.
I always have a wrapper fn for os.system. Several, in fact. Typically I print out the command and then execute it. Sometimes w/ logging, sometimes w/o.
In Python, I would either have to fork explicitly (yuck), or read in from the input piecemeal, and then write my translation on the output piecemeal (double-yuck). There is no straight-forward Python equivalent of { }.
Have you checked out "pipes" module, by any chance?
Save your wrists today - switch to Dvorak
What you are describing is a syntax check, not a debugger.
For fun I downloaded your script. You are truly a glutton for punishment. 80% of this code could have been more sanely expressed in perl. Your script demonstrates extreme proficiency in sh scripting (hats off to you) but in no way invalidates the well-established idea that perl or python are superior for long scripts. I suspect this program would have been coded in half the number of lines using perl in particular, just in syntactic clarity and expressiveness without knowing anything about the actual hardware you are dealing with.
FWIW, the Korn shell was available before BASH and came with most commercial unices from about 1990 on. Korn's intent was to have a shell that was useful for programming as the original Bourne shell and was as nice for interactive use as the C shell.
BASH is common on Linux as the source code for KSH was not widely available until relatively recently. The other problem is that most unices come with an old version of ksh (1988).
A Shadeless room is a brighter room.
Ok, I have a question. My ISP uses bash and when you tab complete stuff it automagically encloses it in double quotes. But when I tab complete on my own box it just does the old insert\ back\ slashes which is kind of lame.
So, I figure it must be some sort of option I can change in bashrc or something but I don't know what needs to be changed or added for this to occur.
My Minix box doesn't have perl or python.
No room for that kind of bloat. The entire install media set, including all source, fits on 9 floppies.
A Good Intro to NetBS
The irony that I think you may have missed is that you just used the binary /usr/local/bin/python (or /usr/bin/python on some installs, I suppose) to mount /usr.
A Good Intro to NetBS
Yeah but bash can tell when it was started as "sh" and run in compatibility mode, to roughly quote another poster somewhere in this thread - Don't mod me up.
I agree that racism is intolerable. However, my response was directed at a comment I read that implied that the blog was intentionally promoting racism.
I read his blog entry as an illustration of how awful some posters are. While perhaps he could have worded it a bit better, it still sounded to me as if his blog implied that people who post racist comments are the lowest of the low, the people that "gotta piss in the pool".
I guess that means that you've yet to have any sort of job in the IT industry.
Maybe a good example of how shell scripting can be made to good use is smartadmin, which i wrote during a weekend :
ftp://ftp.crashrecovery.org/pub/linux/smartadmin/
smartadmin - Create/Edit/Remove a UNIX/Linux user and/or a Samba user.
smartadmin was created out of sheer misgrief about total contra produc-
tive effects of packages like webmin, requiring rediculous resources to
perform basic user administration on a UNIX/Linux and Samba server. The
requirements for smartadmin to act as remote admin is just a terminal
client program which can handle ncurses/dialog menu's.
in my life God comes first.... but Linux is pretty high after that
Francis Smit
When the Junior Unix Sysadmin comes to me, as they do, and asks "what language should I write this tool in?", here is my decision sequence:
- shell (with sed/awk/grep) for process management/job control and line-by-line text processing.
- C for servers, time-sensitive applications, interfaces to syscalls.
- Python or Ruby for complex system tools that benefit from an object model.
- Perl for text mangling. I know; Perl can do anything, and often it's the fastest to write. But as the corollary has it: in Perl, there are too many ways to do it. I usually say that "Using Perl for any of the above is cheating," but what I actually mean is that since most of the perl I've seen produced by anyone below "Guru" status is sloppy, undisciplined, inconsistent and barely maintainable, I'd rather see the above languages used instead.
- Java for the server-side of big business applications (i.e. Java is the new COBOL)
- C++ when Java is too slow or memory hungry, or for client-side business apps (e.g. GUIs, office software, the recording backend for your particle accelerator)
This list, in this order of preference, has stood me in good stead for years and leads to decisions that are almost always right.I never recommend TCL or expect, believing them obsoleted by python/ruby. LISP is only a good recommendation for emacs weenies, who live in their own wonderful world and never ask others anyway.
Sorry, no, PHP doesn't qualify as a useful language in my book. I see it as an API the size of a planet driven by a syntax akin to a small, sick dog. Vade retro.
- J
Surprise, surprise, os.system() invokes--get this--the shell
.pid file kind of stuff. Works like a charm. You fail to realize that language doesn't need to be "designed" for a particular task to excell in it, it happens automatically if the fundamental language design is good enough. You can do the rest with libraries.
Of course it does. That's why you can do most of the stuff you use shell for in Python.
I'm obviously not saying that the shell is evil incarnate that should be removed from the system. I'm saying that programming straight for it, instead of invoking it from Python, is futile.
Also, how is os.system() supposed to be less verbose?
We developers then to use these things called "functions" to make stuff less verbose. And nobody prevents you from doing
x = os.system
x("ls")
And Python isn't designed primarily as a process control language, which makes things trickier than in a shell (have you ever done job control in Python)?
Yes I have, if you mean the
Save your wrists today - switch to Dvorak
The shell-like scripting languages are actually a lot closer fit to their problem domain (managing programs, I/O, and files) than more recent scripting languages like Perl and Python. There are a number of reasons for their decline in popularity, but it is hard to argue that explicit management of files and their contents (open, close, iteration) is easier or better than piping and redirection. It is also possible to make shell-like languages both faster and safer than other scripting languages (this is work in progress - I hope to make a prototype release available soon). Although it may surprise many Slashdot readers to hear that bash is easily 10 times faster than Perl for many text processing tasks...
Once upon a time I had some nasty .BAT files that used AWK.EXE and SED.EXE for the heavy lifting. Explaining them to a coworker took a while, because he wasn't an awk or sed guy.
.BAT files are very limited, and annoying. VBscript/WSH syntax is verbose and annoying. Shell syntax is just plain fucked up and annoying.
WSH is complex, but nontrivial shell scripts are complex too, there's a lot of baggage involved.
I'm an equal opportunity bigot: I hate all the common scripting choices.
The above have their place, and I can write scripts in all of 'em, but I don't enjoy it.
When possible I lean on awk/sed/Perl. The DJGPP AWK.EXE and SED.EXE has saved my bacon many times, and these days Perl runs nicely on Win32.
except that awk and sed tend to be the same no matter what shell you're using
-- 'The' Lord and Master Bitman On High, Master Of All
--Geez, you and this Ultrabot troll are getting on my nerves already. He's already made my enemy list, and you're not far behind.
;; if $DEBUGG echo ... ' stuff where I need to see what's going on.
--Who the hell needs an interactive debugger for SHELL SCRIPTS?! The reason nobody's written one is because they're NOT NEEDED!
--If I want to "debug" a script, I just do ' set -o xtrace ' and/or ' DEBUGG=1
--Climb down off the high horses guys, shell scripts work fine where Python, et al (not to mention an interactive debugger -- sheesh! Ars-Fartsica $crack-pipe!) would be complete overkill.
.
== WolfriderV6 == I'm willing to admit that *I just might* be wrong... Are you??
(pounds sand in frustration)
/usr isn't mounted yet PYTHON ISN'T EVEN AVAILABLE YET!!!
--Do you even REALIZE that os.system USES THE SHELL? You don't NEED python for that command... And as someone else pointed out, if
(scream, crash, sob)
.
== WolfriderV6 == I'm willing to admit that *I just might* be wrong... Are you??
But, I'm also pretty certain that this is a minority position. Most Unix boxes are purchased/leased for a specific purpose and the default install contains very little leaving the administrator to decide which programs to install. The fewer programs installed, the fewer possibilities there are for something to go wrong.
I hold that this is a good thing because the administrator knows better if Perl (or Python) is needed and if so if Perl (or Python) needs to be a specific version or flavor or compiled with specific options and so on and so forth. It is best to keep the defaults to a minimum and assume that the adminstrator knows what to add on and what not to.
Hence, your beef seems to me to be with sys admins that aren't providing the tools that the boxes they installed need for the users to get their work done. It doesn't really have anything to do with whether or not a given toolset is part of the default install.
Although, I will also say that it royally pisses me off when the sys admin installs one of the newfangled versions of vi with all the bells and whistles turned on so that I have to edit some .rc file or the other to turn them off so that vi acts like vi. When I want syntax highlighting and autoindent, I'll use xemacs. Few things are more irritating than discovering pasting a sizeable chunk of code only to discover that vi is actually vim and autoindent is turned and all the indentation in twenty lines or so of code you just pasted gets funged because vim's autoindent sucks when the pasting lines already indented.
Whatever. This book is no substitute for a close reading of The Unix Programming Environment -- if anyone knows what is, I'd love to hear about it.