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?
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.
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.
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”?
22 comments
[ 24.4 ms ] story [ 460 ms ] threadThe expansion supports several transformations that can help build values:
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.
[1]: https://hurl.dev
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.
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.
Environment variables are nice for this. Locally scoped and reasonably secure.
`--expand-data “{ \"homedir\": \"{{HOME:json}}\” "`
To disable.