On Sat, Nov 5, 2011 at 15:08, <sta...@cs.tu-berlin.de> wrote: > * Étienne Faure <tinou...@gmail.com> [2011-11-05 14:59]: >> On Sat, Nov 5, 2011 at 14:40, <sta...@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.
