I love the beauty and elegance of curl's design, seems to well thought out and practical

what about this design is elegant? duping all your commands so some can have variable interpolation and some of them don't, so people don't need to do that trivial task themselves? essentially upstreaming a bunch of difficult to maintain cruft, instead of easy to maintain downstream?

I wonder what the use case for this is, when every shell already offers parameter expansion of some kind. Is it so that you can write Curl command lines that work in any shell identically, once properly quoted?

The blog post states the feature got implemented because a user wanted to use environment variables for values in configuration file variables.

I missed that, thanks.

You can tell curl to read its arguments from a file, in which case a shell won't get to interpret them first, perhaps this feature is aimed at that?

Looks like there are a couple of use cases.

The expansion supports several transformations that can help build values:

  "json" outputs the content using JSON string quoting rules.
  "url" shows the content URL (percent) encoded.
  "b64" expands the variable base64 encoded

Command-line arguments are visible to others (eg, through ps or /proc/<pid>/cmdline) so including a secret directly on the command-line may leak data.

(For context, here's a SO message asking how to avoid that sort of leakage: https://stackoverflow.com/questions/3830823/hiding-secret-fr... )

You can use different files for different configurations, rather than depend on (global) shell variables.

I just discovered and used wget the other day. I've never used curl before but I have heard of it. Apparently they were both initially released in 1996. I wonder what makes that year notable in that regard.

I maintain an Open Source HTTP client based on libcurl [1]. We have support for variables like {{foo}} and also add kind of filters (like these new curl functions that you can chain to refine values). It seems natural to have this kind of templating for an HTTP client now (for instance, when you want to make "templatized" script). Really a nice addition to curl.

[1]: https://hurl.dev

I was wanting a tool like this! I had even started hacking something together to do this. Thanks for sharing, excited try it.

Love the name

I really feel this is reinventing the wheel and the resulting wheel is not quite round.

Would it not have been both simpler and more powerful to have a .curlrcscript file that gets executed and the output used as the config contents?

Even the original use case looks somewhat fishy: the user has secrets in their environment, but they can't have a bash script or function wrapper around curl to call curl with the environment variable baked? Again, more general and powerful than a limited variable-replacement scheme using yet-another curl-specific syntax.

I can think of many examples where the direction curl went will backfire: people will want variable based on other variables. People will want variable based on conditions (if/else), etc. All things a general scripting solution would fulfill in a standard way.

I don’t think a general purpose scripting language is simpler than this variables feature. As you rightly point out, sh already exists for more complex use-cases, and really complicated stuff can be handled by a helper program.

For me, the big value-add is the filter functions - for example, proper JSON escaping or URL encoding is hard to do with pure sh, usually needing some external tool; now that it’s built into curl, it will simplify scripts and reduce the list of dependencies.

I disagree. I don't like to have to write to disk. Sometimes I even can't.

Environment variables are nice for this. Locally scoped and reasonably secure.

If you can’t write to disk, how are you going to use curl? What is the scenario where you “don’t like to have to write to disk”? What do you mean by “reasonably secure”?

Read-only mounted filesystem? PXE boot with no storage? Chrooted into a folder without write access?

Why do the examples use two different styles of double quotes?

`--expand-data “{ \"homedir\": \"{{HOME:json}}\” "`

Looks like a simple case of an overzealous rich text editor adding smart quotes. All the quote characters should be straight double quotes (").

Written on Mac? It tends to do that.

mac/iOS: Settings > General > Keyboard > Smart Punctuation [(0) ]

To disable.

So how long until Curl is turing complete :)