Buy commercial curl support from
WolfSSL. We help you work out your issues, debug your libcurl
applications, use the API, port to new platforms, add new features and more.
With a team lead by the curl founder himself.
Re: debugging config files options
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-users <curl-users_at_lists.haxx.se>
Date: Fri, 5 Apr 2024 14:31:14 +0200 (CEST)
On Fri, 5 Apr 2024, Daniel Feenberg wrote:
> Does the -v option provide significant additional information during
> parsing? Many commands have -v or -d options, and .rc files - do we know
> what they do? My guess is that for most commands -v doesn't affect parsing,
> so there isn't a problem for them.
-v is for "verbose" so I figured it was natural to use that. I would really
prefer to not add a new option.
> What is the reason to only examine the first option? Even if documented,
> that restriction would be missed by most users.
I agree that it is quirky and unfortunate. The reason is of course that our
command line parser parses and acts on the content in the same phase, so we
cannot easily check the entire command line for a verbose option without also
reading all the specified config files etc.
This is basically the best idea I came up with that avoids a new option and
still works.
> How costly would it be to scan the entire command line? Would that mean
> having a fixed maximum length for the command line?
Primarily it would need a refactor that would first split up the entire
command line into options and their arguments (so that we can scan for a
verbose option among them) - then in a second phase act on them.
A significantly larger change than the 35 lines my current patch is! :-)
> Sorry for all the questions.
No need, they're perfectly sensible!
My first take and draft pull request for this feature is here:
https://github.com/curl/curl/pull/13295
Date: Fri, 5 Apr 2024 14:31:14 +0200 (CEST)
On Fri, 5 Apr 2024, Daniel Feenberg wrote:
> Does the -v option provide significant additional information during
> parsing? Many commands have -v or -d options, and .rc files - do we know
> what they do? My guess is that for most commands -v doesn't affect parsing,
> so there isn't a problem for them.
-v is for "verbose" so I figured it was natural to use that. I would really
prefer to not add a new option.
> What is the reason to only examine the first option? Even if documented,
> that restriction would be missed by most users.
I agree that it is quirky and unfortunate. The reason is of course that our
command line parser parses and acts on the content in the same phase, so we
cannot easily check the entire command line for a verbose option without also
reading all the specified config files etc.
This is basically the best idea I came up with that avoids a new option and
still works.
> How costly would it be to scan the entire command line? Would that mean
> having a fixed maximum length for the command line?
Primarily it would need a refactor that would first split up the entire
command line into options and their arguments (so that we can scan for a
verbose option among them) - then in a second phase act on them.
A significantly larger change than the 35 lines my current patch is! :-)
> Sorry for all the questions.
No need, they're perfectly sensible!
My first take and draft pull request for this feature is here:
https://github.com/curl/curl/pull/13295
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2024-04-05