The timeless beauty of shell scripts

I'd agree with timeless. A pile of shell-scripts is the backbone of just about any deployment. And once you have them, they're not going away soon.<p>Beauty? Not so much.<p>Bash scripts are still the go-to solution because it's so quick to throw one together. Just paste what you have just tested on the CLI, add a few conditionals, done.<p>Unfortunately the "done"-part more often than not drags out much further than we'd like. Suddenly there's a need to inspect the output of a process rather than just the return code. Suddenly the script should run from cron, but only one instance at a time please. Welcome to the not-so-beautiful world of lockfiles and the never-quite-complete shell environment in cron.<p>This is the way our quick and beautiful 5-liners tend to turn into fragile 50-liners in short order. Little helpers like ftsh[1] can mitigate the mess somewhat. However, I for one try to use Python or Ruby for just about everything nowadays. It takes a bit longer to get off the ground that way - but it saves my slightly older self so much time and headache...<p>[1] <a href="http://www.cse.nd.edu/~ccl/software/ftsh/" rel="nofollow">http://www.cse.nd.edu/~ccl/software/ftsh/</a>

Most shell scripts are heaping mounds of undeclared external dependencies.

I really like the idea of connecting commands using pipes to do "one-off" commands. But piping strings is dumb and limits what you can reasonably do. It's too hard extracting what you want from the strings.<p>At my last company, I needed a tool to interact with the nodes of a cluster, including the databases on each node.<p>Putting this all together, I wrote a tool named Object Shell (<a href="http://geophile.com/osh" rel="nofollow">http://geophile.com/osh</a>), which is available under the GPL. It takes the idea of piping, but exposes Python language constructs on the command line. Python objects, not strings, are piped between commands. For example, I can write a command line to: execute a database query on each node; bring back the results with each row as a python tuple; combine the stream of tuples from each node into one stream; and then operate on the stream. Or I can write a command line to: get a list of process objects once a second; extract and transform properties of each process; dump the stream of data into a database. The Python objects have Python types, so I can operate directly on files, processes, numbers, times, etc. instead of strings representing those types.

Ruby is often just as terse as bash, and often simpler to understand. That said I still end up using bash, awk, sed, tr etc.. and don't revert to ruby until something gets complicated. Probably because bash is more portable.

<a href="http://en.wikipedia.org/wiki/Domain-specific_language" rel="nofollow">http://en.wikipedia.org/wiki/Domain-specific_language</a><p>Unix shell scripts is listed as the first example.

While I am an inadvertent bash progammer--an astonishing number of lines of code end up in bash--I view the python challenge as more of an tutorial tool, and don't advocate replacing my shell scripts with python.<p>I see this as a good way to learn python in the context of small problems to develop basic proficiency.

$ tr a-z l-za-m<p>$ tr -cd a-z<p>Absent the comments, who the hell knows what either of these do? Certainly not the new guy on your team who has spent most of his life in the more popular environments.

We evolve, or we die. Truism that. Sometimes it might take awhile, but its not less true.