Description of problem: grep -r is behaving differently between distros. Not sure if a broken behavior has been fixed or bug introduced. Version-Release number of selected component (if applicable): grep-2.14-5.fc20.x86_64 How reproducible: Always Steps to Reproduce: Execute the following from /tmp (THIS IS IMPORTANT) 1. grep -roe '^nfs.*--server' /root/anaconda-ks.cfg | grep -roe ^nfs where anaconda-ks.cfg contains something like: nfs --server=nfs-01.eng.brq.redhat.com --dir=/pub/fedora/linux/development-snapshot-20130924/20/x86_64/os/ --opts="nolock" Actual results: On RHEL 6 with grep-2.6.3-4.el6.x86_64 this yields just "nfs", while on Fedora 20 it yields empty string. Expected results: Same result in both versions. Additional info: Reading the man page I see -r is for recursion which is not needed in this case. Indeed removing -r from the command sequence gives correct results. If you execute from /root on Fedora 20: # grep -roe '^nfs.*--server' /root/anaconda-ks.cfg | grep -roe ^nfs anaconda-ks.cfg:nfs anaconda-ks.cfg:nfs while on RHEL 6 from /root: # grep -roe '^nfs.*--server' /root/anaconda-ks.cfg | grep -roe ^nfs nfs I think in the Fedora 20 version -r implies to recursively scan all files in the local directory regardless of input on stdout while in RHEL6 -r doesn't have an effect if a file/stdout is specified. Not sure which version is at fault.
This seems to be bug in the RHEL-6 grep, that was fixed by the following upstream commit: http://git.savannah.gnu.org/cgit/grep.git/commit/?id=faf6ea13b3281a2004f5bfd1487708d1ba50a6c5 I think it is not worth backporting to RHEL-6. The current Fedora's prep behaviour is according to the manual page, thus closing as not a bug.