hckrnws

This is powerful stuff, but I can't help feeling like it's adding unnecessary bloat to an already-enormously complicated command. What is the advantage of:

    curl --variable "pwd@secret;[0-31]" \
        --expand-user daniel:{{pwd}} \
        https://example.com/

    curl --user daniel:`command-to-fetch-password` \
        https://example.com/

The latter one shows your password in the process listing.

First one will show how to get it :D

… which is not accessible to as many users as the process list is.

Not all places you might run curl allow for shell tricks like process substitution or perhaps for subprocesses at all.

The main benefit seems to be context dependent quoting which is tricky to get right and in most cases (like in your example) omitted completely

I'm sure this solves someone's problem, but reading https://everything.curl.dev/cmdline/variables.html makes me wonder whether curl really needs this added complexity

What is the use-case for this feature? I get specifying byte ranges for parsing headers and whatnot, but I don't know a curl workflow that benefits from this.

The first one that comes to mind is something I haven’t done lately but used to do constantly, enough so that I wrote a custom fuse filesystem to combine isofuse with http handling, and that’s parsing an index from something with a range request then fetching only the part or parts I want. Think fetching only the trailing index from a zip archive and then fetching the specific file you want out of a 10tb zip rather than downloading the whole thing. Now, how often would I do this on the command line? Not sure, but I might not have bothered with fuse if I’d had the option.

Unless I'm gravely misunderstand this feature currently, it won't help that use case as the variable assignment only supports string literals, env cars, or existing files which wouldn't help your range request for the remote file

It would be a natural extension to treat the @ syntax as a uri (because, come on, it's curl!) if it contains a ":" but even that gets hairy because the next layer of indirection would be --variable-with-curlrc to allow setting the enormous number of parameters one would want when chasing the interior uri