Timeline for saving output of another command
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 25, 2013 at 16:51 | comment | added | Magellan | Good stuff. Thanks. had no idea that the default buffer was that large. | |
| Nov 25, 2013 at 12:50 | comment | added | tkrennwa | Consider a text file with only a few characters in it. If you run tail -f... and pipe it into the grep | tee machinery, you would end up in exactly the scenario of the question: grep would wait for more input before processing it, while tee does not receive anything at all. Of course, if general.log is sufficiently large, the standard approach without altering the output buffer mode to line-buffered would work, but only if you it larger than the buffer size. And then you would need to wait for filling up grep's buffer again. See unix.stackexchange.com/a/102505/50954 | |
| Nov 18, 2013 at 21:01 | history | migrated | from serverfault.com (revisions) | ||
| Nov 18, 2013 at 16:33 | comment | added | Magellan | You're right. Wasn't paying attention. | |
| Nov 18, 2013 at 7:34 | comment | added | zhenech | Using tail -f ... |grep allows one to grep the new lines incoming (-f option to tail). AFAIK grep has no such option. | |
| Nov 18, 2013 at 6:42 | comment | added | Magellan | Sure enough. Thanks. What I get for multi-tasking. | |
| Nov 18, 2013 at 6:23 | comment | added | dmourati | I think you mean tee instead of tail in your command line example. | |
| Nov 18, 2013 at 5:49 | history | answered | Magellan | CC BY-SA 3.0 |