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

 
 

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

Submitter:  None
Submitted:  Mon 20 Apr 2015 06:40:55 PM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Status:  None
Privacy:  Public Assigned to:  None
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  Open Release:  1.16.3
Operating System:  Microsoft Windows Reproducibility:  None
Fixed Release:  None Planned Release:  None
Regression:  None Work Required:  None
Patch Included:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

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 Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code