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

Reply via email to