Why does grep sometimes show the file name, sometimes not

grepwildcards

Can somebody please explain to me why I don't get the full path in example 1?

example 1 – returning found line

grep MODIFY /opt/releases/packages/cr_c_cr6/sas/dbms/*/*;
outcome: MODIFY

example 2 – returning full path

grep MODIFY /opt/releases/packages/cr666/sas/dbms/*/*;
/opt/releases/packages/cr666/sas/dbms/sti/FA_DISCLOSURE.ddl:MODIFY QUANTITY NUMBER;

I have found a solution, but I want to understand what is happening here. 1 command, different outcome/handling.

Best Answer

In your first example, the glob must have expanded to a single file. In that case, grep doesn't (by default) prepend the file name.

The second example must have expanded to several file names, and grep does prepend the filename in that case.

You can use the -H option to always get the filename prepended to the output, or -h to never get it.

If your grep lacks these options, you can use grep REGEX /path/to/pattern/* /dev/null to always get the filename (there's never any hit in /dev/null but it counts as a file name), or cat /path/to/pattern/* | grep REGEX to never get a filename.

Related Solutions

Why does grep sometimes return directories with two slashes

When you run the command:

grep -r <pattern> <directory>

it prints all the filenames as <directory>/<filename>. If you put a slash at the end of <directory>, it will be included in that, so you end up with a double slash.

The code could have been smart enough to notice when the original directory name ends with / and omit it when printing filenames, but they didn't bother. I think the only special case it makes is for the root directory, e.g.

grep -r pattern /

will print /foo/bar/baz rather than //foo/bar/baz. This is because POSIX specifies that a sequence of slashes is treated equivalently to a single slash except that two slashes at the beginning have implementation-dependent meaning (this is because some network file system mechanisms made use of syntax like //server/pathname). See How does Linux handle multiple consecutive path separators (/home////username///file)?

Why does ‘grep -q’ consume the whole input file

grep does stop early, but it buffers its input so your test is too short (and yes, I realise my test is imperfect since it's not seekable):

seq 1 10000 | (grep -q 2; cat)

starts at 6776 on my system. That matches the 32KiB buffer used by default in GNU grep:

seq 1 6775 | wc

outputs

   6775    6775   32768

Note that POSIX only mentions performance improvements

When searching several files

That doesn't set any expectations up for performance improvements due to partially reading a single file.

Best Answer

Related Solutions

Why does grep sometimes return directories with two slashes

Why does ‘grep -q’ consume the whole input file

Related Question