All of the WordPress themes that I work on for iThemes are managed as Git repositories. Recently, we moved past the 100 repositories mark. That’s a lot of repositories to manage, and unfortunately, too many of those repositories contain duplicated information.

Later on, I might delve into how we use Git to manage our theme repos. For today, however, I’d like to focus on how I quickly and easily pushed up changes to more than a dozen repos in a single, albeit long, Bash command.

I had finished making updates to 16 Flexx repos, and I needed to push all of those changes up. Since I had multiple working repos in that folder, I was lucky that each of these repos began with the text “Flexx”. Also, since they are all part of the same series and need to keep the same version number, that simplified the tagging as all could be tagged as 2.5.0.

Given this information, I simply ran the following command from the directory that contained all the repository directories:

There’s a lot going on here, so I’ll break it up and explain what I’m doing.

This is basically a compound command. Bash’s for command is being used to step through the results of ls|grep Flexx. Each result will be stored to the variable i which can be referred to with $i.

In other words, I’m going to loop through each directory that contains the text “Flexx” (technically, it isn’t limited to just directories, but I don’t have any files containing “Flexx”, so I’m safe). For each iteration of the loop, the variable $i will contain the name of the folder I’m interested in.

The most important bit here is do. do simply begins the functional part of the loop and could be followed by any command that I wanted to start the loop with.

The echo command isn’t technically necessary. I simply have it there so that I can better determine what output belongs to which repository.

This is a very important command. It changes the directory to the repository I wish to run commands on.

This is the command that actually does what I want to do in each repo directory. This adds all the modified files, commits them with a message of “2.5.0″, pushes the changes to the remote repository, creates a new tag of 2.5.0, and pushes up the new tag.

I have all of these commands chained together with && so that if one command fails, the other ones won’t run. This prevents tagging in the event that the repository couldn’t be committed or pushed.

It’s a small command but necessary. This switches back to the main directory that holds all the repos, thus returning us back to a state that the next loop iteration can work with.

As with the other echo command, this simply allows me to keep track of what is going on more easily.

The done command finishes out the loop iteration.

I hope that by sharing this you can gain a bit of insight into how I work with repositories while also learning more about how you can do things with Bash.

I’ve had a lot of fun recently posting about how to do stuff on the command line in Linux. My focus is specifically for Ubuntu users, but the information and techniques can be used for any Linux distro.

Since I’m probably going to end up with a lot of content under this topic, I’ve decided to create a dedicated tag: Mastering the Command Line. I’ve gone through my older posts on this topic and tagged them as well. So, make sure to check out Mastering the Command Line if you want to know how to become a command line power user.

Back to today’s topic. You’re starting to learn how to use the command line, but it’s annoying to always have to type in similar commands over and over. If only there were a way to pull up commands that you’ve already run to run again as is or to quickly modify. Today, I’m going to teach you how to do exactly this.

Introduction to BASH Command Line History

BASH (Bourne Again SHell) is the default command line shell that is used in Ubuntu, and most other distros for that matter. The instructions that I give here are specific to BASH and may or may not work in other shells. Since most people don’t modify which shell they access through Terminal, I only point this out to inform those who have changed their shell that their experiences may differ depending on the shell used.

When you close a Terminal session, BASH writes all the commands you’ve run for that session to your ~/.bash_history file. When you load a new session, this file is read and those commands along with the new commands you execute for that session become your new command history.

It’s important to keep in mind that commands executed for a session are only written when you exit. If you have two sessions running concurrently, they cannot cross-reference the newly-executed commands run in the other session. Furthermore, if you force a Terminal session to quit, the command history will not be updated.

Simple Command History Navigation

The easy way to get started with your command history is to simply navigate with the up and down arrow keys. Using the up key, you can scroll through previous commands one command at a time. To scroll back down the list, you can use the down arrow key.

Once you’ve found the desired command, you can treat it as if you’ve typed that command in the command line. You can simply press Enter to execute the command again, or you can modify the command as needed before executing it.

This method is very good for quickly running commands that you have to execute repeatedly without many other commands between.

Listing and Searching Command History

BASH provides the history command that when executed with no options will list the entire command history. Each command will be preceeded with a number that represents that command’s command number. I’ll tell you how to use these numbers below.

You can also have the history command produce just the last certain number of commands by supplying a number. For example, if you want to see the previous ten commands, you can run the following:

Notice that the last command is the same as the command you ran to produce it. So, “history 1″ will just show you “[command number] history 1″.

Searching History

If you remember that you ran a really cool command and can’t quite remember how you did it, combining history with grep provides an easy way to find that command with just a piece of the command.

For example, let’s say that I ran a command that listed all the files that end in “.php” inside the ~/wordpress folder it then filters for just matches that contain the text “link” and then reverses the output. I was quite proud of that command, but I can’t remember how I did it. So, I search through my history.

Since I don’t think that I have the word “link” in many of my commands, I pick it as the target to search for and run the following:

That’s what I was looking for. Now I can bask in the glory of my ingenious command and use it as the inspiration for other inspired words of command line magic.

Running Previous Commands Again

Searching through the history is great and all, but I’d rather not have to copy and paste found commands. I’d like to just run them immediately. BASH to the rescue again.

If you’d like to run the previous command again quickly, you can simply run “!!”. The first exclamation point tells BASH that you are running a previous commands. The second exclamation point tells BASH that it’s the last command that you’d like to run again. It’s a double exclamation point simply to make it quick and easy to type in.

I’ve already shown you how to look through your history and find a specific command in your history complete with the command number. Now is the time to make use of that number. If I wanted to execute command number 510 (which bash) again using the history, I can simply run the following:

Notice how running the command again first lists the actual command and then the output.

BASH substitutes the !number command with the actual command from the history. This allows you to supply additional parameters to the command. The following is a silly example, but it gets the point across.

Notice how the command now has the additional parameter added to the original command. As expected, the full command is listed followed by the command output.

You can also do the standard manipulations such as piping the output, “!412 | grep wp-admin”, or redirecting the output, “!510 > shell_locations.txt”.

Searching and Running Previous Commands

The “!” functionality of BASH also allows you to search through the history and execute the first match.

The basic form of this simply searches for matches at the beginning of the command. “!find” executes the most recent command that begins with “find”.

You can also search the entire command for a match. “!?link?” executes the most recent command that contains “link”.

Advanced History with Regular Expressions

As with many tools in the Linux world, you can attain great power by combining the tool with regular expressions. The history in BASH allows you to run previous commands with a search and replace in Regex fashion.

Let’s take my searching through the ~/wordpress example, command number 412, and run it again with some modifications. This time, instead of searching ~/wordpress, I’d like to search through /home/site/public_hmtl/wordpress. I’d do that with the following:

Note that the search and replace is done by adding “:s|find|replace|” to the end of the history command. I used the pipes, “|”, to deliminate the find and replace portions to make it easier to add the forward slashes, “/”, to the terms. You can also use “:s/find/replace/”.

Closing Thoughts

I hope that you enjoy my Mastering the Command Line series. If you have any command line-specific requests, please leave a comment, and I will see about creating a tutorial on that topic.

Remember, those who forget history, are doomed to repeat it by manual entry.

Did you know that you aren’t limited to working on one thing at a time while on a Linux command line? You can actually “minimize” a program that you are in, get back to the command line, and then return to the program whenever you’d like.

When you run a program or script on the Linux command line (from now on referred to as the shell), you are creating a new job. For those that are used to GUI environments, each of these jobs is somewhat like a window on the desktop. Just as you can have multiple windows and switch between them, the shell is capable of managing multiple jobs and allows you to switch between them.

There is a lot to cover, so let’s start simple by describing what states a shell job can be in.

Jobs States

Foreground Jobs

Up to now, you may have only worked with foreground jobs in the shell. Foreground jobs are ones that don’t return you to the command prompt until you exit out of the job or the job finishes.

If you run “ping yahoo.com” from the shell, the ping process will become a foreground job and will not return you to the command prompt until you stop it.

Just in case you didn’t know, you can stop the ping process by pressing Ctrl+c. Unlike in many applications that you may be used to, Ctrl+c does not mean “copy” in a Linux shell. Instead of copying text, this signals the foreground process to terminate by sending it the SIGINT (Signal Interrupt) signal.

An example of a foreground job that won’t return you to the command prompt until it is finished is the zip command. Imagine that you have a large amount of files inside a folder called “stuff”. If I run “zip -r stuff.zip stuff” and don’t know about job management, I won’t have access to the shell until zip finishes its task and returns me to the prompt.

Background Jobs

Putting a job in the background allows the job to run exactly as if it were in the foreground except that it does not receive user input. If a command produces output and is put in the background, it will still produce the output.

Why would putting a job in the background be helpful then you may wonder. There are a number of reasons, and they will become clear in the examples below.

Stopped Jobs

There is technically a third state that a job can be in. Jobs that aren’t in the foreground yet are also not in the background have been stopped.

Like background jobs, stopped jobs do not receive user input. Unlike background jobs, stopped jobs do not produce output. As a matter of fact, they don’t do anything. They have essentially been put on hold and won’t do any processing until they are resumed or killed.

Multitasking 101: Stopping and Resuming Processes

It may seem like stopped jobs are the odd man out, but they are actually the key to getting started with multitasking on the Linux shell. I use stopped jobs every day, and I couldn’t imagine using the shell without them.

Imagine that you are in your favorite shell text editor working on a program or modifying config files, and you can’t remember what the IP address you need is but you could easily look it up with dig. You could easily open up another shell connection and run the command, but it would be quicker to simply stop the editor, run the command quickly, copy the text, and bring your editor to the foreground.

The following is a sequence that illustrates how this example would look on your shell.

[chris@local ~]$ sudo vi /etc/httpd/conf/httpd.conf
[sudo] password for chris:
Ctrl+z
[1]+  Stopped          sudo vi /etc/httpd/conf/httpd.conf
[chris@local ~]$ dig +short chrisjean.com
96.125.165.12
[chris@local ~]$ fg %1

After running these commands, you will be back in your editor.

The key to stopping a running job is the Ctrl+z key combination. Again, some of you may be used to Ctrl+z as the shortcut to undo, but in the Linux shell, Ctrl+z sends the SIGTSTP (Signal Tty SToP) signal to the foreground job. When you press this key combination, the running program will be stopped and you will be returned to the command prompt.

You may notice the “%1” after fg. The “1″ is the job number that is to be brought to the foreground. The job number is listed in brackets when the job was stopped. These numbers are crucial when you have multiple jobs in stopped states. At any time, you can run “jobs” to get a list of the current jobs.

I stop jobs every day, and it greatly reduces the number of active shell sessions I have running. Sometimes I have stopped jobs that I set up ahead of time when I first access the shell. For example, I may open up a MySQL session, connect it to the database of the site I’m working on, and then stop it. Any time I need to run a query, I can load up the job by running “fg 1“, run the query, and then stop the job again.

Multitasking 202: Running Jobs in the Background

Stopping jobs is great, but what if we want to be returned to the command prompt while still allowing the job to run? Sending a job to the background will do exactly that.

As I talked about in my post about finding files, the locate command is extremely helpful. Sometimes you need to manually run the updatedb command in order for the locate database to update. The problem is that the updatedb command can take a very long time to run, sometimes it can take more than an hour.

I’ll use the example of the updatedb command to show how you can take a foreground process and put it in the background so that you can free up the shell.

[chris@local ~]$ sudo updatedb
[sudo] password for chris:
Ctrl+z
[1]+  Stopped            sudo updatedb
[chris@local ~]$ bg %1
[1]+ sudo updatedb &
[chris@local ~]$ 

There are a few items of note here.

1. I’m back at the command prompt and can do anything I’d like while the job works merrily away in the background.
2. Notice how I used “%1″ with bg just as I did with fg. Both commands accept a job number to tell it which job is to be sent to the foreground/background.
3. After running bg, a line similar to when I pressed Ctrl+z was printed showing the command and job number. However, there is also the addition of the “&” at the end. We’ll get into the reason for that in the next section.

When a process that is running in background finishes, you will receive a message the next time your command prompt refreshes. The prompt refreshes when you run another command or simply hit Enter to get a new prompt.

Continuing from the previous example, I receive output similar to the following when the updatedb command finishes:

[chris@local ~]$ 
[1]+  Done              sudo updatedb
[chris@local ~]$ 

As with all the other job-related output, you will be notified of the job number and the command.

Multitasking 303: Starting Jobs in the Background

Now that you see the value of having jobs run in the background, you might wonder if you can just start the command in the background to begin with. In fact, you can!

Remember that odd ampersand “&” after the command in the output of the bg command? The ampersand means that the job is running in the background. You can run a command with the ampersand at the end to automatically put the job in the background.

Going back to the updatedb example again, we could have simply run the following to have the job in the background and get our command prompt back immediately:

[chris@local ~]$ sudo date
...
[chris@local ~]$ sudo updatedb &
[sudo] password for chris:
[1] 15231
[chris@local ~]$ 

You might wonder what that completely unnecessary “sudo date” command is all about. Remember that when you send a job to the background, it cannot receive input from the user. Since sudo prompts for the password when it hasn’t been run recently, I ran a throwaway command before running the background sudo command to ensure that the password wouldn’t be prompted for. If you do send a sudo command to the background and sudo prompts for a password, you need to bring it to the foreground first to enter the password and then send it to the background again.

The output when sending the job directly to the background is different than running bg. Instead of telling you the command, it tells you the actual process ID. Every program that runs in Linux is a process and has a process ID. You can use these process IDs to kill a specific process, change the process’ execution priority, and isolate the resource utilization by that process.

Even though you’ve put a task in the background, you can still bring it to the foreground using the fg command. In the previous example, I can pull the background process to the foreground by running “fg %1“.

Multitasking Graduate School: Killing and Prioritizing Jobs

Now that you know the fundamentals of managing jobs, it’s time to get more advanced and tell you how to terminate jobs and modify their execution priority.

Terminating Jobs

Sometimes a process goes rogue and either won’t respond to input, is consuming massive amounts of resources, or both. At times like this, it’s very important to know how to kill a job which will cease the program’s execution and free up its used resources.

The command used to kill processes is appropriately called kill. The kill command can accept either process IDs or job numbers (the job number must be preceded by a percent sign, “%”).

If my updatedb job from before fails to respond, the job has a job number of “1″, and I want to tell the job to stop, I could run the following command:

[chris@local ~]$ sudo kill %1
[sudo] password for chris:
[chris@local ~]$ 

Notice that there isn’t any confirmation that the kill command was successful. You can check to ensure that the job has been terminated by running the “jobs” command and looking for that job’s listing.

By default, the kill command sends a SIGTERM (Signal Terminate) signal to the process; however, sometimes this is not enough to stop the execution of an out of control process. To shut down these processes, we need something more powerful.

[chris@local ~]$ sudo kill -9 %1
[sudo] password for chris:
[chris@local ~]$ 

This may not look much different, but the addition of the “-9″ option tells the command that things are serious now. This option causes a SIGKILL (Signal Kill) signal to be sent to the process. A kill signal cannot be intercepted by a process and causes the process to immediately terminate without allowing it to clean up after itself. It’s for this reason that you should only use SIGKILL after first sending the process a SIGTERM.

As mentioned before, you can also run a kill command on a process ID rather than a job number. If we wished to kill a process with a process ID of 12267, we can run the following command:

[chris@local ~]$ sudo kill 12267
[chris@local ~]$ 

Note that you don’t have to always run the kill command with sudo, you just have to ensure that whatever privilege level you are running the kill command at has the ability to control that process. In other words, if you are trying to kill a process run with sudo, you’ll need to use sudo to kill it as well.

Prioritizing Jobs

Linux does a great job of prioritizing tasks automatically; however, what Linux thinks is best isn’t always what you want. Basically, Linux always wants to make a process finish as soon as possible, which means that you get a nice bit of lag when you try to do your work as a CPU or disk hungry process churns away. Fortunately, there are tools that will let you tell Linux what you want.

First, let’s deal with managing a process’ use of CPU time. If you are going to run a command that will eat up large amounts of CPU cycles and you want to make sure that this process doesn’t keep you from doing your work, you can run the command with nice to give the command a lower-than-default priority.

[chris@local ~]$ sudo date
[sudo] password for chris:
Fri Mar  6 10:55:11 CST 2009
[chris@local ~]$ sudo nice updatedb &
[1] 16312
[chris@local ~]$ 

As before, a junk sudo command was run first to take care of the password prompt.

Running the command in nice lowers the processes CPU priority and will result in smoother CPU performance for your other applications.

What if you already ran a command whose process is now greedily chewing away at your CPU resources? That’s where the renice command comes into play.

With renice, you can change the CPU priority of an existing process.

[chris@local ~]$ sudo date
[sudo] password for chris:
Fri Mar  6 10:56:25 CST 2009
[chris@local ~]$ sudo updatedb &
[1] 16324
[chris@local ~]$ sudo renice 10 16324
16324: old priority 0, new priority 10
[chris@local ~]$ 

The renice command accepts a priority as the first argument and the process ID as the second argument. The priority argument has a range from -20 to 19 where -20 is the highest priority and 19 is the lowest. In other words, a higher numeric value priority results in lower CPU priority.

That takes care of the CPU, but admittedly, the updatedb command does more damage to the IO or disk traffic than it does to the processor. How can we reign in a process’ use of the disk so that performance for the rest of the system improves? For that, we use the ionice command.

With the ionice command, you can set the IO priority for a process to one of three classes: Idle (3), Best Effort (2), and Real Time (1). The Idle class means that the process will only be able to read and write to the disk when all other processes are not using the disk. The Best Effort class is the default and has eight different priority levels from 0 (top priority) to 7 (lowest priority). The Real Time class results in the process having first access to the disk irregardless of other process and should never be used unless you know what you are doing.

If we wish to run the updatedb process in the background with an Idle IO class priority, we can run the following:

[chris@local ~]$ sudo date
[sudo] password for chris:
Fri Mar  6 11:02:43 CST 2009
[chris@local ~]$ sudo updatedb &
[1] 16324
[chris@local ~]$ sudo ionice -c3 -p16324
[chris@local ~]$ 

If we’d rather just lower the Best Effort class priority (defaults to 4) for the command so the process isn’t limited to idle IO periods, we can run the following:

[chris@local ~]$ sudo date
[sudo] password for chris:
Fri Mar  6 11:07:12 CST 2009
[chris@local ~]$ sudo updatedb &
[1] 16324
[chris@local ~]$ sudo ionice -c2 -n7 -p16324
[chris@local ~]$ 

Again, the Real Time class should not be used as it can prevent you from being able to interact with your system.

You may wonder where you can get the process ID if you don’t know it, can’t remember it, or didn’t start the process (an automated script may have launched it). You can find process IDs with the ps command.

For example, if I had an updatedb program running in the background, and I wanted to find its process ID, I can run the following:

[chris@local ~]$ ps -C updatedb
PID TTY          TIME CMD
4234 ?        00:00:42 updatedb

This tells me that the process’ process ID (PID) is 4234.

Another useful command is “ps -u user” (replace “user” with your username) which lists all processes your user has access to. Basically, these are processes that your user or some process using your user’s permissions started.

Another really helpful use of ps is “ps aux“. This command will list all the system’s processes, which user owns the process, and even detail the resource usage of the process. This is very helpful for finding processes that you don’t know enough about to find using other methods.

Mutitasking Doctorate: Using Job Management in Scripts

Keep in mind that many scripts execute from inside shell environments. This means that you can manage the script’s job using the tools I’ve given you here.

If you look in the /etc/cron.daily folder, you’ll find many scripts that execute once a day. These scripts can create a huge load on a system while they execute. If around the clock performance is crucial, you can prioritize the shells that the scripts run in which causes all the commands run inside that shell to follow the same prioritization rules.

This all sounds very complex, but it’s actually very simple.

Let’s open up the /etc/cron.daily/mlocate file (pick another file if you don’t have this one). At the top, you should see a line like the following:

This shebang line tells Linux what interpreter is used to execute the script. My example script uses the bash shell as the interpreter. Other scripts may use the sh shell instead of the bash shell, but that won’t make any difference.

Below the first line, put the following:

The $$ variable is a special variable that contains the shell’s own process ID. The two commands above cause the CPU priority to lower to 10 and changes the IO priority to class 3 (Idle).

Add this type of customization to your resource hungry scripts, and your system will perform more smoothly around the clock. Keep in mind that this also can result in the scripts taking much longer to complete.

You can use those same commands above using the $$ variable to change the CPU and IO priority of shells that you open in order to lower the impact you have while working on the system. This can be a smart thing to do if you need to compile software or run other intensive processes on production machines.

Important Commands

Here’s a list of all the commands, key combos, and other important bits that I went over with a brief description for each. It’s like the word list at the end of children’s books.

• fg – Brings a stopped or background job to the foreground
• bg – Sends a stopped job to the background
• jobs – Lists the current jobs and their corresponding job number
• Ctrl+c – Key combination that sends a SIGINT signal to the foreground process. Use this to close processes that don’t stop (such as ping or top) or terminate a process that no longer responds or is no longer needed.
• Ctrl+z – Key combination that sends the SIGTSTP signal to the foreground process. Use this to send a foreground process to a stopped state.
• & – Use an ampersand at the end of a command to send the resulting job to the background immediately
• kill – Sends signals to processes based on process ID or job number. Useful to send SIGTERM or SIGKILL signals to forcibly stop processes.
• nice – Runs the given command with a lower-than-default CPU priority
• renice – Changes an existing process’ CPU priority
• ionice – Changes an existing process’ IO priority

Closing Thoughts

Frankly, I didn’t expect to make such a long post. If this post has helped you, please leave a comment and let me know what you thought.

I’d greatly appreciate it if you’d share the post by using one of the icons below. Or you can click here to Digg this post.

Many of you fellow Ubuntu users will be familiar with the “Search for Files” tool that allows you to look for files. As is true with most things in Linux, there are great desktop tools, but more power can be found in Terminal than any streamlined desktop tool can match.

Today, I’d like to introduce you to a few tools that can turn a chore of finding files into an easy process.

locate

The first tool that you should become comfortable with is also one of the simplest. The locate program works in a similar fashion to most graphical search tools.

Using

Let’s say that you’ve read up on how to modify X to provide enhanced video performance. The document that you are reading says to modify the xorg.conf file, but the document doesn’t say where that is and you don’t know how to find it. You can use locate to find it for you quickly:

Most likely, your system will return a number of results. For example, on one of my systems, I receive the following output:

It’s clear that /etc/X11/xorg.conf is the file we’re looking for, but what if dozens or even hundreds of results were returned? How could you manage all of that? If you know a little bit about regular expressions (every Linux user really should learn the basics), you can easily use regular expressions to search for directories or files. For example, we can search for an exact match for xorg.conf with the following command:

locate -r '/xorg.conf$'

If you want to look for files without case sensitivity, you can use the ‘-i’ option. For example:

locate -i 'monthly report'

Something that may confuse you when you first start using locate is that it not only returns matches, but if the match is a directory, it also lists all of the directories and files under that directory. To stop this behavior, use the ‘-b’ option. For example:

This will return a much shorter list of results than if you did not include the ‘-b’ option and all the matches will contain the search term as the final portion of the path.

Important Note

The locate command relies on a slocate database to function. This database caches the file system directory and file names and allows the locate command to operate in moments rather than taking long periods of time to search the entire file system.

This ability doesn’t come without cost though. By default, your system will run a command to update this database once a day at 6:25am. This command will update the database with any changes made to the file system since the last update.

If you’ve made changes recently, such as added or removed large amounts of files and directories, and you want to use the locate command to search through these new directories and files, you can manually update the slocate database at any time with the following command:

Depending on the volume of changes made since the slocate database was last updated, this could take a few seconds to a few minutes to update. Once it’s done, you’re ready to search again with locate.

which

locate is great for searching the entire file system. However, sometimes you just want to find where a command lives. That’s where which comes into play.

which only does one thing, but it does it well. Given the name of a command, which will tell you where the file for that command resides in the file system.

Let’s imagine that we want to find out where there firefox command resides. We can simply run the following to find out:

On my system, and most likely on your’s as well, which will tell us that it is located at /usr/bin/firefox.

Why would you ever want to search specifically for a command? Imagine that you have some code that needs to replace an old command. You really need to remove the the old one (I usually rename it to the same name followed by “.bak” to keep it around in case I need it) first before putting the new one in its place. which will help you find the file quickly and easily so you don’t have to search everywhere to find it.

whereis

The whereis command is similar to which but goes one step further. Not only does it tell you where the executable file is located at, but it will also locate the source, man page, and other associated directories as well.

Keeping with the which example, let’s ask whereis about the firefox command:

On my system, I get the following output:

This helped me find /usr/lib/firefox/plugins earlier when working on the solution for Flash. That location is where the global add-ons for Firefox are stored.

find

find is the ultimate search tool, the Swiss Army knife of Linux search if you will. find can do everything from search for files based on last modified times, owners and groups, permissions, type (file, directory, symbolic link, etc), whether the file is readable/writable/executable by the current user, file size, whether the file or directory is empty, and much more. You can also search for matches by regular expression.

When you use this tool in combination with the xargs command (which I’ll have to cover some other time), you can do truly amazing things on the command line. Imagine being able to recursively search through the current directory for files ending with “.bak” that were last modified more than 100 days ago and then deleting them with one command:

find . -name '*.bak' -type f -mtime +100 -print0 | xargs -0 /bin/rm -f

It will look very complex at first, but when you master the art of using find, it will become second nature. Soon, you’ll wonder how you ever searched for things without it.

To be frank, there is much more to find than I am willing to cover and there are many, many great introductions to the tool that do a better job than I would. So, I’ll simply point you to three great references that can be used to get going with find.

• Example uses of the Linux Command find
• (I apologize for the horrible colors in advance) Unix/Linux “find” Command Tutorial
• Using the find command

You just got your new CentOS dedicated server, and you notice that times in your logs aren’t quite right. You check the time from the command line (run “date”), and find that the timezone is set to US Eastern or some other timezone. How do you get this changed?

Unfortunately, this is not an easy thing to figure out. Fortunately though, it’s not hard to do with the right directions.

Please note that you have to have root access to be able to make the changes detailed below.

There are a series of time zone files located at /usr/share/zoneinfo. Select the appropriate named timezone for your location. For my location, Oklahoma, USA, I actually have two that I can select from: America/Chicago or US/Central. Make note of the appropriate folder and file for your timezone.

The active timezone used on your system is in the /etc/localtime file. The default will vary depending on your server host but often seems to be EST or EDT (depending on the time of year you are checking). We simply need to replace this file with the file we selected in the previous step.

Now, I say replace, but I actually recommend creating a link to the pertinent file rather than actually making a copy. Let me explain the reasoning for this quickly.

A crucial part of the timezone shift calculations is the daylight savings calculations. Many people don’t realize this, but the daylight savings days were changed in 2007. When this change happened, all servers needed to be updated with new zoneinfo files.

If your server has an automated process to update these files when daylight savings calculations change, your /usr/share/zoneinfo files will be updated but the /etc/localtime file will not be. So, if you simply made a copy of the file, you’ll have to know when these updates come out and manually copy the file over. If you create a link, everything will take care of itself.

Enough of the banter. On with the show.

First, make a backup of the existing localtime file. It’s always good practice to make backups of original config files.

Next, create the link:

Make sure to replace “America/Chicago” with the directory (if your zone has one) and filename of the timezone you wish to use.

Now you just need to test your change. Run “date” from the command line, and ensure that the appropriate time, date, and timezone are reported.

Here’s a quick tip that will help you work with multiple zip files on the command line.

If you are in a folder and have three zip files in it (a.zip, b.zip, c.zip) that you want to unzip, “no problem,” you think, “I can take care of that with one command.” So, you quickly run the following:

However, rather than having the unzip program nicely unzip each file one after another, you receive the following:

I’m sure that this is not what you were expecting. I know I certainly wasn’t expecting this when I first tried it. However, this problem can help us understand more of how the command line works.

The Problem

Whenever you use a wildcard (*), the shell itself will expand that and pass the results to the program rather than the program handling the expansion itself. That means that our previous command was actually expanded to the following before being executed:

Again, this may not look odd since other programs (such as mkdir, chmod, etc) can take one or more arguments and repeat the process for each. However, unzip is different and actually has use for the additional arguments. If you specify additional arguments after the zip file name, unzip will try to only extract those specific files from the archive rather than all the files.

The previous command told unzip that it should extract b.zip and c.zip from inside the a.zip archive. Since those files don’t exist inside a.zip, we get the nasty output seen earlier.

You might think that you will have to manually unzip each archive one at a time, but you’d be wrong.

The Solution

Just because the shell expands out wildcard characters automatically doesn’t mean that programs can’t as well. The simple solution to this problem is to quote the argument to prevent the shell from interpreting it:

That’s all there is to it. I’ve seen solutions from coding loops in bash script to running find combined with xargs, but none of that is necessary. Simply let unzip itself take care of things for you.