Curl Command Line Variables(daniel.haxx.se)
daniel.haxx.se
Curl Command Line Variables
https://daniel.haxx.se/blog/2023/07/31/introducing-curl-command-line-variables/
22 comments
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.
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?
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.
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 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
[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
[deleted]
Why do the examples use two different styles of double quotes?
`--expand-data “{ \"homedir\": \"{{HOME:json}}\” "`
`--expand-data “{ \"homedir\": \"{{HOME:json}}\” "`
Written on Mac? It tends to do that.
mac/iOS: Settings > General > Keyboard > Smart Punctuation [(0) ]
To disable.
To disable.
Looks like a simple case of an overzealous rich text editor adding smart quotes. All the quote characters should be straight double quotes (").
So how long until Curl is turing complete :)
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?
Looks like there are a couple of use cases.
The expansion supports several transformations that can help build values:
(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.
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
(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.
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.