On Tue, 10 Jun 2008, Dan Fandrich wrote:

> I think this is an excellent improvement. Without this, the .curlrc file is
> essentially useless for the majority of options since it's impossible for a
> user or app to call curl with an unambiguous set of options. The user
> experience with this change should be pretty reasonable, too, excepting a
> few double negatives (e.g. --no-disable-eprt, --no-no-keepalive (does the
> patch already handle this one?)) and a few that become misleading (e.g.
> --no-ipv4 does NOT disable IPv4 parsing).

I did try to address the most obvious double negatives, so --no-keepalive is
now the negative to --keepalive (which didn't previously exist) and both
--eprt and --epsv are now recognized options to allow for --no-eprt and
--no-epsv (that are supposed to be aliases for --disable-eprt and
--disable-epsv but added to allow them to follow the same style). But yes,
"--no-disable-eprt" actually should work...

I'm sure I've missed some things in there since we had 126 options and a
large portion of them are booleans!

I added --remote-name-all, which is my sneaky way to finally offer a feature
that's been asked for many times over the years:

Starting now, you can add --remote-name-all in your .curlrc and then curl will
default to -O'ing urls (also known as wget-style ;-O), and thus you must
_undo_ -O if you want to specificly download to stdout! I'm not 100% sure how
this is going to hurt, but I know lots of users will start doing things this
way...

I'm of course interested to hear if anyone experiences any problems with the
command line options with this new concept applied.

-- 
  / daniel.haxx.se