I really feel this is reinventing the wheel and the resulting wheel is not quite round.<p>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?<p>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.<p>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 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.<p>[1]: <a href="https://hurl.dev" rel="nofollow noreferrer">https://hurl.dev</a>
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?