On Sun, May 17, 2009 at 6:49 PM, Bruce Dubbs <bruce.du...@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: > > http://lists.gnu.org/archive/html/bug-gzip/2008-02/msg00002.html > > 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: > > gzip_status=$( > 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. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
