On Sat, Nov 5, 2011 at 15:08, <stanio_AT_cs.tu-berlin.de> wrote:
> * Étienne Faure <tinoucas_AT_gmail.com> [2011-11-05 14:59]:
>> On Sat, Nov 5, 2011 at 14:40, <stanio_AT_cs.tu-berlin.de> wrote:
>> >
>> > I'm afraid, then curl won't do either.
>>
>> As a matter of fact, it does:
>>
>
> great. then use curl. It's acceptable dependence, just as much as wget
> is.
>
>> Renaming the file afterwards can lead to failure: if the list of
>> arguments after the ".php" is too long, the file won't be created, and
>> the rename will fail.
>> In such cases wget returns:
>>
>> Cannot write to `...' (File name too long).
>
> Never encountered that myself. And I'm not sure I understand correctly.
> I would see whether the file was created -- on the last line of wget
> output:
>
Try this:
wget '
http://www.vim.org/scripts/script.php?script_id=3792&adding=dummy&arguments=that&could=be&a=horrible&hash=that&i=ve&seen=on&crappy=sites&unfortunatly=i&can=not&find=a&publicly=available&example=of&this=so&let=s&go=for&a=hash&here=514241337a3c43a0bb28eb88de0adde1&and=another&one=K3NYV1NvZm9IeU5IRFRjbkFIdjdlV0F5cW5HbVFzeWJpcFd0UHZyenhEZklDSUNrb1VwdnN3PT0K'
This only happens when things like session id or any other type of
hash is appended.
Though, now that I come to it, curl -JO fails as well. Only chromium
succeeds with this horrible URI.
Maybe we could go by a temporary file name as the same chromium does:
naming it "<suggested filename>.surfdownload", and then renaming it.
Left is to find out how curl gets its correct remote header filename.
Received on Sat Nov 05 2011 - 15:22:34 CET