Elmar Stellnberger wrote:
> I am not sure what grep does not like about my home directory, but as
> soon as I issue a "grep -R Testtext *" in my home dir grep will start to
> hang not triggering any further disk access after a short while.
Bugs in grep should be reported to bug-grep. But you have contacted
the bug-coreutils list instead. We don't know much about grep here.
The bug reporting address for most programs is documented in the
manual and in the output from --help.
> Tried to get a backtrace by installing coreutils-debuginfo and
> coreutils-debugsource but gdb does not find any symbols:
> > rpm -ql coreutils-debugsource coreutils-debuginfo|grep grep
> > (nothing found)
I am not familiar with those packages. I assume that they are
specific to a particular distribution. Meanwhile this is the mailing
list for the development of the coreutils for the GNU project. Those
packages are not part of the GNU Project.
But I don't think they are related to grep. This was confirmed by
your not finding any files relating to grep in them. They are
unrelated to your issue with grep.
> i.e. it does not seem to descend to subdirs)
Even though this isn't the right place to comment I can't help but to
suggest something. The most likely problem is that you have a pipe
file in your home directory. When grep reads the file it is blocked
waiting for input. Since nothing is writing the file this input never
arrives and grep waits for it. You would need to --exclude that file.
The grep -R option is really just a hack. Adding it requires adding
much of 'find's functionality such as --exclude and others. It
violates the principles of the Unix philosophy. Instead it is better
to use 'find' for finding files to act upon with a command. Here is a
better way to search all files in your home directory.
find . -type f -exec grep Testtext {} +
Bob
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
