|
Home > Archive > Unix administration > May 2006 > grep hang - grep xxxx *
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
grep hang - grep xxxx *
|
|
| blackdog 2006-05-23, 1:17 pm |
| I use grep, it work just fine on all of my systems sun Solaris, but on
one particully system it alwyas hang. The system I built as other
system, there is no different from other systems I have.
It seems that the grep command grep the first file then hang. It could
not grep the string for
next file. The command I use as below:
grep xxx *
grep all of file in the same directory.
Please shed a light.
tks
| |
| Doug Freyburger 2006-05-23, 1:17 pm |
| blackdog wrote:
>
> I use grep, it work just fine on all of my systems sun Solaris, but on
> one particully system it alwyas hang. The system I built as other
> system, there is no different from other systems I have.
> It seems that the grep command grep the first file then hang. It could
> not grep the string for
> next file. The command I use as below:
>
> grep xxx *
>
> grep all of file in the same directory.
What directory are you in and what types of files are there?
If you're in /dev there are plenty of files that will take a very
long time before they run out of data like the device file of a
large filesystem, and others like tty* that will wait until
someone hooks up a terminal and types ^D.
If you're in /var/spool/lp you might have a FIFO file that
might never have an end up file.
If you're NFS mounted maybe the server went down.
Many other possibilities that can't be guessed without context.
| |
| blackdog 2006-05-23, 1:17 pm |
|
Doug Freyburger wrote:
> blackdog wrote:
>
> What directory are you in and what types of files are there?
They all are plan text files, and it is not in /dev directory.
Just regular directory data files. And the files is not large ether.
I can grep easily on other system in the same directory.
> If you're in /dev there are plenty of files that will take a very
> long time before they run out of data like the device file of a
> large filesystem, and others like tty* that will wait until
> someone hooks up a terminal and types ^D.
Would you please elaborate a littile more about tty* vs. grep hang and
^D
>
> If you're in /var/spool/lp you might have a FIFO file that
> might never have an end up file.
>
> If you're NFS mounted maybe the server went down.
> Many other possibilities that can't be guessed without context.
| |
| Doug Freyburger 2006-05-23, 1:17 pm |
| blackdog wrote:
> Doug Freyburger wrote:
>
>
> Would you please elaborate a littile more about tty* vs. grep
> hang and ^D
Device files named tty* and pty* are software emulations of
terminal lines or serial lines. What's an end-of-file on a serial
line? Control-D. So if you open a serial line for read and
keep reading until the end-of-file you are going to hang until
someone on the far end supplied a control-D or a hang-up
signal or whatever.
The same will apply to named tty*, pty*, named pipes,
fifos and likely a few other types of file.
Think of "tail -f". It reads from a regular file and waits rather
than exitting when it hits the end of the buffered data. On
a serial line or a software emulation of a serial line, it's
still just a regular old file as far as fopen() is concerned so
an fread() will wait until it completes.
| |
| blackdog 2006-05-24, 1:20 am |
|
Doug Freyburger wrote:
> blackdog wrote:
>
> Device files named tty* and pty* are software emulations of
> terminal lines or serial lines. What's an end-of-file on a serial
> line? Control-D. So if you open a serial line for read and
> keep reading until the end-of-file you are going to hang until
> someone on the far end supplied a control-D or a hang-up
> signal or whatever.
>
> The same will apply to named tty*, pty*, named pipes,
> fifos and likely a few other types of file.
>
> Think of "tail -f". It reads from a regular file and waits rather
> than exitting when it hits the end of the buffered data. On
> a serial line or a software emulation of a serial line, it's
> still just a regular old file as far as fopen() is concerned so
> an fread() will wait until it completes.
I use grep on command line. Thanks for all of explanation, I still
don't know how to resolve the problem.
| |
| Tim Skirvin 2006-05-24, 1:20 am |
| "blackdog" <cljlk@hotmail.com> writes:
[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
> They all are plan text files, and it is not in /dev directory.
Are there any symlinks pointing off-filesystem?
- Tim Skirvin (tskirvin@killfile.org)
--
http://www.killfile.org/~tskirvin/ Skirv's Homepage <FISH>< <*>
http://www.killfile.org/~tskirvin/friends/ Skirv's Friends
| |
| Thomas Maier-Komor 2006-05-24, 7:16 am |
| blackdog wrote:
>
> I use grep on command line. Thanks for all of explanation, I still
> don't know how to resolve the problem.
>
either run grep with truss or run grep without truss and truss it as
soon as it hangs. Once you have the filedescriptor causing the hang run
pfiles on the pid of grep to find out which file is the offender.
E.g.
truss grep xxx *
or
grep xxx *
^Z
bg
pfiles -p `pgrep grep`
truss -p `pgrep grep`
HTH,
Tom
| |
| Stephane Chazelas 2006-05-24, 1:16 pm |
| On 23 May 2006 09:55:06 -0700, blackdog wrote:
> I use grep, it work just fine on all of my systems sun Solaris, but on
> one particully system it alwyas hang. The system I built as other
> system, there is no different from other systems I have.
> It seems that the grep command grep the first file then hang. It could
> not grep the string for
> next file. The command I use as below:
>
> grep xxx *
>
> grep all of file in the same directory.
>
> Please shed a light.
[...]
There may exist a file called "-" in the current directory. For
some grep implementations, "-" means stdin, so grep will look
for xxx on its standard input instead of from the file called
"-".
In anycase, you should always mark the end of options, as some
files may as well be called "-F" or "-x"...
grep xxx -- *
or
grep xxx ./*
--
Stephane
|
|
|
|
|