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
quotes...)
>> 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.
Yeah.
> 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!
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
