|
⇤ ← Revision 1 as of 2007-05-02 22:53:30
Size: 2005
Comment:
|
Size: 2192
Comment: The 'less' trick does *not* answer the original question. I'm not sure it belongs here at all, but at least accurately describe what the trick does.
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 6: | Line 6: |
| Unfortunately there's no easy solution to this, because the behaviour of the standard programs would need to be changed. *See bottom of section before taking 'no easy solution' to heart* Some programs provide special command line options for this purpose, e.g. |
Unfortunately there's no easy solution to this, because the behaviour of the standard programs would need to be changed. *See bottom of section before taking 'no easy solution' to heart* Some programs provide special command line options for this purpose, e.g. |
| Line 15: | Line 13: |
| The {{{expect}}} package (http://expect.nist.gov/) has an {{{unbuffer}}} example program, which can help here. It disables buffering for the output of a program. Example usage: |
The {{{expect}}} package (http://expect.nist.gov/) has an {{{unbuffer}}} example program, which can help here. It disables buffering for the output of a program. Example usage: |
| Line 24: | Line 19: |
| Line 31: | Line 25: |
| Line 34: | Line 27: |
| A solution to this is to use the 'less' command in follow mode. This is simple to do! | If you simply wanted to highlight the search term, rather than filter out non-matching lines, you can use the 'less' program instead of Bash: |
| Line 38: | Line 31: |
| Then enter your search pattern (/ is search in less, like vi) /foo bar Next, put less into follow mode by issuing shift+f Thats all there is to it! |
Inside less, start a search with the '/' command (similar to searching in vi). This should highlight any instances of the search term. Now put less into "follow" mode, which by default is bound to shift+f. You should get an unfiltered tail of the specified file, with the search term highlighted. |
My command line produces no output: tail -f logfile | grep 'foo bar'
Most standard Unix commands buffer their output if used non-interactively. This means, that they don't write each character (or even each line) as they are ready, but collect a larger number (e.g. 4 kilobytes) before printing it. In the case above, the tail command buffers its output, and therefore grep only gets its input in e.g. 4K blocks.
Unfortunately there's no easy solution to this, because the behaviour of the standard programs would need to be changed. *See bottom of section before taking 'no easy solution' to heart* Some programs provide special command line options for this purpose, e.g.
grep (e.g. GNU version 2.5.1) |
--line-buffered |
sed (e.g. GNU version 4.0.6) |
-u,--unbuffered |
awk (some GNU versions) |
-W interactive, or use the fflush() function |
tcpdump, tethereal |
-l |
The expect package (http://expect.nist.gov/) has an unbuffer example program, which can help here. It disables buffering for the output of a program. Example usage:
unbuffer tail -f logfile | grep 'foo bar'
There is another option when you have more control over the creation of the log file. If you would like to grep the real-time log of a text interface program which does buffered session logging by default (or you were using script to make a session log), then try this instead:
$ program | tee -a program.log In another window: $ tail -f program.log | grep whatever
Apparently this works because tee produces unbuffered output. This has only been tested on GNU tee, YMMV.
If you simply wanted to highlight the search term, rather than filter out non-matching lines, you can use the 'less' program instead of Bash:
$ less program.log
Inside less, start a search with the '/' command (similar to searching in vi). This should highlight any instances of the search term. Now put less into "follow" mode, which by default is bound to shift+f. You should get an unfiltered tail of the specified file, with the search term highlighted.