4 ms·
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 .curlrc
by pierrebai 3y ago
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.
- nneonneo 3y agoI 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.
- WirelessGigabit 3y agoI 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.
- allarm 3y agoIf 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”?
- 10000truths 3y agoRead-only mounted filesystem? PXE boot with no storage? Chrooted into a folder without write access?