Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

We are doing all our scripting with Bash so far, but I'm starting to feel a bit silly about it. While we can of course do everything we want with Bash (it's quite powerful), I'm starting to wonder if we shouldn't use a proper scripting language (in our case most likely Ruby) instead.

How do you decide when to use Perl/Python/Ruby over Bash for a script? I don't think an init script with Ruby makes sense, but how about a slightly longer script that adds email accounts?

share|improve this question
If you can do it using either, does it really matter? The choice is only interesting if the resulting script presents any differences. For example, execution time could differ drastically (not the case an issue when email accounts). –  Dennis Apr 21 '12 at 4:05

5 Answers 5

up vote 5 down vote accepted

Given a problem that both can handle, you'll want to use the one you're most comfortable with. Ultimately, there are a lot of small details, and only experience can teach you to see them.

Bash is a general purpose scripting language just like Python, Ruby, Perl, but each has different strengths over the rest. Perl excells at text analysis, Python claims to be the most elegant of the bunch, Bash scripts are excellent at "piping stuff around", if you know what I mean, and Ruby... well, Ruby is a little special in a lot of ways.

However, the differences between them only really matter once you have a healthy amount of scripting experience under your belt. I suggest you pick one language and push it to it's limits before moving to the next. You can do a lot in a shell script, more than most people would admit. Any language is just as hard as you want to make it. After you've written a couple things in it, every language is "easy" to you.

Being familiar with the shell pays off quickly if you live in Linux, so maybe you want to start with that. If you find a task you that is impossible or impractical to solve in a shell script, use something else.

Also, bear in mind that learning shell scripting is very simple. The real power of it lies in other programs, like awk, sed, tr, et al.

share|improve this answer
I've got quite some experience with bash scripting, as with Ruby, but I sometimes still don't know what to use. Choosing based on personal preference at that moment in time seems silly. But you're right, I'll ask myself what I want to do and pick the best tool for the job. –  futlib Apr 21 '12 at 6:09
Personally, I'll use a scale of the languages I know well, in ascending order of complexity and power, and use the simplest that will fit the bill. But really, the only way to know for sure is writing your script in all languages and comparing the outcome. It's all more of a gut feeling than a certainity. After some years writing scripts, you will have come across most "types of problems", and know which language did well solving them. –  mkaito Apr 21 '12 at 14:20

I use bash when my primary focus is on file handling. This could include moving, copying, and renaming files, as well as using files as input for other programs or storing other program's output in files. I rarely write bash code that actually examines the contents of a file or generates the output to write to a file; I leave that to the other programs (which I may write in Perl or python) that I launch via bash.

I use Perl and python when my primary focus is on reading data from files, processing that data in some way, and writing output to files. If I find myself using (in Perl) the system command, back ticks or (in python) the subprocess module too extensively, I consider writing the script in bash. On the other hand, I sometimes start adding so much functionality to a bash script that eventually it makes more sense to rewrite it in Perl/python rather than deal with bash's limited (by comparison) support for variable scoping, functions, data structures, etc.

share|improve this answer
I used t0 also bail on Bash whenever file reading/text generation was required, but after learning the =~ operator supported by [[ ]] I have been loving me some Bash for simple file reading –  Freedom_Ben May 15 '14 at 20:32

Bash is a Unix shell it includes a scripting language. It is rather command processor. you control the way how you run commands, you actually run them.

Perl/Ruby/Python are general purpose languages.

When you want a shell script, you use Bash

If you want more complex task or not related to shell. Use Python etc.

I would never compare these languages actually. Python etc. are portable. You can run them anywhere. Bash is for Unix only.

Python etc. have tons of reusable libraries solving millions of tasks.

It's almost the same if you ask. "When to use Paint and when to use Photoshop"

For processing emails I would use Ruby, again, because it has a lot of reusable libraries.

But the best way would be combine bash and ruby. That would be right. Like you create a email lrocessor in ruby and bash script would invoke that ruby script and run other commans ds.

So whenever you need command processor you use bash. You run unix commands and control them.

share|improve this answer
Bash's scripting subset is just as general purpose as any general purpose scripting language. Add general programs like sed into the mix, and you got yourself covered for 90% of all scripting needs you'll ever have. –  mkaito Apr 21 '12 at 3:06
bash is a command processor so its power is to run other unix commands and programs in their scripts.like you mentioned sed etc. He is asking for when to choose certain language –  bakytn Apr 21 '12 at 3:16
The shell is a glorified program launcher indeed, but it's scripting capabilities are far beyond that. I suggest you learn some real shell scripting. –  mkaito Apr 21 '12 at 3:34
I can sleep on the floor but i would rather do it on a bed. The languages cant be compared they have dofferent purposes. –  bakytn Apr 21 '12 at 3:50
Well, if Bash is the floor, something like Haskell must be a nailboard :-) –  mkaito Apr 21 '12 at 14:15

I like the criteria set out in this blog post.

  • If there aren’t any arguments to pass in, it’s probably a shell script.
  • If there isn’t much for control logic (besides a single loop or if/else) it’s probably a shell script.
  • If the task is automation of command-line instructions it’s almost definitely a shell script.
share|improve this answer

I found this Perl versus Bash analysis useful...


For convenience, I'm copying a summary of that author's 1) when bash is better findings and 2) when perl is better conclusion...

When Bash is Better...

  • Job Failure
  • Commands on Exit
  • Processing Job Output Lines
  • Here Documents
  • File Equivalencies
  • File Timestamp Comparisons
  • Tilde Expansion

When Perl is Better...

Perl still beats the crap out of bash for most applications. Reasons I might prefer Perl include (but are not limited to):

  • It’s going to be faster. Mainly because I don’t actually have to start new processes for many of the things I want to do (basename and dirname being the most obvious examples, but generally cut, grep, sort, and wc can all be eliminated as well).
  • String handling in bash is rudimentary at best, and the whole $IFS thing is super-clunky.
  • Conditionals in shell scripts can be wonky.
  • Quoting in shell scripts can be a nightmare.
  • bash’s case statement leaves a lot to be desired beyond simple cases (NPI).
  • Arrays in bash suck. Hashes in bash (assuming your bash is new enough to have them at all) suck even harder.
  • Once processing files or command output goes beyond the simple case I listed above, Perl starts really smoking bash.
  • CPAN.

So it’s not like bash is going to take over for Perl any time soon. But I still find, after all these years, that many times a simple shell script can sometimes be simpler than a simple Perl script. As I say, I welcome all attempts to convince me otherwise. But, then again, there’s nothing wrong with having a few different tools in your toolbox.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.