This is part one of what will likely turn into a long running series of posts on Why I Love Linux (WILL). The idea of WILL is to share little bits of what makes me love working with Linux. These could be small simple things such as a little feature here or there, the design concept behind Linux, or some other random thing.

I hope that by sharing what it is that I love about Linux, readers can learn a thing or two along the way.

To kick off this new series, I’m going to talk about one of the first command line tools that you should familiarize yourself with in Linux: grep.

What is grep?

Put simply, grep is a program that takes a pattern to match, a list of options, and a list of files to search through and gives you a list of each file that matches the pattern and options you gave it in addition to the specific line in the file that matched.

At first, this sounds boring and you may think that you can think of a use here or there for it, but in fact, this is one of the most useful command line programs in all of Linux (in my humble opinion that is).

Maybe the best way to show this is with some examples of how I use grep on a day by day basis.

Examples

Finding Functions in WordPress Core

Since I’m a PHP developer and often work with WordPress, I frequently need to search the WordPress core for where functions are defined, where actions are added or called, or where global variables are first defined. Fortunately, grep comes to the rescue.

Let’s say that I want to know what code is behind the sanitize_title_with_dashes() function. I’ll change directories to where my WordPress installation is and run the following:

grep -r 'function &*sanitize_title_with_dashes' .

A quick description of what I’ve asked is: Search files for lines that contain “function &*sanitize_title_with_dashes”. Show me every match found in all the files and directories recursively starting at the current directory.

Just so you know, the asterisk (*) after the ampersand (&) means that the ampersand is optional. That’s right, grep supports regular expression format search queries. The reason why it is there is because some of the WordPress functions are preceded with an ampersand since they return variables by reference rather than by value. Adding this makes sure that your search finds these when you may not know if the function returns by reference or not.

After running the command, grep comes back and tells me:

wp-includes/formatting.php:function sanitize_title_with_dashes($title) {

So I instantly know what file has my function definition. If only I had the line number as well. That’s no problem. I’ll just slightly modify my grep command:

grep -rn 'function &*sanitize_title_with_dashes' *

Notice the new ‘n’ option. This option says to show the line number of the match. The result is:

wp-includes/formatting.php:502:function sanitize_title_with_dashes($title) {

Now I know that the function definition starts on line 502.

Finding Examples of Using a Specific WordPress Function

Another common case of using grep while coding for WordPress is needing to find examples of how the WordPress dev team have used certain functions. So, how do I find where these code examples are? grep of course.

I need to find out how to properly use the wp_schedule_single_event() function. I change directories to the WordPress install directory and quickly run the following:

grep -rn 'wp_schedule_single_event(' .

Which results in:

wp-admin/includes/upgrade.php:625: wp_schedule_single_event(mysql2date('U', $post->post_date), 'publish_future_post', array($post->ID));
wp-includes/cron.php:22:function wp_schedule_single_event( $timestamp, $hook, $args = array()) {
wp-includes/post.php:1646: wp_schedule_single_event( $time, 'publish_future_post', array( $post_id ) );
wp-includes/post.php:3131: wp_schedule_single_event(strtotime($post->post_date_gmt. ' GMT'), 'publish_future_post', array($post->ID));
wp-includes/post.php:3161: wp_schedule_single_event(time(), 'do_pings');

This looks great, but I’d rather not have the function definition in the middle of the results. Fortunately, grep comes to the rescue again. The key is to pipe the results from this grep command into another grep command.

grep -rn 'wp_schedule_single_event(' . | grep -v 'function &*wp_schedule_single_event'

There are three things to notice here:

  1. I’m using the pipe operator, |, to use the output of the first command as the input for the second command.
  2. I’m giving the second grep command the option of -v. This option tells grep to reverse the match to show the non-matching lines rather than the matching ones.
  3. You may have missed this in previous commands, but I have a period at the very end of each search request. This is where I tell grep to search, and the . means the current path.The second command in this example does not have this location to search. It’s not needed as the second grep command uses the output of the piped first command as its input.

The resulting output is the same as before without the function reference:

wp-admin/includes/upgrade.php:625: wp_schedule_single_event(mysql2date('U', $post->post_date), 'publish_future_post', array($post->ID));
wp-includes/post.php:1646: wp_schedule_single_event( $time, 'publish_future_post', array( $post_id ) );
wp-includes/post.php:3131: wp_schedule_single_event(strtotime($post->post_date_gmt. ' GMT'), 'publish_future_post', array($post->ID));
wp-includes/post.php:3161: wp_schedule_single_event(time(), 'do_pings');

That looks much better. Now I know where to look for examples of how the WordPress developers used the function. This will make it much easier for me to use it as well.

Searching Through syslog

There is a log file at /var/log/syslog that stores generic logging information for many programs that don’t have their own specific log file. Synergy, the program I used to share my keyboard and mouse with multiple of my computers logs to /var/log/syslog. I want to quickly look through the log and see the recent logged information from Synergy, so I run the following command:

grep -i 'synergy' /var/log/syslog

There are a few things new about this command:

  1. I no longer have the -r option on the command. -r means recursive. Since we are only searching a file and not a list of directories and their files, we don’t need the -r option.
  2. I added a new option, -i. grep searching is done in a case-sensitive manner. Adding the -i option tells grep to ignore case while searching.
  3. Rather than using the . for the search location, I’m searching an actual file. Notice that I don’t have to be in the /var/log directory to search a file located in that directory.

I get the following results:

Jan 20 18:42:53 rommie Synergy 1.3.1: NOTE: synergyc.cpp,330: started client
Jan 20 18:42:53 rommie Synergy 1.3.1: WARNING: synergyc.cpp,265: failed to connect to server: cannot connect socket: Network is unreachable
Jan 20 18:42:54 rommie Synergy 1.3.1: WARNING: synergyc.cpp,265: failed to connect to server: cannot connect socket: Network is unreachable
Jan 20 18:42:57 rommie Synergy 1.3.1: WARNING: synergyc.cpp,265: failed to connect to server: cannot connect socket: Network is unreachable
Jan 20 18:43:02 rommie Synergy 1.3.1: WARNING: synergyc.cpp,265: failed to connect to server: cannot connect socket: Network is unreachable
Jan 20 18:43:17 rommie Synergy 1.3.1: NOTE: synergyc.cpp,247: connected to server
Jan 20 21:05:27 rommie Synergy 1.3.1: NOTE: synergyc.cpp,330: started client
Jan 20 21:05:27 rommie Synergy 1.3.1: WARNING: synergyc.cpp,265: failed to connect to server: cannot connect socket: Network is unreachable
Jan 20 21:05:28 rommie Synergy 1.3.1: WARNING: synergyc.cpp,265: failed to connect to server: cannot connect socket: Network is unreachable
Jan 20 21:05:31 rommie Synergy 1.3.1: WARNING: synergyc.cpp,265: failed to connect to server: cannot connect socket: Network is unreachable
Jan 20 21:05:36 rommie Synergy 1.3.1: WARNING: synergyc.cpp,265: failed to connect to server: cannot connect socket: Network is unreachable
Jan 20 21:05:51 rommie Synergy 1.3.1: NOTE: synergyc.cpp,247: connected to server

It looks like I’ve been having some problems tonight. I better check on that.

Conclusion

grep is an extremely powerful command. When you get into more advanced command line operations, you’ll find yourself often chaining a grep command or two in the command to assist other programs. So, gaining a solid working knowledge of grep now is the first step to being a command line power user.

grep has many more options than I’ve shown here. At the terminal, run man grep to get a full listing of options that are available with grep. Trying out the options as practice from time to time is a great way to get conditioned to what grep is capable of so you know that you have that ability when the need arises for a certain option.

If you’d like more information about grep or would like some more examples, please let me know.

Did I help you?