From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Sat, 02 Jan 2010 14:47:26 EST." <5512efb3946b55a6983849404d0cab15@ladd.quanstro.net> References: <5512efb3946b55a6983849404d0cab15@ladd.quanstro.net> From: Bakul Shah Date: Sat, 2 Jan 2010 15:21:09 -0800 Message-Id: <20100102232110.17F6A5B4D@mail.bitblocks.com> Subject: Re: [9fans] du and find Topicbox-Message-UUID: b64a9932-ead5-11e9-9d60-3106f5b1d025 On Sat, 02 Jan 2010 14:47:26 EST erik quanstrom wrote: > > my beef with xargs is only that it is used as an excuse > for not fixing exec in unix. it's also used to bolster the > "that's a rare case" argument. I often do something like the following: find . -type f | xargs grep -l | xargs If by "fixing exec in unix" you mean allowing something like $(grep -l $(find . -type f )) then would take far too long to even get started. And can eat up a lot of memory or even run out of it. On a 2+ year old MacBookPro "find -x /" takes 4.5 minutes for 1.6M files and 155MB to hold paths. My 11 old machine has 64MB and over a million files on a rather slow disk. Your solution would run out of space on it. Now granted I should update it to a more balanced system but mechanisms should continue working even if one doesn't have an optimal system. At least xargs gives me that choice. Basically this is just streams programming for arguments instead of data. Ideally all the args would be taken from a stream (and specifying args on a command line would be just a convenience) but it is too late for that. Often unix commands have a -r option to walk a file tree but it would've been nicer to have the tree walk factored out. Then you can do things like breadth first walk etc. and have everyone benefit.