How to make scripts you actually reuse

Shell scripts are great for many reasons, but one of the most tangible benefits is simple: you can stop running the same long, obscure commands over and over again. You might have a text file of commands that you copy and paste, or you might find yourself on Stack Overflow searching for the same thing every day.

Overcome these bad habits, learn how to script your shell, and reclaim valuable time.

Be intimate with your shell

If you’re undertaking any serious type of scripting, you’ll need to know your shell. It’s probably bash, but it could also be zsh, or even the old original shell, sh (the Thompson shell).

You may have even changed your shell to something completely different, like dash or fish. Regardless of which shell you use, you need to read its manual and know its syntax and capabilities. POSIX shells, such as bash, ksh, and zsh, are widely compatible, but each can introduce its own additional features.

As you explore, you’ll likely discover aspects of the hull that are completely new or that you’ve heard about but never fully understood. This can range from special characters to expansion rules and test patterns.

Identify common tasks

This one seems obvious, but deciding what to write will be the most important factor in how much time you save by doing it. If you can speed up a task you do daily, that’s a big win, but if it’s something you’ll only do once, it’s not worth investing too much time into it.

THE history The command is a good way to see what other commands you run the most. You can go through it manually or create a small pipeline to get summary information:

history | sed 's/^ *[0-9]* *//' | cut -d' ' -f1 | sort | uniq -c | sort -n

This will retrieve the first word of each command you have run, count the instances, and sort them to show the last most frequent one:

This can help point you in the right direction and can even tell you how well you’re using existing scripts you’ve written. Here’s a similar command that will tell you a little bit about which man pages you read the most:

history | sed 's/^ *[0-9]* *//' | cut -d' ' -f1- | grep ^man | sort | uniq -c | sort -n

For example, on my system it tells me I’m using man to get help with cp, git, strftime, jq and ls. I know the ls command has many options, so any scripts I can write to help encapsulate some of the more obscure ones will probably be worth it.

Use good names

I’ve found that one of the biggest obstacles to replacing a command or using a new program is simply remembering it. THE ls the command is burned into my brain and muscle memory, but I find ezaa modern alternative, too obscure to remember; that name just doesn’t say “list files” to me.

There are ways to fix this problem for third-party programs. You can use an alias, for example:

alias list=eza

This isn’t perfect though, as it doesn’t rename the man page or help other users, but for your own purposes it may be a useful workaround. However, there’s no excuse for your own scripts, so give them good names to start. Here are some tips:

• Shorter names are always easier to use, as long as you can associate them with the task your script is performing.

• Names that exploit existing knowledge are practical. THE lsd program is another ls alternative that is much easier to remember; it even benefits from tab completion.

• On the other hand, if your script has a short, single prefix, it will be easier to tab complete it. My system has over 60 commands starting with “co”, but only 12 starting with “q” – and one of them is my own script!

• Scripts should always be named in lowercase. There’s no better way to lose a script than to give it an initial capital letter.

• Prefer commands without extension. If you save your script as foo.sh, create an alias or symbolic link named “foo”. Not only is it cleaner, but it’s also easier to change the extension, if you rewrite the script in a different language, for example.

Related

I automated Linux backups with a simple bash and cron script (and it’s better than a GUI)

Skip one-click backup apps. This rsync script gives you full control over what is recorded and when, as well as logs and some hard-earned lessons.

Keep them in a reasonable place

You can place your scripts wherever you want, but to run them easily you will need to place them in a named directory in your PATH variable.

If you are writing scripts for multiple users to run on a single system, you must place them in /usr/local/bin. This follows the standard Linux directory structure.

Your personal scripts belong in your home directory, not a global directory like /bin or /usr/bin. The traditional location was ~/bin, which you may need to create. If you don’t like seeing too many directories at home, you can use a hidden one: ~/.bin.

The last convention is to follow the XDG specification and use a folder like ~/.local/bin. You may already have this directory, even if you don’t know it, with third-party software inside.

Related

This IDE made me a better programmer

One IDE to rule them all. You won’t want to use anything else.

Use functions for more maintainable code

When your scripts exceed a certain size (usually beyond one or two pages), they can become cumbersome, with repeated code and unnecessary duplication. Any code you repeat is likely to be passed into a function, reducing the overall size of your script and making it more maintainable.

There are two main forms of syntax for declaring a function:

foo() {
}

function foo {
}

I recommend the first style, which is a bit shorter and more widely compatible. Regardless of the style, you will access the parameters in the same way as your main script, that is, using $1 for the first parameter, $2 for the second, and so on. You can call a function the same way you would call any command:

foo param1 param2

Another advantage of writing functions is that you can reuse them within and within scripts. You can import a file containing shell functions by searching for it:

. ./shell-functions.sh

As with all programming, comments are a valuable feature that you should neither overuse nor underuse. It is essential to comment on any parts of your code that might be difficult to understand later, even if these parts are ideally kept to a minimum.

In shell scripts, comments start with a # symbol. They can appear anywhere on a line and always extend to the end of the line:

Comments can be particularly useful for documenting the parameters expected by a function, because they are not explicitly declared:

# $1 the post URL
twitter() {
}