[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#422088: [Patch] wish preseed_fetch could distinguish between non-existance of a requested file and other failures to fetch file.

On 06/05/07, Joey Hess <joeyh@debian.org> wrote:
Alex Owen wrote:
>               # TODO add progress bar
> -             if wget -q "$url" -O "$file"; then
> +             if wget -q "$url" -O "$file" 2>$log ; then
> +                     rm -f $log
>                       return 0
> +             elif    grep "server returned error 404" $log >/dev/null ; then

It's generally not a good idea to rely on command error messages like

I agree,
I was thinking that getting wget to give a sensible exit status rather
than parsing the error message. Perhaps that warrents a wishlist bug
on wget?

Perhaps reducing the grep line to:
> +             elif    grep "404" $log >/dev/null ; then
would be more robust?

On 06/05/07, Joey Hess <joeyh@debian.org> wrote:
An alternative way to do this is to first always load the standard preseed
file, and then try to fetch the load preseed file, which if it exists, can
override settings in the standard file.

I used to think that too... untill I discussed the idea with Philip Hands.

Alex Owen:
" I was thinking that a cleaner approach might be to have all public and
 all examples under classes then override that by placing stuff in
 local (or local_classes if you want to keep local for your way of
 doing things). I have test code which will test for the existance of
 [presee|subclasses|early_script|late_script] under local and use that
 and fall back to the equivilent file under classes if that fails."

Philip Hands:
" That sounds like the way I used to do that, but it has the problem that if
 you have a network outage, it's possible to have it skip an existing local
 file, and then carry on regardless, rather than having it complain that it
 failed to get a file it was expecting to exist -- this possibility, while
 slight makes the whole thing non-deterministic, so I'd rather avoid it
 (unless you have a scheme where a file that exists but is temporarily
 unavailable is distinguished from one that doesn't exist at all, in which
 case I'm all ears :-)

Alex Owen:
" If wget (busybox) gives different error code for "not found" response
 from web server as opposed to no response from server then you can

I then wrote this patch as parsing the error message was easier than
hacking the wget code!

Thanks for your comments,
Alex Owen

Reply to: