Two Simple Tricks with Shell Scripts To Improve Your Productivity [Linux]

One of the best things about the Linux command line is your ability to put together scripts that make your life easier. At its most basic level, a shell script is a list of commands executed one after another, as if you typed them yourself at the command line. While shell (for example, Bash shell) programming can be just as complex as programming in other languages, it is easier to pick up a few basic tricks that you can use to make yourself more efficient.

Note: While you should be able to use these tips immediately, MTE has an excellent Beginner’s Guide to Writing Linux Shell Scripts you can reference for more detail.

You’ll already have everything you need to take advantage of these tricks on any modern Linux distribution: a text editor and a shell (we’ll be using the Bash shell here). Open your text editor, and you’re ready to script away. You’ll be saving the scripts as plain text files… some people favor using an “.sh” file extension to help identify scripts.

You’ll also need to learn a little bit about the syntax, or format of shell scripts. One thing you’ll need to remember is to put the following line at the top of each script:

When you run a script at the command prompt, this line tells your current shell which other shell to use to run it, if they’re different. The other thing you’ll need to remember is to make your script executable, which we’ll do in a moment. But for now, let’s create a new, useful script.

The Beginners Guide above does a great job of explaining variables, and showing you how to take arguments (any words/phrases you type after the command’s name) and use them. But you can also use what are called “environment variables” to change things about how your programs run. For example, I’m a Japanese speaker, and while Linux programs can handle the input of Japanese, sometimes I get nostalgic for the Japanese UI. There is an environment variables for “Locale,” which define in what language programs are displayed. For example, if I want to go back to my web browsing days in Japan, I’d use the following:

But I often forget whether that environment variable should be “LANG,” “LC_TYPE,” or one of the other 10 local-related variables. I’d rather just “Japanize it.” So I created a Bash script called “jpit” as follows:

This will show the translated Japanese menus and interface (you can see the English UI below at left, and the result when launched by “jpit” at right).

firefox english

firefox japanese

Then, I simply made the script executable with the following:

I placed this in my ~/bin directory because this is in my PATH, and I can now execute this from any terminal or KRunner, and insert any application name that accepts the “LANG” variable. You can use a script like this to run a program with a different set of options, whether they’re environment variables, command line flags, or input/output files.

There are some times I find myself executing a number of the same commands, in the same order, in a row. The following comes immedately to mind:

Fortunately, there’s a way to issue these as one command, then “walk away” until they all complete:

The && in this command signifies that the second command should only be run after the first, and only if the first completes without errors. The apt-get commands above will probably ask you if you want to install some dependencies, though, so how is this useful?

Let’s go back to our old friend, Pandoc. We’ve seen in previous articles that Pandoc has options to convert Markdown into other, different formats. But what if you want to do convert it to HTML, ODT, DOCX, and an e-book all at once? Simple: create a shell script with the following:

This will take whatever Markdown document you give it as an argument, and generate each of the desired formats by running the Pandoc command one format at a time. One command, four end products. Now that’s efficiency!

You can even combine the above to options to create all kinds of useful scripts. Because even though we all love the command line, there’s no reason to spend more time at it than you have to…