lundi 30 mars 2015

File path to input.txt file with multiple URLs for download reported as non-existent by wget

OK, I've downloaded this version (http://ift.tt/1CF5Zi0, wget-1.16.3-win64) of the wget standalone executable file for Windows (from http://ift.tt/1MPBqr6). I'm using Windows 7 Ultimate SP1 (64-bit) and I'm trying to use wget to download a large amounts of files which are listed in the file input.txt (a newline-delimited list of URLs). However, (even though I've done cd with Windows' cmd.exe to the directory where I have both wget64.exe and input.txt), when I try the following command to download my files



wget64.exe -i C:\Users\Aspire\Desktop\test3\input.txt -np -E --execute robots=off --user-agent=Mozilla


I get an error:



C:\Users\Aspire\Desktop\test3>wget64.exe -i C:\Users\Aspire\Desktop\test3\input.txt -np -E --execute robots=off --user-agent=Mozilla
C:/Users/Aspire/Desktop/test3/input.txt: No such file or directory
No URLs found in C:/Users/Aspire/Desktop/test3/input.txt.


First of all, why does wget list the directory path as / (the *NIX/Linux way) rather than the Windows way (\)? I know that wget is primarily a Linux program, but still...


I tried to execute the same download command as above, but by using Administrator privileges (e.g. to start cmd.exe as an admin), but the next error popped up:



wget64.exe is not a valid win32 application! (a pop-up error message)
Access denied. (what was left in cmd.exe)


Any ideas on how to solve this? What is it that I'm doing wrong in this case?


P.S. If it's of any use, my input.txt is encoded as UTF-8 and has a CRLF (\r\n) EOLs (i.e. the DOS/Windows end-of-line style).


Aucun commentaire:

Enregistrer un commentaire