From mboxrd@z Thu Jan 1 00:00:00 1970 From: dexen deVries To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Date: Wed, 29 Aug 2012 10:09:49 +0200 Message-ID: <2163431.PCPU6Eb4rj@coil> User-Agent: KMail/4.9 (Linux/3.5.0-l45; KDE/4.9.0; x86_64; ; ) In-Reply-To: <8ee568439e1855124564ecf0e83ac2b3@kw.quanstro.net> References: <8ee568439e1855124564ecf0e83ac2b3@kw.quanstro.net> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Subject: Re: [9fans] rc's shortcomings (new subject line) Topicbox-Message-UUID: b3465efe-ead7-11e9-9d60-3106f5b1d025 On Tuesday 28 of August 2012 16:34:10 erik quanstrom wrote: > my knee-jerk reaction to my own question is that making it easier > and more natural to parallelize dataflow. a pipeline is just a reall= y > low-level way to talk about it. the standard > =09grep x *.[ch] > forces all the *.[ch] to be generated before 1 instance of grep runs = on > whatever *.[ch] evaluates to be. >=20 > but it would be okay for almost every use of this if *.[ch] were gene= rated > in parallel with any number of grep's being run. (in Linux terms, sorry!) you can get close with find|xargs -- it runs the command for every -L <= number>=20 lines of input. AFAIK xargs does not parallelize the execution itself. find -name '*.[ch]' | xargs -L 8 grep REGEX --=20 dexen deVries [[[=E2=86=93][=E2=86=92]]] I'm sorry that this was such a long lett=C2=ADer, but I didn't have tim= e to write=20 you a short one. -- Bla=C2=ADise Pasc=C2=ADal