Is there any use for Bash scripting anymore?

Question

I just finished my second year as a university CS student, so my "real-world" knowledge is lacking. I learned Java my first year, continued with Java and picked up C and simple Bash scripting my second. This summer I'm trying to learn Perl (God help me). I've dabbled with Python a bit in the past.

My question is, now that we have very readable, very writable scripting languages like Python, Ruby, Perl, etc, why does anyone write Bash scripts? Is there something I'm missing? I know my linux box has perl and python. Are they not ubiquitous enough? Is there really something that's easier to do in Bash than in some other hll?

Answer 1

Among other things, bash is useful when most of what you're doing is communicating and piping between various programs (many of which are also standard). And there are many environments where bash (or at least a POSIX shell) is available but Perl and Python are not.

And of course, you should distinguish between interactive bash and scripted bash. Ubuntu recently switched their default scripted shell (#!/bin/sh) to dash because it was much faster. However, bash has useful interactive features dash does not (zsh is still better, IMHO).

See also Is it worth learning BASH when I know Perl?

Answer 2

Bash is incredibly useful in system administration, web application deployment, data crunching, sutomated backups, even getting-things-done day by day management just to name really few of them. I think It's too early for you to judge a "veteran IT soldier" like BASH.

EDIT googling around:

• comprehensive list of nice examples
• Useful bash tip and tricks
• 18 useful scripts for Web Devel.
• two minutes bash coding to improve your git usage

I'd like also to mention that TextMate a successful OS-X program has a lot of Bash machinery inside.

Answer 3

Well, when writing with bash, you can directly use every possible tool you have on the command line for your script. With any other language you would first have to execute that command and get some result etc. A simple script that (for example) gets a list of processes, runs through grep and gets some result would be a lot more complicated in other languages. As such, bash is still a good tool for writing quick things.

Answer 4

Many startup scripts are traditionally written as shell scripts and there doesn't seem to be a trend to move away from those.

Shell scripts are perfectly suited for starting other processes and gluing their input/output together. That's an area where the other scripting languages are not as powerful.

Apart from that: even if languages like Perl, Python and Ruby become more and more ubiquitous, the only language that you're practically guaranteed on every unix-like system is the bourne shell ('though not necessarily in the form of bash) .

Answer 5

Easier, probably not. I actually prefer perl to bash scripting in many cases. Bash does have one advantage, though, especially on Linux systems: it's all but guaranteed to be installed. And if it's not, its largely-compatible father (sh) will be, cause almost all system scripts are written for sh. Even perl isn't that ubiquitous, and it's everyfreakingwhere.

Answer 6

Bash (and the original Bourne sh and myriad derivatives) is - from one perspective - an incredibly high-level language. Where many languages use simple primitives, shell primitives are entire programs.

That it might not be the best language to express your tasks, doesn't mean it is dead, dying, or even moribund.

Answer 7

Bash scripts allow you to automate command line tasks by using the same language you would if you type the commands out manually.

Trivial Example to list $PATH

Bash

#!/bin/sh
echo $PATH

Python

print os.getenv("path")

Answer 8

Bash is not only a scripting language, but it is a shell.

Job control languages and shells
Main article: Shell script

A major class of scripting languages has grown out of the automation of job control, which relates to starting and controlling the behavior of system programs. (In this sense, one might think of shells as being descendants of IBM's JCL, or Job Control Language, which was used for exactly this purpose.) Many of these languages' interpreters double as command-line interpreters such as the Unix shell or the MS-DOS COMMAND.COM. Others, such as AppleScript offer the use of English-like commands to build scripts. This combined with Mac OS X's Cocoa frameworks allows user to build entire applications using AppleScript & Cocoa objects.

Python, Ruby and Perl are great, but are more general tools; in certain cases (embedded devices or other minimalistic systems) they can be considered bloat or in other situations they might pose a security risk (for environments where you want very high security and try to eliminate any unnecessary package).

In some cases shell scripts will perform much better due to closer integration with OS.

Also, bash is production proven for myriad of administrative tasks and it is easy to find scripts that will cover very complicated scenarios (exceptions) and handle them gracefully.

Answer 9

If you do lots of GUI stuff, you'll probably only meet bash whenever you're doing some sort of customization on your own machine. Various hacks and stuff. If you use the command line to do stuff, bash is just indispensable. In fact, being good on the command line requires bash or some other shell familiarity.

I get miles out of having learned Bash when I wanted to navigate around my harddrive quickly. I wrote a navigation/menu interface that let me beam to different folders and files quickly and easily. Writing it in bash was simple and easy. And there's lots of easily accessed, and free, stuff that'll show you how.

Also, learning Bash is great for understanding how Unix and some of the core stuff really works -- and how far we've come with tools like Python.

Answer 10

You may get a true bournesh over at freshmeat (on Mac OS X, for example, /bin/sh is not a true bournesh).

How to identify a traditional Bourne shell? ... A simple check for an often undocumented but characteristic feature: You can use the circumflex ^ (caret) as replacement for | (pipe).

see: http://www.in-ulm.de/~mascheck/bourne/

Answer 11

Apart from what others have said, I'd like to point out what's in my opinion the main reason to learn Bash: it's the (almost) standard Linux shell.

Other scripting languages are surely useful, and maybe a lot more powerful, but what you'll be dealing with when you have a terminal in front of you is... Bash.

Being able to manage I/O, pipes and processes, assing and use variables, and do at least some loop and condition evaluation is a must, if you want to manage a Linux system.

Answer 12

In my experience, Perl meets something like 99% of any need that might require a shell script. As a bonus, it is possible to write code that runs on Windows sans Cygwin. If I won't have a Perl install on a Windows box I want to target, I can use PAR::Packer or PerlApp to produce an executable. Python, Ruby and others should work just as well, too.

However, shell scripting isn't all that complicated--at least things that you should be scripting in a shell aren't all that complicated. You can do what you need to do with a fairly shallow level of knowledge.

Learn how to read and set variables. How to create and call functions. How to source other files. Learn how flow control works.

And most important, learn to read the shell man page. This may sound facetious, but I am 100% serious--don't worry about cramming every detail of shell scripting into your brain, instead learn to find what you need to know in the man page quickly and efficiently. If you find yourself using shell scripting often, the pertinent info will naturally stick in your brain.

So, yes, basic shell is worth learning.

Answer 13

I'm a perl guy, but the number of the bash (or ksh) functions I use and create on a daily basis is quite significant. For anything involved, I'll write a perl script, but for navigating the directory structure, and specifically for manipulating environment variables bash/ksh/... are indispensable.

Again, especially for environment variables nothing beats shell, and quite a few programs use environment variables. In Perl, I have to write a bash alias or function that calls the Perl script, which writes out a temporary bash script, which then gets sourced after Perl exits in order to make the change in the same environment I'm launching from.

I've done this, especially for heavy-lifting on path variables. But there's no way to do it in just Perl (or python or ruby... or C-code for that matter).

Answer 14

For a lot of tasks, bash can be very very concise. Code to search for a string in all the files of the current directory and print those lines:

In bash:

grep -ir "search_term" .

In Python:

for file in os.listdir('.'):
  file_content = open(file).readlines().split('\n')
  for line in file_content:
    if line.count("search_term") > 0:
      print file, ": ", line

Answer 15

As mentioned, the GNU tools are great, and are easiest to use within the shell. It is especially nice if your data is already in a linear or tabular form of plain text. Just as an example, the other day I was able to build a script to create an XHTML word cloud of any text file in 8 lines of Bourne Shell, which is even less powerful (but more widely supported) than Bash.

Answer 16

What I don't get is why people say bash when they mean any bourne-shell compatible shell.

When writing shell scripts: always try to use constructs that also work in older bourne shell interpreters as well. It will save you lots of trouble some day.

And yes, there is plenty of use for shell scripts today, as the shell always exist on all unixes, out of the box, contrary to perl, python, csh, zsh, ksh (possibly?), and so on. Most of the time they only add extra convenience or different syntax for constructs like loops and tests. Some have improved redirection features.

Most of the time, I would say that ordinary bourne shell works equally well.

Typical pitfall: if ! test $x -eq $y works as expected in bash that has a more clever builtin "if" operator, but the "correct" if test ! $x -eq $y should work in all environments.