On Thu, Mar 10, 2005 at 02:13:44PM +0100, Friedrich Delgado Friedrichs wrote:
> Hiho!
>
>
> Ari Pollak schrieb:
> > Does this happen for any URL you try? Can you give an example of one
> > where it fails?
> It fails with any url.
>
> Manish Singh schrieb:
> > wget -T 300 http://the/url/that/is/failing -O /tmp/testwget
> >
> > would help (replace "http://the/url/that/is/failing"; with an actual
> > example url of course).
>
> I didn't know that gimp uses wget for retrieving the url...
>
> Actually that gives me an idea. My ~/.wgetrc contains:
> robots=off
> server-response=on
>
> And thus the output from above command is:
> [EMAIL PROTECTED]:~$ wget -T 300
> http://www.cashab.de/bilder_flaggen/australia.png -O /tmp/testwget
> --13:46:54-- http://www.cashab.de/bilder_flaggen/australia.png
> => `/tmp/testwget'
> Aufl?sen des Hostnamen ?www.cashab.de?.... 80.86.176.132
> Verbindungsaufbau zu www.cashab.de[80.86.176.132]:80... verbunden.
> HTTP Anforderung gesendet, warte auf Antwort...
> 1 HTTP/1.1 200 OK
> 2 Date: Thu, 10 Mar 2005 12:45:16 GMT
> 3 Server: Apache/1.3.31 (Debian GNU/Linux) mod_python/2.7.10
> Python/2.3.4 PHP/4.3.9-1 mod_ssl/2.8.20 OpenSSL/0.9.7d mod_perl/1.29
> 4 Last-Modified: Thu, 03 Feb 2005 01:47:35 GMT
> 5 ETag: "75408b-1784-420182b7"
> 6 Accept-Ranges: bytes
> 7 Content-Length: 6020
> 8 Keep-Alive: timeout=15, max=100
> 9 Connection: Keep-Alive
> 10 Content-Type: image/png
>
> 100%[================================================>] 6,020
> --.--K/s
>
> 13:46:55 (59.01 KB/s) - ?/tmp/testwget? gespeichert [6020/6020]
>
> I'm not sitting in front of my home machine right now, but I'm fairly
> certain that the bug will disappear if I remove the server-response
> parameter. Maybe gimp should add the "-e server-response=off" to its
> wget call (or improve the output parsing in a way that any options the
> user might have set in his .wgetrc don't get in the way).
Yeah, that'd do it. I've just committed code that adds
"-e server-response=off" to the wget arguments. Ari, that patch is
attached to this mail, so if you want to stick it in the debian builds
until 2.2.5 is out, go for it.
Improving the output parsing is nontrivial, since there isn't any
straightforward way to detect errors vs. informational messages. It's
not really worth doing, as GIMP 2.3 will now use gnome-vfs when
available.
> I also wonder why they don't look at the return value, which should be 0
> in this case.
Because GIMP parses the wget output to show loading status, so it
doesn't hang around doing nothing waiting for wget to finish.
-Yosh
Index: url.c
===================================================================
RCS file: /cvs/gnome/gimp/plug-ins/common/Attic/url.c,v
retrieving revision 1.33.2.1
diff -u -p -r1.33.2.1 url.c
--- url.c 24 Feb 2005 17:16:37 -0000 1.33.2.1
+++ url.c 10 Mar 2005 23:49:40 -0000
@@ -186,7 +186,8 @@ load_image (const gchar *filename,
putenv ("LANG=C");
#endif
- execlp ("wget", "wget", "-T", TIMEOUT, filename, "-O", tmpname, NULL);
+ execlp ("wget", "wget", "-e", "server-response=off", "-T", TIMEOUT,
+ filename, "-O", tmpname, NULL);
g_message ("exec() failed: wget: %s", g_strerror (errno));
g_free (tmpname);
_exit (127);
