bugGNU Wget - Bugs: bug #44886, Windows filepaths not recognized...

 
 

bug #44886: Windows filepaths not recognized for -i, reported in the *NIX style

Submitted by:  None
Submitted on:  Mon 20 Apr 2015 06:40:55 PM UTC  
 
Category: NoneSeverity: 3 - Normal
Priority: 5 - NormalStatus: None
Privacy: PublicAssigned to: None
Originator Name: Originator Email: -unavailable-
Open/Closed: OpenRelease: 1.16.3
Operating System: Microsoft WindowsReproducibility: None
Fixed Release: NonePlanned Release: None
Regression: NoneWork Required: None
Patch Included: None

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Wed 06 May 2015 11:05:49 PM UTC, comment #3:

Problem:
wget64.exe -i C:\Users\Aspire\Desktop\test3\input.txt
fails with
C:/Users/Aspire/Desktop/test3/input.txt: No such file or directory

My first guess was related to cygwin shell, but you explicitely stated that you are using cmd.exe

Does it work if you simply call it as wget64.exe -i input.txt ?

Ángel <angel_>
Tue 21 Apr 2015 05:26:28 AM UTC, comment #2:

The forward slashes in the file name are not your problem, they are supported by Windows as well as backslashes.

Does the same wget command work if you put the input.txt file somewhere outside of the C:\Users hierarchy? There could be access restrictions to files there that cause wget to think the file is not accessible or doesn't exist.

Also, does the command work if the URLs don't use UTF-8 encoded non-ASCII characters? (Granted, if this is the cause, the error message needs to be improved.)

FWIW, I just tried a similar command using my own build of wget 1.16.1, with plain-ASCII URLs, and it did work, so the -i option definitely is working on MS-Windows.

Anonymous
Mon 20 Apr 2015 06:44:22 PM UTC, comment #1:

Sorry for posting this bug report as Anonymous, I didn't notice that I wasn't logged in while I was submitting the bug report.

K. <sahwar>
Mon 20 Apr 2015 06:40:55 PM UTC, original submission:

Here's the brief explanation of the problem:

http://stackoverflow.com/questions/29358626/file-path-to-input-txt-file-with-multiple-urls-for-download-reported-as-non-exis

Wget looks for "file\path\here" (the *NIX style) rather than Windows' "file/path/here" and thus reports that the selected input file doesn't exist even though it definitely exists.

I'm using wget-1.16.3-win64.exe (listed as wget64.exe there) from https://eternallybored.org/misc/wget/.

I'd appreciate any comments on this problem. Perhaps I'm doing something wrong, but I'm not sure what it is.

P.S. I'm sorry in advance if the same or a similar bug report has already been submitted, but I couldn't find anything similar in the bug tracker.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by angel_ (Posted a comment)
  • -unavailable- added by sahwar (Posted a comment)
  •  

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    No Changes Have Been Made to This Item

    Back to the top


    Powered by Savane 3.1-cleanup1