"--run" sounds good to me (assuming it sets its own specific options for each URL requests, just like "--next")
Then you could even have -K read from a named pipe and pipe options into that 
from whereever and get curl to wait and transfer stuff as soon as it parses 
the next --run from the pipe and just never quit! =)

"named pipe" or stdin, that was exactly the point 
(Of course, EOF sent to curl trough "named pipe" or stdin would tell curl to quit)
What would/should happen when URLs set to distinct HOSTs/IPs are met in random orders from stdin ?Should curl keep n distinct connexions opened, or should it close the TCP connexion when the next HOST has a different "ip:port" than the previous URL ?
Regards,
Xavier

    Le Mercredi 16 décembre 2015 8h57, Daniel Stenberg <daniel_at_haxx.se> a écrit :
 

 On Wed, 16 Dec 2015, Dan Fandrich wrote:

> The --next option opens up the possibility of adding a feature to do this.
> Essentially, curl would parse options up to the --next, fire off the transfer,

Right. Or add a --next alternative that has that explicit functionality from
the start to make it less likely to rock any boats. Something like: --run

It would pause the config file reading, do the transfer with what's been given
so far and then come back and continue reading.

Then you could even have -K read from a named pipe and pipe options into that
from whereever and get curl to wait and transfer stuff as soon as it parses
the next --run from the pipe and just never quit! =)

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ:        http://curl.haxx.se/docs/faq.html
Etiquette:  http://curl.haxx.se/mail/etiquette.html
  

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ: http://curl.haxx.se/docs/faq.html
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2015-12-16