Scripting languages part 1 (1)
Every admin loves time-saving shortcuts, and carries a selection of scripts from job to job, as well as inheriting new ones when arriving in post. The question any new admin asks is which is the best language to learn? (Followed by, where’s the coffee?) Veterans of language wars should know that the best language question rarely has a simple or definitive answer, but we thought it would be well worth comparing the most useful choices to make your Linux life easier. Most scripting languages have been around longer than you think.
For example, NewLISP was started on a Sun-4 workstation in 1991. They’ve borrowed from each other, and elsewhere, and accumulated a long legacy of obsolete libraries and workarounds. Perl’s Regular Expressions, for instance, are now found everywhere, and in some cases better implemented elsewhere.
So what matters most? How fast the script runs, or how quickly you can write it? In most cases, the latter. Once up and running, support is needed both from libraries or modules to extend the language into all areas of your work, and from a large enough community to support the language, help it keep up with trends, and even to innovate it. So, which scripting language should you learn to improve your Linux life this year?
How we tested…
Comparisons, they say, are invidious. This is certainly true for programming languages, where personality and local support are, at least, of equal import to criteria such as speed, and the level of support for different paradigms.
Given this, we’re presenting a mixture of facts, collective opinions and our own prejudices, but it’s a basis for further investigation.
The key to a scripting language’s usefulness to the sysadmin lies not just in how easily it helps solve problems, but in how many of the solutions have already been written, and are available to download and adapt, and preferably well-documented.
We tried to work across the range of versions installed on a typical network, but insisted on Python 3. Other than that, we’ve tried to stay in the context of working with what you’re likely to find on your network.
The learning curve
The key questions are: how easy is the language to pick up? Are the learning resources at least adequate? Even if these two questions are answered in the positive, they still need to be backed up by a helpful community to assist you in quickly producing something useful, and help maintain that initial enthusiasm as you hit inevitable problems.
To produce a backup script and test scripts in each of the languages, we started by browsing Stack Overflow. But downloading random code means no consistency between Posix (pure Bourne Shell) scripts, modern Bash, and legacy code that occasionally fails.
Fortunately, www.shellcheck.net is a great tool for checking the correctness of scripts, and teaches you best practice as it corrects them. The Linux Document Project’s (perhaps overly) comprehensive Advanced Bash Scripting Guide (www.tldp.org/LDP/ abs/html) is also excellent and will help you quickly gain confidence.
Perl’s online and built-in documentation is legendary, but we started by running through an exercise from the classic O’Reilly admin book, Running Linux , then leapfrogged the decades to No Starch’s recent Perl One- Liners by Peteris Krumins.
Those who eschew the book form should try http://perlmonks.org, a source of cumulative community wisdom. Recent efforts at getting youngsters learning through Code Club (www. codingclub.co.uk) and the rest of us through PyConUK education sprints and open data hackdays have shown Python to be easily picked up by anyone.
But out-of-date advice, such as the many ways of running subprocesses which persist for compatibility reasons, means careful reading is needed, and it’s yet another good reason for starting with Python 3, not Python 2.
Head to www.python. org/about/gettingstarted for large list of free guides and resources. Ruby is also an easy sell to learners, and before Rails, command-line apps were what it did best.
David B. Copeland’s book, Build Awesome Command Line Applications in Ruby will save you hours of wading through online documentation, but we were able to get up and running on our test scripts with a couple of web tutorials.
Last, we come to NewLISP: a challenge to programmers schooled only in non-LISP family languages, but you’ll be amazed by what it manages to accomplish with just lists, functions and symbols. We dived right in with the code snippets page on http://newlisp.org, adapting to build our backup script, and were rewarded with terse, powerful code, that was easier to read than its equally compact Perl counterpart.
Version and compatibility
The question here is: have I got the right version? Lets start with Bash . Every modern Linux distro ships with a version that will run your scripts and anyone else’s. Bash 4 , with its associative arrays, coproc (two parallel processes communicating), and recursive matching through globbing (using ** to expand filenames) appeared six years ago.
Bash 4.2 added little, and is four years old and Bash 4.3 ‘s changes were slight. Perl is still included in the core of most distros. The latest version is 5.20 (with 5.22 soon to appear), but many stable distros ship with 5.18. No matter, you’re only missing out on tiny improvements, and just about every script you’d want to write will be fine. The switch from Python 2 to 3 still catches out the unwary.
Run Python 3 if you can and check the documentation if you come unstuck. Python 3.3 is our baseline for Python 3 installs and Python 3.4 didn’t add any new syntax features.
Ruby version changes have caused enough problems that painless solutions have appeared, rvm enables you to run multiple versions of Ruby, and bundle keeps track of the gems you need for each script. NewLISP’s stability and lack of third- party scripts is an advantage here. We can’t, however, guarantee every script will run on the latest versions.