The following bytes were arranged on 21 Sep 2012 by Theo Markettos :
> The wget commit log is here:
> http://git.savannah.gnu.org/cgit/wget.git/log/
> if you want to poke through it to find out if the change was deliberate or a
> bug (it's pretty busy).
Sadly I couldn't locate the code which spat out the 200 OK message, but
I did find this illuminating commit message for the equivalent FTP code:
http://git.savannah.gnu.org/cgit/wget.git/commit/?id=ef113e51d8c80b16902042de7279ef634e7fdc2a
So it looks very like a deliberate change. But like I said, it probably
never crossed his mind that anybody might be relying on the distinction
between output/no output.
> I think the right answer here is either to use the return value, which as
> you say has concurrency issues under RISC OS, or to use curl. IME wget is
> more of a UI tool and curl is more of a 'plumbing' tool. Matching the UI
> output (as you're doing from wget) is akin to telling a GUI tool to click on
> the 4th menu item down - it's fragile and not likely to be stable. (For
> starters, what happens in translated versions of wget? I have no idea).
From a brief browse it seems as if curl has similar problems (one
command-line solution advocated using grep to second-guess the
diagnostic output, which is exactly the approach I want to avoid),
unless one uses libcurl, which is completely out in BASIC.
(It does remind me of an idea I've been playing with for a while, some
form of automated translation of C library headers into RISC OS modules
so they could both be used from other languages and shared between C
programs without the need to faff about with !SOManager. I'm convinced
it should be theoretically possible, given a set of fixed, sensible
calling standards and nailing down the format of C's data types,
particularly structs, but it's not happening any time soon. But hey, I
see one of my modules for this year is entitled "Compilers", so you
never know...)
--
__<^>__
/ _ _ \ It is written that Geeks shall inherit the Earth.
( ( |_| ) )
\_> <_/ ======================= Martin Bazley ==========================
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
No comments:
Post a Comment