{"id":1970,"date":"2018-10-30T08:01:56","date_gmt":"2018-10-30T08:01:56","guid":{"rendered":"https:\/\/www.appservgrid.com\/paw92\/?p=1970"},"modified":"2018-10-31T09:24:13","modified_gmt":"2018-10-31T09:24:13","slug":"10-practical-grep-command-examples-in-linux","status":"publish","type":"post","link":"https:\/\/www.appservgrid.com\/paw92\/index.php\/2018\/10\/30\/10-practical-grep-command-examples-in-linux\/","title":{"rendered":"10 Practical Grep Command Examples in Linux"},"content":{"rendered":"

Brief: The grep command is used to find patterns in files. This tutorial shows some of the most common grep command examples that would be specifically beneficial for software developers.<\/em><\/p>\n

Recently, I started working with <\/em>Asciidoctor.js<\/a> and on<\/em> the Asciidoctor.js-pug<\/a> and Asciidoctor-templates.js<\/a> project. It is not always easy to be immediately effective when you dig for the first time into a codebase containing several thousand of lines. But my secret weapon to find my way through so many code lines is the grep<\/a> tool.<\/p>\n

I am going to share with you how to use grep command in Linux with examples.<\/p>\n

Using grep commands in Linux<\/h2>\n

\"Grep<\/p>\n

If you look into the man<\/a>, you will see that short description for the grep tool: \u201cprint lines matching a pattern.\u201d<\/em> However, don\u2019t be fooled by such humble definition: grep is one of the most useful tools in the Unix toolbox and there are countless occasions to use it as soon as you work with text files.<\/p>\n

It is always better to have real-world examples to learn how things work. So, I will use the Asciidoctor.js source tree<\/a> to illustrate some of the grep capabilities. You can download that source tree from GitHub, and if you want, you may even check out the same changeset I used when writing this article. That will ensure you obtain results perfectly identical to those described in the rest of this article:<\/p>\n

git clone https:\/\/github.com\/asciidoctor\/asciidoctor.js
\ncd asciidoctor.js
\ngit checkout v1.5.6-rc.1<\/p>\n

1. Find all occurrences of a string (basic usage)<\/h3>\n

Asciidoctor.js is supporting the Nashorn JavaScript engine<\/a> for the Java platform. I do not know Nashorn, so I could take that opportunity to learn more about it by exploring the project parts referencing that JavaScript engine.<\/p>\n

As a starting point, I checked if there were some settings related to Nashorn in the package.json file describing the project dependencies:<\/p>\n

sh$ grep nashorn package.json
\n“test”: “node npm\/test\/builder.js && node npm\/test\/unsupported-features.js && node npm\/test\/jasmine-browser.js && node npm\/test\/jasmine-browser-min.js && node npm\/test\/jasmine-node.js && node npm\/test\/jasmine-webpack.js && npm run test:karmaBrowserify && npm run test:karmaRequirejs && node npm\/test\/nashorn.js”,<\/p>\n

Yes, apparently there was some Nashorn-specific tests. So, let\u2019s investigate that a little bit more.<\/p>\n

2. Case insensitive search in a file set<\/h3>\n

Now, I want to have a closer look at the files from the .\/npm\/test\/ directory mentioning explicitly Nashorn. A case-insensitive search (-i option) is probably better here since I need to find both references to nashorn and Nashorn (or any other combination of upper- and lower-case characters):<\/p>\n

sh$ grep -i nashorn npm\/test\/*.js
\nnpm\/test\/nashorn.js:const nashornModule = require(‘..\/module\/nashorn’);
\nnpm\/test\/nashorn.js:log.task(‘Nashorn’);
\nnpm\/test\/nashorn.js:nashornModule.nashornRun(‘jdk1.8.0’);<\/p>\n

Indeed case insensitivity was useful here. Otherwise, I would have missed the require(‘..\/module\/nashorn’) statement. No doubt I should examine that file in greater details later.<\/p>\n

3. Find non-matching files<\/h3>\n

By the way, is there some non-Nashorm specific files in the npm\/test\/ directory? To answer that question, we can use the \u201cprint non-matching files\u201d option of grep (-L option):<\/p>\n

sh$ grep -iL nashorn npm\/test\/*
\nnpm\/test\/builder.js
\nnpm\/test\/jasmine-browser-min.js
\nnpm\/test\/jasmine-browser.js
\nnpm\/test\/jasmine-node.js
\nnpm\/test\/jasmine-webpack.js
\nnpm\/test\/unsupported-features.js<\/p>\n

Notice how with the -L option the output of grep has changed to display only filenames. So, none of the files above contain the string \u201cnashorn\u201d (regardless of the case). That does not mean they are not somehow related to that technology, but at least, the letters \u201cn-a-s-h-o-r-n\u201d are not present.<\/p>\n

4. Finding patterns into hidden files and recursively into sub-directories<\/h3>\n

The last two commands used a shell glob pattern<\/a> to pass the list of files to examine to the grep command. However, this has some inherent limitations: the star (*) will not match hidden files. Neither it will match files (eventually) contained in sub-directories.<\/p>\n

A solution would be to combine grep with the find<\/a> command instead of relying on a shell glob pattern:<\/p>\n

# This is not efficient as it will spawn a new grep process for each file
\n$ find npm\/test\/ -type f -exec grep -iL nashorn {} ;
\n# This may have issues with filenames containing space-like characters
\ngrep -iL nashorn $(find npm\/test\/ -type f)<\/p>\n

As I mentioned it as comments it the code block above, each of these solutions has drawbacks. Concerning filenames containing space-like characters, I let you investigate the grep -z option which, combined with the -print0 option of the find command, can mitigate that issue. Don\u2019t hesitate to use the comment section at the end of this article to share your ideas on that topic!<\/p>\n

Nevertheless, a better solution would use the \u201crecursive\u201d (-r) option of grep. With that option, you give on the command line the root of your search tree (the starting directory) instead of the explicit list of filenames to examine. With the -r option, grep will examine all files in the search directory, including hidden ones, and then it will recursively descend into any sub-directory:<\/p>\n

grep -irL nashorn npm\/test\/npm\/
\nnpm\/test\/builder.js
\nnpm\/test\/jasmine-browser-min.js
\nnpm\/test\/jasmine-browser.js
\nnpm\/test\/jasmine-node.js
\nnpm\/test\/jasmine-webpack.js
\nnpm\/test\/unsupported-features.js<\/p>\n

Actually, with that option, I could also start my exploration one level above to see in there are non-npm tests that target Nashorn too:<\/p>\n

sh$ grep -irL nashorn npm\/<\/p>\n

I let you test that command by yourself to see its outcome; but as a hint, I can say you should find many more matching files!<\/p>\n

5. Filtering files by their name (using regular expressions)<\/h3>\n

So, there seems to have some Nashorn specific tests in that project. Since Nashorn is Java, another question that could be raised would be \u201cis there some Java source files in the project explicitly mentioning Nashorn?\u201d<\/em>.<\/p>\n

Depending the version of grep you use, there are at least two solutions to answer that question. The first one is to use grep to find all files containing the pattern \u201cnashorn\u201d, then pipe the output of that first command to a second grep instance filtering out non-java source files:<\/p>\n

sh $grep -ir nashorn .\/ | grep “^[^:]*.java”
\n.\/spec\/nashorn\/AsciidoctorConvertWithNashorn.java:public class AsciidoctorConvertWithNashorn {
\n.\/spec\/nashorn\/AsciidoctorConvertWithNashorn.java: ScriptEngine engine = engineManager.getEngineByName(“nashorn”);
\n.\/spec\/nashorn\/AsciidoctorConvertWithNashorn.java: engine.eval(new FileReader(“.\/spec\/nashorn\/asciidoctor-convert.js”));
\n.\/spec\/nashorn\/BasicJavascriptWithNashorn.java:public class BasicJavascriptWithNashorn {
\n.\/spec\/nashorn\/BasicJavascriptWithNashorn.java: ScriptEngine engine = engineManager.getEngineByName(“nashorn”);
\n.\/spec\/nashorn\/BasicJavascriptWithNashorn.java: engine.eval(new FileReader(“.\/spec\/nashorn\/basic.js”));<\/p>\n

The first half of the command should be understandable by now. But what about that \u201c^[^:]*\\.java\u201d part?<\/p>\n

Unless you specify the -F option, grep assumes the search pattern is a regular expression<\/a>. That means, in addition to plain characters that will match verbatim, you have access to a set of metacharacter to describe more complex patterns. The pattern I used above will only match:<\/p>\n