Friday, November 16, 2012

Jenkins pattern for e-mailing log fragments

https://issues.apache.org/jira/browse/LUCENE-4092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel


Steven Rowe added a comment - 30/May/12 21:16
Editable Email Notification/Default Content configuration for the Lucene-Solr-tests-only-trunk job:
Build: ${BUILD_URL}

${FAILED_TESTS}

Build Log (for compile errors):
${BUILD_LOG_REGEX,regex="\\[javac\\]\\s+\\d+ error(s*)\\b",linesBefore=100,linesAfter=0}
Dawid Weiss added a comment - 30/May/12 21:22
Yeah, but what is ${FAILED_TESTS}? I mean – can we edit it to detect "<<< FAILURES!" and report 100 lines before this string?
Steven Rowe added a comment - 30/May/12 21:47
Yeah, but what is ${FAILED_TESTS}? I mean – can we edit it to detect "<<< FAILURES!" and report 100 lines before this string?
Jenkins's Content Token Reference
All arguments are optional. Arguments may be given for each token in the form name="value" for strings and in the form name=value for booleans and numbers. The {'s and }'s may be omitted if there are no arguments.
Examples: $TOKEN, ${TOKEN}, ${TOKEN, count=100}, ${ENV, var="PATH"}
Available Tokens
  • ${DEFAULT_SUBJECT} - This is the default email subject that is configured in Jenkins's system configuration page.
  • ${DEFAULT_CONTENT} - This is the default email content that is configured in Jenkins's system configuration page.
  • ${PROJECT_DEFAULT_SUBJECT} - This is the default email subject for this project. The result of using this token in the advanced configuration is what is in the Default Subject field above. WARNING: Do not use this token in the Default Subject or Content fields. Doing this has an undefined result.
  • ${PROJECT_DEFAULT_CONTENT} - This is the default email content for this project. The result of using this token in the advanced configuration is what is in the Default Content field above. WARNING: Do not use this token in the Default Subject or Content fields. Doing this has an undefined result.
  • ${BUILD_LOG, maxLines, escapeHtml} - Displays the end of the build log.
    • maxLines - display at most this many lines of the log.
      Defaults to 250.
    • escapeHtml - If true, HTML is escaped.
      Defaults to false.
  • ${BUILD_LOG_REGEX, regex, linesBefore, linesAfter, maxMatches, showTruncatedLines, substText, escapeHtml, matchedLineHtmlStyle} - Displays lines from the build log that match the regular expression.
    • regex - Lines that match this regular expression are included. See also java.util.regex.Pattern
      Defaults to "(?i)\b(error|exception|fatal|fail(ed|ure)|un(defined|resolved))\b".
    • linesBefore - The number of lines to include before the matching line. Lines that overlap with another match or linesAfter are only included once.
      Defaults to 0.
    • linesAfter - The number of lines to include after the matching line. Lines that overlap with another match or linesBefore are only included once.
      Defaults to 0.
    • maxMatches - The maximum number of matches to include. If 0, all matches will be included.
      Defaults to 0.
    • showTruncatedLines - If true, include ...truncated ### lines... lines.
      Defaults to true.
    • substText - If non-null, insert this text into the email rather than the entire line.
      Defaults to null.
    • escapeHtml - If true, escape HTML.
      Defaults to false.
    • matchedLineHtmlStyle - If non-null, output HTML. matched lines will become <b style="your-style-value">html escaped matched line</b>.
      Defaults to null.
  • ${BUILD_LOG_EXCERPT, start, end} - Displays an excerpt from the build log.
    • start - Regular expression to match the excerpt starting line to be included (exluded). See java.util.regex.Pattern
    • end - Regular expression to match the excerpt ending line to be included (exluded)
  • ${BUILD_NUMBER} - Displays the number of the current build.
  • ${BUILD_STATUS} - Displays the status of the current build. (failing, success, etc...)
  • ${BUILD_URL} - Displays the URL to the current build.
  • ${CHANGES, showPaths, showDependencies, format, pathFormat} - Displays the changes since the last build.
    • showDependencies - if true, changes to projects this build depends on are shown.
      Defaults to false.
    • showPaths - if true, the paths modified by a commit are shown.
      Defaults to false.
    • format - for each commit listed, a string containing %X, where %X is one of %a for author, %d for date, %m for message, %p for paths, or %r for revision. Not all revision systems support %d and %r. If specified, showPaths is ignored.
      Defaults to "[%a] %m\n".
    • pathFormat - a string containing %p to indicate how to print paths.
      Defaults to "\t%p\n".
  • ${CHANGES_SINCE_LAST_SUCCESS, reverse, format, showPaths, changesFormat, pathFormat} - Displays the changes since the last successful build.
    <ul>
    • reverse - indicates that most recent builds should be at the top.
      Defaults to false.
    • format - for each build listed, a string containing %X, where %X is one of %c for changes, or %n for build number.
      Defaults to "Changes for Build #%n\n%c\n".
    • showPaths, changesFormat, pathFormat - defined as showPaths, format, and pathFormat from ${CHANGES}, respectively.
  • ${CHANGES_SINCE_LAST_UNSTABLE, reverse, format, showPaths, changesFormat, pathFormat} - Displays the changes since the last unstable or successful build.
    • reverse - indicates that most recent builds should be at the top.
      Defaults to false.
    • format - for each build listed, a string containing %X, where %X is one of %c for changes, or %n for build number.
      Defaults to "Changes for Build #%n\n%c\n".
    • showPaths, changesFormat, pathFormat - defined as showPaths, format, and pathFormat from ${CHANGES}, respectively.
  • ${ENV, var} - Displays an environment variable.
    • var - the name of the environment variable to display. If "", show all.
      Defaults to "".
  • ${FAILED_TESTS, showStack, maxTests} - Displays failing unit test information, if any tests have failed.
    • showStack - indicates that most recent builds should be at the top.
      Defaults to true.
    • maxTests - display at most this many failing tests.
      No limit is set by default.
  • ${JENKINS_URL} - Displays the URL to the Jenkins server. (You can change this on the system configuration page.)
  • ${HUDSON_URL} - deprecated, please use $JENKINS_URL
  • ${PROJECT_NAME} - Displays the project's name.
  • ${PROJECT_URL} - Displays a URL to the project's page.
  • ${SVN_REVISION} - Displays the subversion revision number.
  • ${CAUSE} - Displays the cause of the build.
  • ${JELLY_SCRIPT, template} - Custom message content generated from a Jelly script template. There are two templates provided: "html" and "text". Custom Jelly templates should be placed in $JENKINS_HOME/email-templates. When using custom templates, the template filename without ".jelly" should be used for the "template" argument.
    • template - the template name.
      Defaults to "html".
  • ${FILE, path} - Includes the content of a specified file.
    • path - The path to the file. Relative to the workspace root.
  • ${TEST_COUNTS, var} - Displays the number of tests.
    • var - Defaults to "total".
      • total - the number of all tests.
      • fail - the number of failed tests.
      • skip - the number of skipped tests.
  • ${SCRIPT, script, template, init} - Custom message content generated from a script using JSR 223. Custom scripts should be placed in $JENKINS_HOME/email-templates. When using custom scripts, the script filename WITH .py/.rb/etc should be used for the "script" argument.
    templates and other items may be loaded using the host.readFile(String fileName) function
    the function will look in the resources for the email-ext plugin first, and then in the $JENKINS_HOME/email-templates directory. No other directories will be searched.
    • script - the script name.
      Defaults to "email-ext.groovy".
    • template - the template filename.
      Defaults to "groovy-html.template"
    • init - true to run the language's init script.
      Defaults to true
    • Available Script Engines
      • ECMAScript - 1.8 (js)
      • Groovy - 1.8.5 (groovy)
Dawid Weiss added a comment - 30/May/12 21:59
Ok, so BUILD_LOG_REGEX should do! I don't know Jenkins but any failed test (suite) will have the "<<< FAILURES!" marker attached – feel free to experiment 
Steven Rowe added a comment - 30/May/12 22:13
I'll switch it to the following - hopefully it will capture everything (any length multiline) between the suite header and "<<< FAILURES!"
Build: ${BUILD_URL}

${FAILED_TESTS}

Build Log (for compile errors):
${BUILD_LOG_REGEX,regex="(?s:\\[java4\\]\\s*Suite:.*?<<<\\s*FAILURES!)"}
Steven Rowe added a comment - 30/May/12 22:19
regex="(?s:\\[java4\\]\\s*Suite:.*?<<<
s*FAILURES!)"
Hmm, that won't work - it'll grab everything from the first "Suite:" to "<<< FAILURES!", including any number of (non-failing) Suite mentions inbetween.
I guess "<<< FAILURES!" and 100 previous lines will work, but I'd rather get the exact region. I'll work on it.
Dawid Weiss added a comment - 30/May/12 22:28
This will be a killer regexp, I can feel it 
Robert Muir added a comment - 30/May/12 22:33
Is there also a way we could improve the output of other checks (e.g. the javadocs warnings task, two javadocs checkers in javadocs-lint, and the rat-checker)
so that if it causes a build failure its included as well, rather than just "No tests ran" or "All tests passed" or whatever it does today?
Robert Muir added a comment - 30/May/12 22:34
By the way: I'm not suggesting to make the regex even more hairy, i'm just wondering if we can modify these tasks
so that when they fail, they can include certain symbols/stuff to ensure they are included in the summary...
Steven Rowe added a comment - 30/May/12 22:54
This one seems to work (from Perl against a recent Jenkins log with a failure):
[^\r\n]*\[junit4\]\s*Suite:.*[\r\n]+[^\r\n]*\[junit4\]\s*(?!Completed)(?!IGNOR)\S(?s:.*?)<<<\s*FAILURES!
I'll change the Lucene-Solr-tests-only-trunk job configuration to use it (after escaping backslashes).
Steven Rowe added a comment - 30/May/12 23:04
Is there also a way we could improve the output of other checks (e.g. the javadocs warnings task, two javadocs checkers in javadocs-lint, and the rat-checker)
so that if it causes a build failure its included as well, rather than just "No tests ran" or "All tests passed" or whatever it does today?
It may be that alternates can be added to the BUILD_LOG_REGEX - I'll look at the output and see if any changes need to be made to enable that.
Steven Rowe added a comment - 31/May/12 18:00
I plan on adding the following (as suggested by Robert) as alternations to the BUILD_LOG_REGEX for all non-Maven Jenkins jobs (some of these things don't run under the Maven jobs, and Maven's output is different enough that it'll require separate treatment):
the javadocs warnings task
(?:[^\r\n]*\[javadoc\].*\r?\n)*[^\r\n]*\[javadoc\]\s*[1-9]\d*\s+warnings.*\r?\n
two javadocs checkers in javadocs-lint
Output from javadocs-lint seems to show up only when there's a problem, so any output from it will always be extracted by the following regex:
[^\r\n]*javadocs-lint:.*\r?\n(?:[^\r\n]*\[echo\].*\r?\n)*
and the rat-checker
[^\r\n]*rat-sources:\s+\[echo\].*(?:\r?\n[^\r\n]*\[echo\].*)*\s*[1-9]\d*\s+Unknown\s+Licenses.*\r?\n(?:[^\r\n]*\[echo\].*\r?\n)*
Along with two others:
  1. Compilation failures:
    (?:[^\r\n]*\[javac\].*\r?\n)*[^\r\n]*\[javac\]\s*[1-9]\d*\s*error.*\r?\n
    
  2. Jenkins FATAL errors:
    [^\r\n]*FATAL:(?s:.*)
    
Steven Rowe added a comment - 31/May/12 18:18
I plan on adding the following (as suggested by Robert) as alternations to the BUILD_LOG_REGEX for all non-Maven Jenkins jobs
Done. Here's the full Editable Email Notification/Default Content configuration:
Build: ${BUILD_URL}

${FAILED_TESTS}

Build Log:
${BUILD_LOG_REGEX,regex="(?x:
# Compilation failures
(?:[^\\r\\n]*\\[javac\\].*\\r?\\n)*[^\\r\\n]*\\[javac\\]\\s*[1-9]\\d*\\s*error.*\\r?\\n
# Test failures
|[^\\r\\n]*\\[junit4\\]\\s*Suite:.*[\\r\\n]+[^\\r\\n]*\\[junit4\\]\\s*(?!Completed)(?!IGNOR)\\S(?s:.*?)<<<\\s*FAILURES!
# License problems
|[^\\r\\n]*rat-sources:\\s+\\[echo\\].*(?:\\r?\\n[^\\r\\n]*\\[echo\\].*)*\\s*[1-9]\\d*\\s+Unknown\\s+Licenses.*\\r?\\n(?:[^\\r\\n]*\\[echo\\].*\\r?\\n)*
# Javadocs warnings
|(?:[^\\r\\n]*\\[javadoc\\].*\\r?\\n)*[^\\r\\n]*\\[javadoc\\]\\s*[1-9]\\d*\\s+warnings.*\\r?\\n
# Other javadocs problems (broken links and missing javadocs)
|[^\\r\\n]*javadocs-lint:.*\\r?\\n(?:[^\\r\\n]*\\[echo\\].*\\r?\\n)*
# Jenkins problems
|[^\\r\\n]*FATAL:(?s:.*)
)"}
Steven Rowe added a comment - 31/May/12 18:44
I'm going to add one more to the regex:
# Third-party dependency license/notice problems
|[^\\r\\n]*validate:.*\\r?\\n[^\\r\\n]*\\[echo\\].*\\r?\\n(?:[^\\r\\n]*\\[licenses\\].*\\r?\\n)*[^\\r\\n]*\\[licenses\\].*[1-9]\\d*\\s+error.*\\r?\\n
Steven Rowe added a comment - 31/May/12 18:48
I'm going to add one more to the regex
Done - added to the configuration on all non-Maven Jenkins jobs
Robert Muir added a comment - 31/May/12 19:15
awesome! thank you!
Dawid Weiss added a comment - 31/May/12 21:09
Thanks for working on this, Steve. It'll really be useful.
Steven Rowe added a comment - 31/May/12 23:08
Two problems:
  1. Spreading the BUILD_LOG_REGEX regex value over multiple lines is not supported by Jenkins's email templating functionality, which is provided by the Jenkins Email Extension Plugin (email-ext) https://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin. See the configuration token parsing regexes in ContentBuilder.Tokenizer, in particular the comment over thestringRegex field:
    // Sequence of (1) not \ " CR LF and (2) \ followed by non line terminator
    private static final String stringRegex = "\"([^\\\\\"\\r\\n]|(\\\\.))*\"";

    This could be fixed by allowing line terminators to be escaped:
    // Sequence of (1) not \ " CR LF and (2) \ followed by any non-CR/LF character or (CR)LF
    private static final String stringRegex = "\"([^\\\\\"\\r\\n]|(\\\\(?:.|\r?\n)))*\"";

    I submitted a Jenkins JIRA issue for this: https://issues.jenkins-ci.org/browse/JENKINS-13976.
  2. BuildLogRegexContent, the content parser for BUILD_LOG_REGEX, matches line-by-line, so regexes targeting multiple lines will fail. I can see two possible routes to address this:
    1. The BUILD_LOG_EXCERPT token allows specification of begin/end line regexes, and includes everything inbetween matches. I'm doubtful this will enable capture of the stuff we want, though.
    2. I'll try to add an argument to BUILD_LOG_REGEX to enable multi-line content matching, and make a pull request/JIRA issue to get it included in the next release of the plugin.
In the mean time, I'll switch the configuration in our Jenkins jobs to the following:
Build: ${BUILD_URL}

${FAILED_TESTS}

Build Log:
${BUILD_LOG_REGEX,regex="[ \\t]*(?:\\[javac\\]\\s+[1-9]\\d*\\s+error|\\[junit4\\].*<<<\\s+FAILURES!|\\[javadoc\\]\\s+[1-9]\\d*\\s+warning).*",linesBefore=100}
${BUILD_LOG_REGEX,regex="[ \\t]*\\[echo\\].*)*\\s*[1-9]\\d*\\s+Unknown\\s+Licenses.*",linesBefore=17,linesAfter=20}
${BUILD_LOG_REGEX,regex="[ \\t]*javadocs-lint:.*",linesBefore=0,linesAfter=75}
${BUILD_LOG_REGEX,regex=".*FATAL:.*",linesBefore=0,linesAfter=100}
Michael McCandless added a comment - 01/Jun/12 00:03
Steve you are a regexp God.
Steven Rowe added a comment - 01/Jun/12 03:02
I'll switch the configuration in our Jenkins jobs to the following ...
Done.
Steven Rowe added a comment - 01/Jun/12 20:50
This one had syntax problems (a recent test failure notification email complained about it):
${BUILD_LOG_REGEX,regex="[ \\t]*\\[echo\\].*)*\\s*[1-9]\\d*\\s+Unknown\\s+Licenses.*",linesBefore=17,linesAfter=20}
I switched it to the following on all non-Maven Jenkins job configuratinos:
${BUILD_LOG_REGEX,regex="[ \\t]*\\[echo\\]\\s+[1-9]\\d*\\s+Unknown\\s+Licenses.*",linesBefore=17,linesAfter=20}
Steven Rowe added a comment - 01/Jun/12 20:54 - edited
Spreading the BUILD_LOG_REGEX regex value over multiple lines is not supported by Jenkins's email templating functionality
[...]
This could be fixed by allowing line terminators to be escaped:
[...]
I submitted a Jenkins JIRA issue for this: https://issues.jenkins-ci.org/browse/JENKINS-13976.
I forked the email-ext project on github and made a pull request, which has now been incorporated into the upstream project.
Steven Rowe added a comment - 05/Jun/12 18:56 - edited
BuildLogRegexContent, the content parser for BUILD_LOG_REGEX, matches line-by-line, so regexes targeting multiple lines will fail. [...] I'll try to add an argument to BUILD_LOG_REGEX to enable multi-line content matching, and make a pull request/JIRA issue to get it included in the next release of the plugin.
I made a new content token named BUILD_LOG_MULTILINE_REGEX in my fork of the email-ext-plugin - see JENKINS-14000. My pull request (#40) was merged into the upstream project a few days ago, so the next release will include this change. (Looks like this plugin releases once a month or so, so the wait before we can use it shouldn't be too long, assuming the plugins on the ASF Jenkins instance are kept up-to-date.)
Dawid Weiss added a comment - 07/Jun/12 13:47
Assigning to you, Steven, since you do the heavy lifting here anyway. Thanks!
Dawid Weiss made changes - 07/Jun/12 13:47
FieldOriginal ValueNew Value
AssigneeSteven Rowe [ steve_rowe ]
Steven Rowe added a comment - 16/Jun/12 16:39
v2.22 of the Jenkins Email-ext plugin was released today, incorporating the new BUILD_LOG_MULTILINE_REGEX content token functionality. Olivier Lamy kindly upgraded the plugin in ASF Jenkins and restarted it.
I'm going to re-try using the full-log multiline regex I posted in comment-13286757, with modification I've since added to Lucene jobs' configurations (using multiple BUILD_LOG_REGEX content tokens, one per context window a.k.a. linesBefore/linesAfter).
Hopefully now we'll be able to get exactly the right snippet from the logs for each failure case.
Steven Rowe added a comment - 16/Jun/12 17:58 - edited
Here is the Editable Email Notification/Default Content configuration I applied to all non-Maven ASF Jenkins jobs (modulo whitespace in front of the trailing line-continuation backslashes):
edit: BUILD_LOG_REGEX -> BUILD_LOG_MULTILINE_REGEX
Build: ${BUILD_URL}

${FAILED_TESTS}

Build Log:
${BUILD_LOG_MULTILINE_REGEX,regex="(?x:                                                                                      \
# Compilation failures                                                                                             \
(?:.*\\[javac\\].*\\r?\\n)*.*\\[javac\\]\\s+[1-9]\\d*\\s+error.*\\r?\\n                                            \
# Test failures                                                                                                    \
|.*\\[junit4\\]\\s*Suite:.*[\\r\\n]+.*\\[junit4\\]\\s*(?!Completed)(?!IGNOR)\\S(?s:.*?)<<<\\s*FAILURES!            \
# Source file license problems                                                                                     \
|.*rat-sources:.*(?:\\r?\\n.*\\[echo\\].*)*\\s+[1-9]\\d*\\s+Unknown\\s+Licenses.*\\r?\\n(?:.*\\[echo\\].*\\r?\\n)* \
# Third-party dependency license problems - include 2 preceding lines and 1 following line                         \
|(?:.*\\r?\\n){2}.*\\[licenses\\]\\s+MISSING\\s+sha1(?:.*\\r?\\n){2}                                               \
# Javadoc warnings                                                                                                 \
|(?:.*\\[javadoc\\].*\\r?\\n)*.*\\[javadoc\\]\\s*[1-9]\\d*\\s+warnings.*\\r?\\n                                    \
# Other javadocs problems: broken links and missing javadocs                                                       \
|.*javadocs-lint:.*\\r?\\n(?:.*\\[echo\\].*\\r?\\n)*                                                               \
# Thread dumps - include 1 preceding line and the remainder of the log                                             \
|.*\\r?\\n.*Full thread dump(?s:.*)                                                                                \
# Jenkins problems - include the remainder of the log                                                              \
|.*(?:FATAL|ERROR):(?s:.*)                                                                                         \
# Include the Ant call stack - include the remainder of the log                                                    \
|.*BUILD\\s+FAILED(?s:.*)                                                                                          \
)"}
Steven Rowe added a comment - 16/Jun/12 18:14
${BUILD_LOG_REGEX,regex="(?x: [...]
Ack! I forgot to switch the previous version to use the new BUILD_LOG_MULTILINE_REGEX content token!
Fixed now...
Dawid Weiss made changes - 06/Jul/12 11:43
ParentLUCENE-3784 [ 12542552 ]
Issue TypeSub-task [ 7 ]Task [ 3 ]
Steven Rowe added a comment - 30/Jul/12 13:34
A bug effectively prevented use of the new BUILD_LOG_MULTILINE_REGEX config: JENKINS-14132. The fix on that issue has been incorporated in v2.24.1 of the Email-ext plugin, and Olivier Lamy has kindly installed this version on ASF Jenkins. Uwe helped work out the kinks, and has been running the patched version for a while on his Jenkins instance - upgraded to the release version now.
I will close as fixed later today once it's clear the ASF configuration is functional.
Steven Rowe added a comment - 30/Jul/12 13:41
Here's the current configuration regex (edited so that the trailing backslashes are lined up):
Build Log:
${BUILD_LOG_MULTILINE_REGEX,regex="(?x:                                                                         \
                                                                                                                \
(?:.*\\[javac\\]\\s++(?![1-9]\\d*\\s+error).*\\r?\\n)*+.*\\[javac\\]\\s+[1-9]\\d*\\s+error.*\\r?\\n             \
                                                                                                                \
|.*\\[(?:junit4:)?junit4\\]\\s+Suite:.*+\\s++.*\\[(?:junit4:)?junit4\\]\\s++(?!Completed)(?!IGNOR).*\\r?\\n     \
 (?:.*\\[(?:junit4:)?junit4\\]\\s++(?!Completed\\s+.*<<<\\s*FAILURES!).*\\r?\\n)*+                              \
 .*\\[(?:junit4:)?junit4\\]\\s++Completed\\s+.*<<<\\s*FAILURES!\\r?\\n                                          \
                                                                                                                \
|.*rat-sources:.*\\r?\\n                                                                                        \
 (?:\\s*+\\[echo\\]\\s*\\r?\\n|\\s*+\\[echo\\]\\s++(?![1-9]\\d*\\s+Unknown\\s+License)\\S.*\\r?\\n)*+           \
 \\s*+\\[echo\\]\\s+[1-9]\\d*\\s+Unknown\\s+License.*\\r?\\n                                                    \
 (?:\\s*+\\[echo\\].*\\r?\\n)*+                                                                                 \
                                                                                                                \
|(?:.*\\r?\\n){2}.*\\[licenses\\]\\s+MISSING\\s+sha1(?:.*\\r?\\n){2}                                            \
                                                                                                                \
|.*check-licenses:.*\\r?\\n\\s*\\[echo\\].*\\r?\\n\\s*\\[licenses\\]\\s+MISSING\\s+LICENSE.*\\r?\\n             \
 (?:\\s*+\\[licenses\\].*\\r?\\n)++                                                                             \
                                                                                                                \
|(?:.*\\[javadoc\\]\\s++(?![1-9]\\d*\\s+warning).+\\r?\\n)*+.*\\[javadoc\\]\\s+[1-9]\\d*\\s+warning.*\\r?\\n    \
                                                                                                                \
|.*javadocs-lint:.*\\r?\\n(?:.*\\[exec\\].*\\r?\\n)*+                                                           \
                                                                                                                \
|.*check-forbidden-apis:.*\\r?\\n                                                                               \
 (?:\\s*+\\[forbidden-apis\\]\\s*\\r?\\n                                                                        \
  |\\s*+\\[forbidden-apis\\]\\s++(?!Scanned\\s+\\d+\\s+class\\s+file\\(s\\))\\S.*\\r?\\n)*+                     \
 \\s*+\\[forbidden-apis\\]\\s++Scanned\\s+\\d+\\s+class\\s+file\\(s\\).*[1-9]\\d*\\s+error\\(s\\)\\.\\r?\\n     \
                                                                                                                \
|.*\\r?\\n.*Full\\s+thread\\s+dump(?s:.*+)                                                                      \
                                                                                                                \
|.*(?:FATAL|ERROR):(?s:.*+)                                                                                     \
                                                                                                                \
|.*BUILD\\s+FAILED(?s:.*+)                                                                                      \
)"}
Steven Rowe added a comment - 30/Jul/12 22:55
ASF Jenkins build log excerpts in notification emails are looking good.
Steven Rowe made changes - 30/Jul/12 22:55
StatusOpen [ 1 ]Resolved [ 5 ]
ResolutionFixed [ 1 ]

Tuesday, November 13, 2012

DOS Alias

http://www.ibm.com/developerworks/forums/thread.jspa?threadID=112117


Here's an extract (with screen shots ommitted) from an email I sent to my co-worker after I setup a use of a doskey file.

I created a "doskey" file that defines aliases "ct" and "mt", for command-line use in "cmd" windows.
The file is on a Samba share available to all users at:
\\cmsrv\SJVBSCMSRV\POLICY\Tools\dk.bat

For starters, the only line in the file are:
doskey ct=cleartool $*
doskey mt=multitool $*
doskey credmap="C:\Program Files\Rational\ClearCase\etc\utils\credmap.exe" $*
doskey creds="C:\Program Files\Rational\ClearCase\etc\utils\creds.exe" $*
However, we can add to it as we please.

To use the file, open the "Properties" of your shortcut to "cmd".
On the "Properties" window, select the "Shortcut" tab. The default "Target" is:

%SystemRoot%\system32\cmd.exe

Append the following to it:

/q /k \\cmsrv\SJVBSCMSRV\POLICY\Tools\dk.bat

to give:

%SystemRoot%\system32\cmd.exe /q /k \\cmsrv\SJVBSCMSRV\POLICY\Tools\dk.bat

Then select "OK" or "Apply".

Regards,
Dan R.

Friday, November 2, 2012

Regular Expressions in Grep Command with 10 Examples

http://www.thegeekstuff.com/2011/01/regular-expressions-in-grep-command/


Regular expressions are used to search and manipulate the text, based on the patterns. Most of the Linux commands and programming languages use regular expression.
Grep command is used to search for a specific string in a file. Please refer our earlier article for 15 practical grep command examples.
You can also use regular expressions with grep command when you want to search for a text containing a particular pattern. Regular expressions search for the patterns on each line of the file. It simplifies our search operation.

This articles is part of a 2 article series.
This part 1 article covers grep examples for simple regular expressions. The future part 2 article will cover advanced regular expression examples in grep.
Let us take the file /var/log/messages file which will be used in our examples.

Example 1. Beginning of line ( ^ )

In grep command, caret Symbol ^ matches the expression at the start of a line. In the following example, it displays all the line which starts with the Nov 10. i.e All the messages logged on November 10.
$ grep "^Nov 10" messages.1
Nov 10 01:12:55 gs123 ntpd[2241]: time reset +0.177479 s
Nov 10 01:17:17 gs123 ntpd[2241]: synchronized to LOCAL(0), stratum 10
Nov 10 01:18:49 gs123 ntpd[2241]: synchronized to 15.1.13.13, stratum 3
Nov 10 13:21:26 gs123 ntpd[2241]: time reset +0.146664 s
Nov 10 13:25:46 gs123 ntpd[2241]: synchronized to LOCAL(0), stratum 10
Nov 10 13:26:27 gs123 ntpd[2241]: synchronized to 15.1.13.13, stratum 3
The ^ matches the expression in the beginning of a line, only if it is the first character in a regular expression. ^N matches line beginning with N.


Example 2. End of the line ( $)

Character $ matches the expression at the end of a line. The following command will help you to get all the lines which ends with the word “terminating”.
$ grep "terminating.$" messages
Jul 12 17:01:09 cloneme kernel: Kernel log daemon terminating.
Oct 28 06:29:54 cloneme kernel: Kernel log daemon terminating.
From the above output you can come to know when all the kernel log has got terminated. Just like ^ matches the beginning of the line only if it is the first character, $ matches the end of the line only if it is the last character in a regular expression.

Example 3. Count of empty lines ( ^$ )

Using ^ and $ character you can find out the empty lines available in a file. “^$” specifies empty line.
$ grep -c  "^$" messages anaconda.log
messages:0
anaconda.log:3
The above commands displays the count of the empty lines available in the messages and anaconda.log files.

Example 4. Single Character (.)

The special meta-character “.” (dot) matches any character except the end of the line character. Let us take the input file which has the content as follows.
$ cat input
1. first line
2. hi hello
3. hi zello how are you
4. cello
5. aello
6. eello
7. last line
Now let us search for a word which has any single character followed by ello. i.e hello, cello etc.,
$ grep ".ello" input
2. hi hello
3. hi zello how are you
4. cello
5. aello
6. eello
In case if you want to search for a word which has only 4 character you can give grep -w “….” where single dot represents any single character.

Example 5. Zero or more occurrence (*)

The special character “*” matches zero or more occurrence of the previous character. For example, the pattern ’1*’ matches zero or more ’1′.
The following example searches for a pattern “kernel: *” i.e kernel: and zero or more occurrence of space character.
$ grep "kernel: *." *
messages.4:Jul 12 17:01:02 cloneme kernel: ACPI: PCI interrupt for device 0000:00:11.0 disabled
messages.4:Oct 28 06:29:49 cloneme kernel: ACPI: PM-Timer IO Port: 0x1008
messages.4:Oct 28 06:31:06 btovm871 kernel:  sda: sda1 sda2 sda3
messages.4:Oct 28 06:31:06 btovm871 kernel: sd 0:0:0:0: Attached scsi disk sda
.
.
In the above example it matches for kernel and colon symbol followed by any number of spaces/no space and “.” matches any single character.

Example 6. One or more occurrence (\+)

The special character “\+” matches one or more occurrence of the previous character. ” \+” matches at least one or more space character.
If there is no space then it will not match. The character “+” comes under extended regular expression. So you have to escape when you want to use it with the grep command.
$ cat input
hi hello
hi    hello how are you
hihello

$ grep "hi \+hello" input
hi hello
hi    hello how are you
In the above example, the grep pattern matches for the pattern ‘hi’, followed by one or more space character, followed by “hello”.
If there is no space between hi and hello it wont match that. However, * character matches zero or more occurrence.
“hihello” will be matched by * as shown below.
$ grep "hi *hello" input
hi hello
hi    hello how are you
hihello
$

Example 7. Zero or one occurrence (\?)

The special character “?” matches zero or one occurrence of the previous character. “0?” matches single zero or nothing.
$ grep "hi \?hello" input
hi hello
hihello
“hi \?hello” matches hi and hello with single space (hi hello) and no space (hihello).
The line which has more than one space between hi and hello did not get matched in the above command.

Example 8.Escaping the special character (\)

If you want to search for special characters (for example: * , dot) in the content you have to escape the special character in the regular expression.
$ grep "127\.0\.0\.1"  /var/log/messages.4
Oct 28 06:31:10 btovm871 ntpd[2241]: Listening on interface lo, 127.0.0.1#123 Enabled

Example 9. Character Class ([0-9])

The character class is nothing but list of characters mentioned with in the square bracket which is used to match only one out of several characters.
$ grep -B 1 "[0123456789]\+ times" /var/log/messages.4
Oct 28 06:38:35 btovm871 init: open(/dev/pts/0): No such file or directory
Oct 28 06:38:35 btovm871 last message repeated 2 times
Oct 28 06:38:38 btovm871 pcscd: winscard.c:304:SCardConnect() Reader E-Gate 0 0 Not Found
Oct 28 06:38:38 btovm871 last message repeated 3 times
Repeated messages will be logged in messages logfile as “last message repeated n times”. The above example searches for the line which has any number (0to9) followed by the word “times”. If it matches it displays the line before the matched line and matched line also.
With in the square bracket, using hyphen you can specify the range of characters. Like [0123456789] can be represented by [0-9]. Alphabets range also can be specified such as [a-z],[A-Z] etc. So the above command can also be written as
$ grep -B 1 "[0-9]\+ times" /var/log/messages.4

Example 10. Exception in the character class

If you want to search for all the characters except those in the square bracket, then use ^ (Caret) symbol as the first character after open square bracket. The following example searches for a line which does not start with the vowel letter from dictionary word file in linux.
$ grep -i  "^[^aeiou]" /usr/share/dict/linux.words
1080
10-point
10th
11-point
12-point
16-point
18-point
1st
2
First caret symbol in regular expression represents beginning of the line. However, caret symbol inside the square bracket represents “except” — i.e match except everything in the square bracket.

---------
In our previous regular expression part 1 article, we reviewed basic reg-ex with practical examples.
But we can do much more with the regular expressions. You can often accomplish complex tasks with a single regular expression instead of writing several lines of codes.

When applying a regex to a string, the regex engine will start at the first character of the string. It will try all possible permutations of the regular expression at the first character. Only if all possibilities have been tried and found to fail, will the regex engine continue with the second character in the text.
The regex will try all possible permutations of the regex, in exactly the same order. The result is that the regex-directed engine will return the leftmost match.
In this article, let us review some advanced regular expression with examples.

Example 1. OR Operation (|)

Pipe character (|) in grep is used to specify that either of two whole subexpressions occur in a position. “subexpression1|subexpression2″ matches either subexpression1 or subexpression2.
The following example will remove three various kind of comment lines in a file using OR in a grep command.
First, create a sample file called “comments”.
$ cat comments
This file shows the comment character in various programming/scripting languages
### Perl / shell scripting
If the Line starts with single hash symbol,
then its a comment in Perl and shell scripting.
' VB Scripting comment
The line should start with a single quote to comment in VB scripting.
// C programming single line comment.
Double slashes in the beginning of the line for single line comment in C.
The file called “comments” has perl,VB script and C programming comment lines. Now the following grep command searches for the line which does not start with # or single quote (‘) or double front slashes (//).
$ grep  -v "^#\|^'\|^\/\/" comments
This file shows the comment character in various programming/scripting languages
If the Line starts with single hash symbol,
then its a comment in Perl and shell scripting.
The line should start with a single quote to comment in VB scripting.
Double slashes in the beginning of the line for single line comment in C.

Example 2. Character class expression

As we have seen in our previous regex article example 9, list of characters can be mentioned with in the square brackets to match only one out of several characters. Grep command supports some special character classes that denote certain common ranges. Few of them are listed here. Refer man page of grep to know various character class expressions.
[:digit:]  Only the digits 0 to 9
[:alnum:]  Any alphanumeric character 0 to 9 OR A to Z or a to z.
[:alpha:]  Any alpha character A to Z or a to z.
[:blank:]  Space and TAB characters only.
These are always used inside square brackets in the form [[:digit:]]. Now let us grep all the process Ids of ntpd daemon process using appropriate character class expression.
$ grep -e "ntpd\[[[:digit:]]\+\]" /var/log/messages.4
Oct 28 11:42:20 gstuff1 ntpd[2241]: synchronized to LOCAL(0), stratum 10
Oct 28 11:42:20 gstuff1 ntpd[2241]: synchronized to 15.11.13.123, stratum 3
Oct 28 12:33:31 gstuff1 ntpd[2241]: synchronized to LOCAL(0), stratum 10
Oct 28 12:50:46 gstuff1 ntpd[2241]: synchronized to 15.11.13.123, stratum 3
Oct 29 07:55:29 gstuff1 ntpd[2241]: time reset -0.180737 s

Example 3. M to N occurences ({m,n})

A regular expression followed by {m,n} indicates that the preceding item is matched at least m times, but not more than n times. The values of m and n must be non-negative and smaller than 255.
The following example prints the line if its in the range of 0 to 99999.
$ cat  number
12
12345
123456
19816282

$ grep  "^[0-9]\{1,5\}$" number
12
12345
The file called “number” has the list of numbers, the above grep command matches only the number which 1 (minimum is 0) to 5 digits (maximum 99999).
Note: For basic grep command examples, read 15 Practical Grep Command Examples.

Example 4. Exact M occurence ({m})

A Regular expression followed by {m} matches exactly m occurences of the preceding expression. The following grep command will display only the number which has 5 digits.
$ grep  "^[0-9]\{5\}$" number
12345

Example 5. M or more occurences ({m,})

A Regular expression followed by {m,} matches m or more occurences of the preceding expression. The following grep command will display the number which has 5 or more digits.
$ grep "[0-9]\{5,\}" number
12345
123456
19816282
Note: Did you know that you can use bzgrep command to search for a string or a pattern (regular expression) on bzip2 compressed files.

Example 6. Word boundary (\b)

\b is to match for a word boundary. \b matches any character(s) at the beginning (\bxx) and/or end (xx\b) of a word, thus \bthe\b will find the but not thet, but \bthe will find they.
# grep -i "\bthe\b" comments
This file shows the comment character in various programming/scripting languages
If the Line starts with single hash symbol,
The line should start with a single quote to comment in VB scripting.
Double slashes in the beginning of the line for single line comment in C.

Example 7. Back references (\n)

Grouping the expressions for further use is available in grep through back-references. For ex, \([0-9]\)\1 matches two digit number in which both the digits are same number like 11,22,33 etc.,
# grep -e '^\(abc\)\1$'
abc
abcabc
abcabc
In the above grep command, it accepts the input the STDIN. when it reads the input “abc” it didnt match, The line “abcabc” matches with the given expression so it prints. If you want to use Extended regular expression its always preferred to use egrep command. grep with -e option also works like egrep, but you have to escape the special characters like paranthesis.
Note: You can also use zgrep command to to search inside a compressed gz file.

Example 8. Match the pattern “Object Oriented”

So far we have seen different tips in grep command, Now using those tips, let us match “object oriented” in various formats.
$ grep "OO\|\([oO]bject\( \|\-\)[oO]riented\)"
The above grep command matches the “OO”, “object oriented”, “Object-oriented” and etc.,

Example 9. Print the line “vowel singlecharacter samevowel”

The following grep command print all lines containing a vowel (a, e, i, o, or u) followed by a single character followed by the same vowel again. Thus, it will find eve or adam but not vera.
$ cat input
evening
adam
vera

$ grep "\([aeiou]\).\1" input
evening
adam

Example 10. Valid IP address

The following grep command matches only valid IP address.
$ cat input
15.12.141.121
255.255.255
255.255.255.255
256.125.124.124

$ egrep  '\b(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?\.){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)' input
15.12.141.121
255.255.255.255
In the regular expression given above, there are different conditions. These conditioned matches should occur three times and one more class is mentioned separately.
  1. If it starts with 25, next number should be 0 to 5 (250 to 255)
  2. If it starts with 2, next number could be 0-4 followed by 0-9 (200 to 249)
  3. zero occurence of 0 or 1, 0-9, then zero occurence of any number between 0-9 (0 to 199)
  4. Then dot character


7 Linux Grep OR, Grep AND, Grep NOT Operator Examples

http://www.thegeekstuff.com/2011/10/grep-or-and-not-operators/


Question: Can you explain how to use OR, AND and NOT operators in Unix grep command with some examples?
Answer: In grep, we have options equivalent to OR and NOT operators. There is no grep AND opearator. But, you can simulate AND using patterns. The examples mentioned below will help you to understand how to use OR, AND and NOT in Linux grep command.

The following employee.txt file is used in the following examples.
$ cat employee.txt
100  Thomas  Manager    Sales       $5,000
200  Jason   Developer  Technology  $5,500
300  Raj     Sysadmin   Technology  $7,000
400  Nisha   Manager    Marketing   $9,500
500  Randy   Manager    Sales       $6,000
You already knew that grep is extremely powerful based on these grep command examples.

Grep OR Operator

Use any one of the following 4 methods for grep OR. I prefer method number 3 mentioned below for grep OR operator.

1. Grep OR Using \|

If you use the grep command without any option, you need to use \| to separate multiple patterns for the or condition.
grep 'pattern1\|pattern2' filename
For example, grep either Tech or Sales from the employee.txt file. Without the back slash in front of the pipe, the following will not work.
$ grep 'Tech\|Sales' employee.txt
100  Thomas  Manager    Sales       $5,000
200  Jason   Developer  Technology  $5,500
300  Raj     Sysadmin   Technology  $7,000
500  Randy   Manager    Sales       $6,000

2. Grep OR Using -E

grep -E option is for extended regexp. If you use the grep command with -E option, you just need to use | to separate multiple patterns for the or condition.
grep -E 'pattern1|pattern2' filename
For example, grep either Tech or Sales from the employee.txt file. Just use the | to separate multiple OR patterns.
$ grep -E 'Tech|Sales' employee.txt
100  Thomas  Manager    Sales       $5,000
200  Jason   Developer  Technology  $5,500
300  Raj     Sysadmin   Technology  $7,000
500  Randy   Manager    Sales       $6,000

3. Grep OR Using egrep

egrep is exactly same as ‘grep -E’. So, use egrep (without any option) and separate multiple patterns for the or condition.
egrep 'pattern1|pattern2' filename
For example, grep either Tech or Sales from the employee.txt file. Just use the | to separate multiple OR patterns.
$ egrep 'Tech|Sales' employee.txt
100  Thomas  Manager    Sales       $5,000
200  Jason   Developer  Technology  $5,500
300  Raj     Sysadmin   Technology  $7,000
500  Randy   Manager    Sales       $6,000

4. Grep OR Using grep -e

Using grep -e option you can pass only one parameter. Use multiple -e option in a single command to use multiple patterns for the or condition.
grep -e pattern1 -e pattern2 filename
For example, grep either Tech or Sales from the employee.txt file. Use multiple -e option with grep for the multiple OR patterns.
$ grep -e Tech -e Sales employee.txt
100  Thomas  Manager    Sales       $5,000
200  Jason   Developer  Technology  $5,500
300  Raj     Sysadmin   Technology  $7,000
500  Randy   Manager    Sales       $6,000

Grep AND

5. Grep AND using -E ‘pattern1.*pattern2′

There is no AND operator in grep. But, you can simulate AND using grep -E option.
grep -E 'pattern1.*pattern2' filename
grep -E 'pattern1.*pattern2|pattern2.*pattern1' filename
The following example will grep all the lines that contain both “Dev” and “Tech” in it (in the same order).
$ grep -E 'Dev.*Tech' employee.txt
200  Jason   Developer  Technology  $5,500
The following example will grep all the lines that contain both “Manager” and “Sales” in it (in any order).
$ grep -E 'Manager.*Sales|Sales.*Manager' employee.txt
Note: Using regular expressions in grep is very powerful if you know how to use it effectively.

6. Grep AND using Multiple grep command

You can also use multiple grep command separated by pipe to simulate AND scenario.
grep -E 'pattern1' filename | grep -E 'pattern2'
The following example will grep all the lines that contain both “Manager” and “Sales” in the same line.
$ grep Manager employee.txt | grep Sales
100  Thomas  Manager    Sales       $5,000
500  Randy   Manager    Sales       $6,000

Grep NOT

7. Grep NOT using grep -v

Using grep -v you can simulate the NOT conditions. -v option is for invert match. i.e It matches all the lines except the given pattern.
grep -v 'pattern1' filename
For example, display all the lines except those that contains the keyword “Sales”.
$ grep -v Sales employee.txt
200  Jason   Developer  Technology  $5,500
300  Raj     Sysadmin   Technology  $7,000
400  Nisha   Manager    Marketing   $9,500
You can also combine NOT with other operator to get some powerful combinations.
For example, the following will display either Manager or Developer (bot ignore Sales).
$ egrep 'Manager|Developer' employee.txt | grep -v Sales
200  Jason   Developer  Technology  $5,500
400  Nisha   Manager    Marketing   $9,500

15 Practical Grep Command Examples In Linux / UNIX


You should get a grip on the Linux grep command.
This is part of the on-going 15 Examples series, where 15 detailed examples will be provided for a specific command or functionality.  Earlier we discussed 15 practical examples for Linux find command,  Linuxcommand line history and mysqladmin command.


In this article let us review 15 practical examples of Linux grep command that will be very useful to both newbies and experts.


First create the following demo_file that will be used in the examples below to demonstrate grep command.
$ cat demo_file
THIS LINE IS THE 1ST UPPER CASE LINE IN THIS FILE.
this line is the 1st lower case line in this file.
This Line Has All Its First Character Of The Word With Upper Case.

Two lines above this line is empty.
And this is the last line.

1. Search for the given string in a single file

The basic usage of grep command is to search for a specific string in the specified file as shown below.
Syntax:
grep "literal_string" filename
$ grep "this" demo_file
this line is the 1st lower case line in this file.
Two lines above this line is empty.

2. Checking for the given string in multiple files.

Syntax:
grep "string" FILE_PATTERN

This is also a basic usage of grep command. For this example, let us copy the demo_file to demo_file1. The grep output will also include the file name in front of the line that matched the specific pattern as shown below. When the Linux shell sees the meta character, it does the expansion and gives all the files as input to grep.
$ cp demo_file demo_file1

$ grep "this" demo_*
demo_file:this line is the 1st lower case line in this file.
demo_file:Two lines above this line is empty.
demo_file:And this is the last line.
demo_file1:this line is the 1st lower case line in this file.
demo_file1:Two lines above this line is empty.
demo_file1:And this is the last line.

3. Case insensitive search using grep -i

Syntax:
grep -i "string" FILE

This is also a basic usage of the grep. This searches for the given string/pattern case insensitively. So it matches all the words such as “the”, “THE” and “The” case insensitively as shown below.
$ grep -i "the" demo_file
THIS LINE IS THE 1ST UPPER CASE LINE IN THIS FILE.
this line is the 1st lower case line in this file.
This Line Has All Its First Character Of The Word With Upper Case.
And this is the last line.

4. Match regular expression in files

Syntax:
grep "REGEX" filename

This is a very powerful feature, if you can use use regular expression effectively. In the following example, it searches for all the pattern that starts with “lines” and ends with “empty” with anything in-between. i.e To search “lines[anything in-between]empty” in the demo_file.
$ grep "lines.*empty" demo_file
Two lines above this line is empty.
From documentation of grep: A regular expression may be followed by one of several repetition operators:
  • ? The preceding item is optional and matched at most once.
  • * The preceding item will be matched zero or more times.
  • + The preceding item will be matched one or more times.
  • {n} The preceding item is matched exactly n times.
  • {n,} The preceding item is matched n or more times.
  • {,m} The preceding item is matched at most m times.
  • {n,m} The preceding item is matched at least n times, but not more than m times.

5. Checking for full words, not for sub-strings using grep -w

If you want to search for a word, and to avoid it to match the substrings use -w option. Just doing out a normal search will show out all the lines.

The following example is the regular grep where it is searching for “is”. When you search for “is”, without any option it will show out “is”, “his”, “this” and everything which has the substring “is”.
$ grep -i "is" demo_file
THIS LINE IS THE 1ST UPPER CASE LINE IN THIS FILE.
this line is the 1st lower case line in this file.
This Line Has All Its First Character Of The Word With Upper Case.
Two lines above this line is empty.
And this is the last line.

The following example is the WORD grep where it is searching only for the word “is”. Please note that this output does not contain the line “This Line Has All Its First Character Of The Word With Upper Case”, even though “is” is there in the “This”, as the following is looking only for the word “is” and not for “this”.
$ grep -iw "is" demo_file
THIS LINE IS THE 1ST UPPER CASE LINE IN THIS FILE.
this line is the 1st lower case line in this file.
Two lines above this line is empty.
And this is the last line.

6. Displaying lines before/after/around the match using grep -A, -B and -C

When doing a grep on a huge file, it may be useful to see some lines after the match. You might feel handy if grep can show you not only the matching lines but also the lines after/before/around the match.

Please create the following demo_text file for this example.
$ cat demo_text
4. Vim Word Navigation

You may want to do several navigation in relation to the words, such as:

 * e - go to the end of the current word.
 * E - go to the end of the current WORD.
 * b - go to the previous (before) word.
 * B - go to the previous (before) WORD.
 * w - go to the next word.
 * W - go to the next WORD.

WORD - WORD consists of a sequence of non-blank characters, separated with white space.
word - word consists of a sequence of letters, digits and underscores.

Example to show the difference between WORD and word

 * 192.168.1.1 - single WORD
 * 192.168.1.1 - seven words.

6.1 Display N lines after match

-A is the option which prints the specified N lines after the match as shown below.
Syntax:
grep -A <N> "string" FILENAME

The following example prints the matched line, along with the 3 lines after it.
$ grep -A 3 -i "example" demo_text
Example to show the difference between WORD and word

* 192.168.1.1 - single WORD
* 192.168.1.1 - seven words.

6.2 Display N lines before match

-B is the option which prints the specified N lines before the match.
Syntax:
grep -B <N> "string" FILENAME

When you had option to show the N lines after match, you have the -B option for the opposite.
$ grep -B 2 "single WORD" demo_text
Example to show the difference between WORD and word

* 192.168.1.1 - single WORD

6.3 Display N lines around match

-C is the option which prints the specified N lines before the match. In some occasion you might want the match to be appeared with the lines from both the side. This options shows N lines in both the side(before & after) of match.
$ grep -C 2 "Example" demo_text
word - word consists of a sequence of letters, digits and underscores.

Example to show the difference between WORD and word

* 192.168.1.1 - single WORD

7. Highlighting the search using GREP_OPTIONS

As grep prints out lines from the file by the pattern / string you had given, if you wanted it to highlight which part matches the line, then you need to follow the following way.

When you do the following export you will get the highlighting of the matched searches. In the following example, it will highlight all the this when you set the GREP_OPTIONS environment variable as shown below.
$ export GREP_OPTIONS='--color=auto' GREP_COLOR='100;8'

$ grep this demo_file
this line is the 1st lower case line in this file.
Two lines above this line is empty.
And this is the last line.

8. Searching in all files recursively using grep -r

When you want to search in all the files under the current directory and its sub directory. -r option is the one which you need to use. The following example will look for the string “ramesh” in all the files in the current directory and all it’s subdirectory.
$ grep -r "ramesh" *

9. Invert match using grep -v

You had different options to show the lines matched, to show the lines before match, and to show the lines after match, and to highlight match. So definitely You’d also want the option -v to do invert match.

When you want to display the lines which does not matches the given string/pattern, use the option -v as shown below. This example will display all the lines that did not match the word “go”.
$ grep -v "go" demo_text
4. Vim Word Navigation

You may want to do several navigation in relation to the words, such as:

WORD - WORD consists of a sequence of non-blank characters, separated with white space.
word - word consists of a sequence of letters, digits and underscores.

Example to show the difference between WORD and word

* 192.168.1.1 - single WORD
* 192.168.1.1 - seven words.

10. display the lines which does not matches all the given pattern.

Syntax:
grep -v -e "pattern" -e "pattern"
$ cat test-file.txt
a
b
c
d

$ grep -v -e "a" -e "b" -e "c" test-file.txt
d

11. Counting the number of matches using grep -c

When you want to count that how many lines matches the given pattern/string, then use the option -c.
Syntax:
grep -c "pattern" filename
$ grep -c "go" demo_text
6

When you want do find out how many lines matches the pattern
$ grep -c this demo_file
3

When you want do find out how many lines that does not match the pattern
$ grep -v -c this demo_file
4

12. Display only the file names which matches the given pattern using grep -l

If you want the grep to show out only the file names which matched the given pattern, use the -l (lower-case L) option.

When you give multiple files to the grep as input, it displays the names of file which contains the text that matches the pattern, will be very handy when you try to find some notes in your whole directory structure.
$ grep -l this demo_*
demo_file
demo_file1

13. Show only the matched string

By default grep will show the line which matches the given pattern/string, but if you want the grep to show out only the matched string of the pattern then use the -o option.

It might not be that much useful when you give the string straight forward. But it becomes very useful when you give a regex pattern and trying to see what it matches as
$ grep -o "is.*line" demo_file
is line is the 1st lower case line
is line
is is the last line

14. Show the position of match in the line

When you want grep to show the position where it matches the pattern in the file, use the following options as
Syntax:
grep -o -b "pattern" file
$ cat temp-file.txt
12345
12345

$ grep -o -b "3" temp-file.txt
2:3
8:3

Note: The output of the grep command above is not the position in the line, it is byte offset of the whole file.

15. Show line number while displaying the output using grep -n

To show the line number of file with the line matched. It does 1-based line numbering for each file. Use -n option to utilize this feature.
$ grep -n "go" demo_text
5: * e - go to the end of the current word.
6: * E - go to the end of the current WORD.
7: * b - go to the previous (before) word.
8: * B - go to the previous (before) WORD.
9: * w - go to the next word.
10: * W - go to the next WORD.

Thursday, November 1, 2012

MSVC devenv.com != devenv.exe

I scratched my head not knowing why my compilation didn't generate any output on the command line when using devenv.exe.

and devenv.com which is a wrapper of devenv.exe does it

http://msdn.microsoft.com/en-us/library/xee0c8y7.aspx