Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: Avoiding overwriting a symlinked target
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-users <curl-users_at_lists.haxx.se>
Date: Sun, 2 Jan 2022 17:48:18 +0100 (CET)
On Sat, 1 Jan 2022, Paul Gilmartin via curl-users wrote:
>> Why should curl remove the file when you can just do it yourself before
>> invoking curl?
>>
> This may not be obvious with "-J, --remote-header-name". (I read the
> warnings.)
Right, it may not be obvious but if you're downloading a file with a name you
don't know what it'll be to a directory, and you have some symlinks already
present in that destination directory, then you are by definition asking for
exactly what curl is going to do.
> What happens if the user specifies two or more of:
Okay, now we're drifting away from what this thread is about but sure...
> --remote-header-name
> --remote-name
> --output
First: -J (--remote-header-name) needs to be specified together with
-O (--remote-name) to work.
--remote-name and --output both specify how to save a URL, so they will apply
to one URL each on the command line if given in the same command line. Like
this:
curl --remote-name --output foo URL1 URL2
--remote-name is then applied for URL1 and "--output foo" goes for URL2. In
the order they are provided.
What's a little special perhaps is that if you remove URL2 from the command
line above there's no error shown and "--output foo" will just not be used.
(I've created a PR that at least will make curl show a warning for it in the
future: https://github.com/curl/curl/pull/8210)
> And I've been wishing for a "--dry-run" option": tell me what curl intends
> to do, but don't actually do it, so I'll know what filename to use for
> "--time-cond <file>". I'm working on parsing the output of "--head"
> to do that.
--dry-run has been mentioned many times before (and is mentioned in the TODO).
It is however not an easy thing to add.
Date: Sun, 2 Jan 2022 17:48:18 +0100 (CET)
On Sat, 1 Jan 2022, Paul Gilmartin via curl-users wrote:
>> Why should curl remove the file when you can just do it yourself before
>> invoking curl?
>>
> This may not be obvious with "-J, --remote-header-name". (I read the
> warnings.)
Right, it may not be obvious but if you're downloading a file with a name you
don't know what it'll be to a directory, and you have some symlinks already
present in that destination directory, then you are by definition asking for
exactly what curl is going to do.
> What happens if the user specifies two or more of:
Okay, now we're drifting away from what this thread is about but sure...
> --remote-header-name
> --remote-name
> --output
First: -J (--remote-header-name) needs to be specified together with
-O (--remote-name) to work.
--remote-name and --output both specify how to save a URL, so they will apply
to one URL each on the command line if given in the same command line. Like
this:
curl --remote-name --output foo URL1 URL2
--remote-name is then applied for URL1 and "--output foo" goes for URL2. In
the order they are provided.
What's a little special perhaps is that if you remove URL2 from the command
line above there's no error shown and "--output foo" will just not be used.
(I've created a PR that at least will make curl show a warning for it in the
future: https://github.com/curl/curl/pull/8210)
> And I've been wishing for a "--dry-run" option": tell me what curl intends
> to do, but don't actually do it, so I'll know what filename to use for
> "--time-cond <file>". I'm working on parsing the output of "--head"
> to do that.
--dry-run has been mentioned many times before (and is mentioned in the TODO).
It is however not an easy thing to add.
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/listinfo/curl-users Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-01-02