On Wed, Jun 20, 2012 at 07:26:25PM +0100, Ted Harding wrote:
On 20-Jun-2012 16:36:43 Chris Green wrote:
Over the past few months I've noticed that when I run grep it sometimes appears to hang, I had put it down to doing "grep -r" down a rather large file hierarchy but now it's happening with a perfectly simple grep:-
www-data$ ls *.txt sidebar.txt start.txt www-data$ grep xxx *.txt www-data$ grep fred *.txt www-data$ grep 'CLEARFLOAT'_*.txt... and there it sits, still (like 5 minutes later). The two .txt files are only a few tens of bytes long. It's not using any processor time, it's just stuck.
I have just done it again in another terminal window, quotes removed but otherwise the same:-
www-data$ grep fred *.txt www-data$ grep CLEARFLOAT_*.txt ^C www-data$... and with a different user (in the same directory):-
chris$ cd /home/www-data/www/wiki/data/pages chris$ grep fred *.txt chris$ grep CLEARFLOAT_*.txt ^C chris$So, what am I missing?
-- Chris Green
You're not giving it anything to grep in! If you give a grep command in the form
grep <regexp> <filenames>
then it will grep, in all the files matching <filenames>, for lines matching <regexp>.
However, you are only giving it
grep <regexp>
and now it is waiting for lines to arrive via stdin, so it is hanging because it is waiting for input. However, where is stdin coming from?
To take a slight modification of your example, if I do
grep CLEARFLOAT*
it will simply hang (until I press Ctrl-C).
But if I now feed it with input lines from the keyboard (using "<< EOT") I shall see:
cat << EOT | grep CLEARFLOAT*
line 1 line 2 line containing CLEARFLOAT_BOATING.txt line 4 line 5 EOT
line containing CLEARFLOAT_BOATING.txt
Does this help?
Aarrgh, where did that undescore come from! That's what's causing the problem.
It should have read:-
grep CLEARFLOAT *.txt
.... and it *does* say that:-
chris$ grep CLEARFLOATÂ *.txt
Still hangs. I don't know where those underscores in your reply came from but I don't think they're in my commands.