curl / Mailing Lists / curl-users / Single Mail

Buy commercial curl support. 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 Daniel himself.

Re: supporting --longopt=value

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: Tue, 1 Jul 2025 16:03:01 +0200 (CEST)

On Tue, 1 Jul 2025, Paul Gilmartin via curl-users wrote:

> Does this introduce any incompatibility?

I have thought hard on this but I can't think of any.

> For example, would i
> change the behavior of:
> curl --output =x https://example.com

That's a valid existing command line for which the equals sign is part of the
argument to --output. The new handling does not change this and it will work
exactly like before.

The new parser only detects and works if the equals sign is used directly
"attached" to the right side of a valid option name with no space in between,
like --output=x. This syntax can be made supported without causing problems
exactly because it does not work at all with the old (existing) parser

-- 
  / daniel.haxx.se || https://rock-solid.curl.dev
-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users
Etiquette:   https://curl.se/mail/etiquette.html

Received on 2025-07-01

This message: [ Message body ]
Next message: Daniel Stenberg via curl-users: "The #curl user survey 2025 analysis"
Previous message: Paul Gilmartin via curl-users: "Re: supporting --longopt=value"
In reply to: Paul Gilmartin via curl-users: "Re: supporting --longopt=value"

Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]