[HN Gopher] Curl with Partial Files
       ___________________________________________________________________
        
       Curl with Partial Files
        
       Author : ingve
       Score  : 48 points
       Date   : 2024-12-30 10:50 UTC (3 days ago)
        
 (HTM) web link (daniel.haxx.se)
 (TXT) w3m dump (daniel.haxx.se)
        
       | oneeyedpigeon wrote:
       | 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/
       | 
       | over, e.g.                   curl --user daniel:`command-to-
       | fetch-password` \             https://example.com/
       | 
       | ? That command may be as simple as an existing one, like cut.
        
         | rubenv wrote:
         | The latter one shows your password in the process listing.
        
           | LetMeLogin wrote:
           | First one will show how to get it :D
        
             | skywhopper wrote:
             | ... which is not accessible to as many users as the process
             | list is.
        
               | bbarnett wrote:
               | And can often be passed in bash via a filehandle, without
               | a file.
        
         | skywhopper wrote:
         | Not all places you might run curl allow for shell tricks like
         | process substitution or perhaps for subprocesses at all.
        
         | djbsbdb wrote:
         | 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
        
       | mdaniel wrote:
       | 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
        
       | RestartKernel wrote:
       | 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.
        
         | trws wrote:
         | 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.
        
           | mdaniel wrote:
           | 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
        
         | raldu wrote:
         | Pausing and resuming downloads, and fetching bytes in splits
         | would turn curl into a download manager like aria2.
        
       | benatkin wrote:
       | This could be used to send a single file in a tar. Nice!
        
       | DrewRWx wrote:
       | Nice! This will make my podcast blog to RSS generator a whole lot
       | easier since I just need to grab some headers from the MP3 in
       | addition to info the the page.
        
       ___________________________________________________________________
       (page generated 2025-01-02 23:00 UTC)