dear lazy web ... (UNIX pipes)
Tony Kennick
0995a06aaeaf6b70e79c3aafd6719329 at half.pint.org.uk
Sat Apr 19 21:33:37 BST 2008
On Sat, Apr 19, 2008 at 03:40:44PM +0100,
the following was promulgated by Greg McCarroll:
>
> So, I thought I knew how pipes worked from a distant OS class at uni.
>
> let say ...
>
> process_that_generates_output | grep something
>
> now i thought that grep would be started around the same time as the
> first process and would grind through output when it had enough input
> to work on, and from this dim distant OS class I remember we
> implemented a special shared memory area in our own OS to do just
> that (this was 14 years ago).
>
> now today i wondered about,
>
> process_that_generates_output | grep something | head
grep will get SIGPIPE from head when head is done and will send it back
up the line. process_that_generates_output may decide that it is doing stuff
that it should carry on doing and it doesn't care that no one is
listening to it any more.
For ways of looking at what your pipe is doing (in bash) look at
http://www.greenend.org.uk/rjk/2001/04/shell.html#pipeerrors
> wondering if when head had enough output to make it happy it would
> terminate and that would propogate to grep and the first process.
>
> and so i experimented timing the first process with and without head
> as the final pipe, and in a very unscientific test it came out with
> the same result.
>
> so can someone either totally fulfill my laziness and explain why
> (even if its 'your tests were wrong') or point me in the direction so i
> can do my own figuring out.
>
> (disclaimer: i'm being a little more lazy than usual as i thought it
> might be an interesting discussion topic)
>
> G.
--
Tony Kennick
Web: http://www.pint.org.uk/ Blog: http://blog.pint.org.uk/
Photos: http://www.flickr.com/photos/thegreatgonzo/
More information about the london.pm
mailing list