zdiff problem

Bryan Kadzban bryan at kadzban.is-a-geek.net
Sun May 17 22:39:27 PDT 2009

Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>> Sheesh, that's complicated!  
> Yes, it's bad.  Earlier they have:
> for file
> do
>    test "X$file" = X- || <"$file" || exit 2
> done
> but file is never defined, so this always fails.  It might be for another shell 
> or architecture, but it isn't commented and look screwy.

This confused me for a while when I saw it in other places, too.

"for file ; do" binds $file to each *positional parameter* ($1, $2,
etc.) and runs the body of the loop.

Yes, I think it's bad to use this.  "for file in "$@" ; do" is a lot
more explicit, which makes me like it a *lot* more.  Of course, in a
shell that doesn't let you "$@" to get properly-quoted arguments with
spaces (if there are any), you might need to do it the other way...

Anyway, the whole loop here appears to attempt reading from every
positional argument, and exit with status 2 if any of them can't be read
from?  *Looks* like the <"$file" isn't actually done for a command that
gets run, just to test whether the file can be opened for reading.

>> (...but where was 3 opened?  before this?); 
> Yes, earlier it does
>    exec 3>&1
> Why we need to use 3 at all is a mystery to me.

OK, that makes a bit more sense.

We need to use 3 because the stdout of that whole gigantic mess is going
(via process substitution) into the gzip_output variable, not to the
user.  But the output of $cmp does need to go to the user, so there
needs to be a way to bypass the substitution.  Of course, stdout of most
of the subshells is getting piped elsewhere, so they then need to dup FD
1 into FD 4 at the start, to get the right values sent to the target of
the process substitution...

>> Pipe the decompressed
>> file into "eval $cmp /dev/fd/5 -" (whatever $cmp is; presumably - means
>> stdin).
> cmp='${DIFF-diff}'

OK, so "diff" unless $DIFF is set to something else.  (They might be
able to get rid of an eval if they changed the single quotes into double

>> Looks like it's attempting to run "$cmp" (whatever it is) on the two
>> streams of gunzip output.  
> Yes and keep it all in memory.  They don't want to do any disk IO here.


> I hadn't run into a script that closed file streams with things like 3>&- 
> before.

The weird thing is, that's not in my bash manpage either.  The manpage
claims that a second FD is required on the right-hand side of the & (so
like "3>&6-", which would either move 6 into 3, or move 3 into 6, I
don't remember which way it worked).  But I've seen it done before.

>> That's because the ls process only has stdin, stdout, and stderr open;
>> FD 3 is a handle to the /proc/self/fd directory itself in this case
>> (because you're looking at its contents; opendir() returned 3).
> That's a new one for me.

"ls -l /proc/self/fd" is useful.  As is "ls -l /proc/<random PID>/fd"
from time to time.  :-)

> its fixed up in the book and I did test it, so it does work.

Sounds good!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20090517/54b6de05/attachment.sig>

More information about the lfs-dev mailing list