Unix: Unexpected behavior of grep command with regex search

Question

I have a grep command that I run daily to find an entry in a huge logfile.

This command works fine in our Development environment. But in our Production environment, it outputs a response that is different from the entry in the logfile.

Here's the command:

logentry=$(grep -m1 -oP '.*(?<=Reset\s).*' $log)

Actual entry in log file:

******Reset  Counter:[Total:1849766] [Success:1849766]  [Insert:102]  [Update:1848861]  [Delete:803]  [Key:0]

Command output:

******Reset  Counter:[Total:1849766] 1  [Insert:102]  [Update:1848861]  [Delete:803]  [Key:0]

Expected output:

 ******Reset  Counter:[Total:1849766] [Success:1849766]  [Insert:102]  [Update:1848861]  [Delete:803]  [Key:0]

What could be the reason behind this inconsistent behavior of the grep command?

i have added expected output to question. the success count field gets replaced by 1 most of the time — Rahul Sharma, Feb 26 '16 at 20:12
more importantly - how are you displaying the `logentry` to verify that it's correct? It's got the smell of a glob pattern finding a file called `1` — Anya Shenanigans, Feb 26 '16 at 20:14
i use echo $logentry to print it. if that is the case then it should be true always. — Rahul Sharma, Feb 26 '16 at 20:15
That'd do it then - you're not quoting your variable so it's open to globbing, word-splitting, and filename expansion and so the net result will be dependent on files in your directory. Use `echo "$logentry"` instead and ALWAYS quote your shell variab;es unless you have a specific purpose in mind by not doing so and fully understand all of the implications. — Ed Morton, Feb 26 '16 at 20:19
What's the point of the fancy grep command, btw,, vs a simple `grep -m1 'Reset' file`? — Ed Morton, Feb 26 '16 at 20:23
when I use logentry variable within quotes it seems working. I will monitor it for few days then update question as resolved. "Ed Morton" I put partial regex in query in question, the purpose is positive look-behind. — Rahul Sharma, Feb 26 '16 at 20:54
You'll want to read [Security implications of forgetting to quote a variable in bash/POSIX shells](http://unix.stackexchange.com/q/171346/4667) — glenn jackman, Feb 26 '16 at 21:24
@RahulSharma positive look-behind isn't a purpose it's just what the script is doing, I was asking why you're doing it. — Ed Morton, Feb 26 '16 at 22:59
Are you trying to remove the "Reset", like `grep -m1 -oP '(?<=Reset\s).*' "${log}"` ? Then please correct your expected and wanted output. The current wanted output is the same as a simple grep. — Walter A, Feb 27 '16 at 07:53

score 0 · Accepted Answer · edited Apr 13 '17 at 12:36

Thanks @Ed Morton for comment. The fix is working fine.
Root cause: The variable is not quoted so it's open to globbing, word-splitting, and filename expansion and so the net result will be dependent on files in your directory.

Solution: Use echo "$logentry" instead and ALWAYS quote your shell variabes unless you have a specific purpose in mind by not doing so and fully understand all of the implications.

Security implications of forgetting to quote a variable in bash/POSIX shells

Unix: Unexpected behavior of grep command with regex search

1 Answers1