cURL / Mailing Lists / curl-library / Single Mail

curl-library

RE: URL specific options

From: Steve Holme <steve_holme_at_hotmail.com>
Date: Wed, 12 Feb 2014 22:17:53 +0000

On Mon, 10 Feb 2014, Daniel Stenberg wrote:

> I think a user would appreciate getting them all up front (unless it
> makes the code very akweard).
>
> The transfers may be slow so there will be cases where entering
> passwords first and then let the command sit there and work can
> be useful.

No problem - it shouldn't be too awkward. I just need to move the existing
checks into their own function, then move the call to that function to just
after parseargs() whilst adding the configurable loop to it. I should be
able to use URL #1, URL #2 in the prompt as well without too much hassle ;-)

> There are a bunch of command line options that we probably want
> to have "global" effect. Like --libcurl and even -v / --trace* ...

So far I've allowed --trace to be inherited from the previous operation but
overridden if the user wants to do it. That way I didn't break the Test
Suite with the current code ;-)

I will investigate a Global Config structure and separating the Global type
variables out from the Operation based variables.

> > * I have removed the curl handle freeing from operate_do() as a) This
> > would destroy the handle after the first operation for any further
>
> I'm afraid a bit lost about the exact place and variable you talk of, but
from
> what I can see you're right.

I ended up reworking that part, as I broke the pingpong based protocols with
their LOGOUT/QUIT commands :(

> > * Do we need to reset certain curl_easy_setopt() options after each
> > operation?
>
> Yes we most probably do. If each "section" is separate it shouldn't be
> affected on the previous options. Or else we need to document those
> clearly.

No problem - I will look at this as well ;-)

> > * How should we document the separating ":" character in --help? It
> > doesn't feel right to mention it in the options but I can't think of
> > the best format to use if we mention it in the usage line.'
>
> It was discussed previously and I think I agree that ":" is not a good
> separator to start with.

I don't have any preference really - I used ":" as that was what was
mentioned in the mail from 2004 but understand it's a little unusual and may
be used on other systems for other things. Does anyone else have any other
suggestions??

Kind Regards

Steve
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-02-12