bruce.dubbs at gmail.com
Sun May 17 21:04:19 PDT 2009
Dan Nicholson wrote:
> On Sun, May 17, 2009 at 6:49 PM, Bruce Dubbs <bruce.dubbs at gmail.com> wrote:
>> I'm trying to address ticket #2315 that says zdiff doesn't work. I confirmed
>> this by creating two files with a one line difference and compressing them:
>> gzip file1
>> gzip file2
>> But 'zdiff file1.gz file2.gz' gives no output. Older versions of the script
>> work properly.
>> The code in the script is really convoluted. I found an error report in the
>> gzip archives about this:
>> I note that there was never a reply to the message and that was over a year ago.
> The bug-gzip list unfortunately is pretty dead. I subscribed to it to
> submit a patch for this specific problem, but I never got around to
> submitting the patch or unsubscribing. :)
>> The problem code looks like:
>> exec 4>&1
>> (gzip -cdfq -- "$1" 4>&-; echo $? >&4) 3>&- |
>> ( (gzip -cdfq -- "$2" 4>&-; echo $? >&4) 3>&- 5<&- </dev/null |
>> eval "$cmp" /dev/fd/5 -) 5<&0
>> When I look at /dev/fd, I only have 0 through 3 (and on RH and Ubuntu other
>> systems too, but none use gzip-1.3.12).
> /dev/fd/ is just a symlink to the current process file descriptors.
> Typically you have 0, 1 and 2 for stdin, stdout and stderr. But a
> process can open up any more it wants. In this case, fd 5 is opened by
> the redirection.
>> The fix appears to be changing the last line above to
>> eval "$cmp" /dev/fd/5 - >&3) 5<&0
>> ^^^^ added
>> We can fix this with this with the following:
>> sed -i 's/5 -)/5 >\&3)/' zdiff
>> but I don't understand what is really going one here.
>> Should I make this change? Comments?
> I think that's right looking at the rest of the script (I agree it's a
> pretty hairy script). I wish I could find the patch I made before, but
> I can't seem to locate it now.
After I made the original post, I found the same fix in the current Debian
patch. I guess I'll go ahead and add the sed.
Thanks for the confirmation Dan.
More information about the lfs-dev