On Thu, Apr 3, 2008 at 12:18 PM, Jim Meyering <[EMAIL PROTECTED]> wrote: > I suppose you have a real application where this is useful? > If so, please describe it -- motivation/justification helps ;-) >
Just a merge with a lot of source files. It's the same motivation as the nmerge patch. I've actually got another patch as well that I'll clean up and offer soon that allows a merge of > nmerge files to be divided among sub-processes whose output is then merged by the parent, which provides a performance benefit (if you've got the resources for it). I've got yet another patch that adds an option to open compressed files through a decompression program, so I don't have to set up fifos for a merge of gzipped files. I've been maintaining these patches against sort for a while, re-patching whenever a new release is published. I figured it would be worth a shot seeing if I could get any them incorporated into the package upstream. :) I'm also just generally interested in helping out with maintenance. I think I'm probably less experienced than most of the regular contributors but I can help with simple stuff and when it comes to coding I think doing is the best way of learning. > I think so. du and wc each have the --files0-from=F option, added for > the same reason. Any such option in sort should have the same name and > be implemented in the same way. That seems reasonable enough. Looks like readtokens0 does most of the work for me. :) How would you feel about also including a --filesn-from=F option to support pipelines like the one in my example where the input is newline separated? > [haven't forgotten about --nmerge. will get to it eventually ] Thanks. :) Bo _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils