Dan Hipschman <[EMAIL PROTECTED]> wrote: > On Fri, Feb 23, 2007 at 12:57:49AM +0100, Jim Meyering wrote: >> Even so, sort needs a better fall-back position for when it fails to >> fork a decompression process (failing to start a compression process >> isn't a big problem). If it can't fork the process, it should simply >> revert to decompressing each stream as it reads it. This is possible >> (easy, even) when using gzip or bzip2, and part of the reason I want to >> limit the list of compressors to programs like those that provide the >> required procedural interfaces. > > Last resort, if you don't have the time to fix it, just don't make > compression the default for the upcoming stable release. I.e., leave > the option in, but require it to be explicitly requested. I'd love to > help, but I'm not sure how long it will take me to do this with my > current schedule.
Yep, that's what I'm going to do. I was just poking around with gdb, started like this: seq -w 10000 > exp gdb --args ./sort -S 1k exp my jaw hit the floor when I saw the 500+ gzip zombies left hanging while I'm at a breakpoint in merge. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
