Is there an option in wget for windows to handle folders that have spaces at end in Windows?
If I want to download something from an URL like http://www.server.com/dirname /some.zip (notice the space at the end of the folder name), wget with options -x -nH cannot download the file some.zip because it cannot create the "dirname " folder.
I would like to be able to download the file but save it to disk to folder "dirname" without spaces.
Is this possible? Where to hack the source if not?
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2009-06-04
Sorry, you're right. wget CAN create the folder, but it cannot write to it once created, hence, the file cannot be saved.
So, my question remains, is it possible to make a patch that creates the folder without trailing space and writes to that folder, instead of creating folder with space which is then unusable?
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, mkdir can create a folder with a space at the end of its name, but only when you end the name with a slash. And other folder accessing functions also need this slash at the end of the folder name. So everywhere in the wget source where a folder name is used, one would have to add a slash. The alternative is to delete any trailing spaces before calling mkdir. The latter would be the simplest, because it will probably occur only once or perhaps a few times.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Yes, mkdir can create a folder with a space at the end of its name,
> but only when you end the name with a slash...
Thanks for this, Kees.
That information would likely be relevant to the MSYS bug report too. Would you care to add an appropriate comment, (so you get the attribution), or shall I do so on your behalf?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is there an option in wget for windows to handle folders that have spaces at end in Windows?
If I want to download something from an URL like http://www.server.com/dirname /some.zip (notice the space at the end of the folder name), wget with options -x -nH cannot download the file some.zip because it cannot create the "dirname " folder.
I would like to be able to download the file but save it to disk to folder "dirname" without spaces.
Is this possible? Where to hack the source if not?
Thanks!
Sorry, you're right. wget CAN create the folder, but it cannot write to it once created, hence, the file cannot be saved.
So, my question remains, is it possible to make a patch that creates the folder without trailing space and writes to that folder, instead of creating folder with space which is then unusable?
Thanks!
For a URL such as
"http://www.server.com/dirname /some.zip"
> wget with options -x -nH cannot download the file some.zip
> because it cannot create the "dirname " folder.
Hmm. This doesn't answer your question, but one might wonder
"why not"? The _mkdir() function in Microsoft's runtime library
is perfectly capable of creating directories named with trailing
spaces, as indicated in this bug report:
https://sourceforge.net/tracker/?func=detail&aid=1959460&group_id=2435&atid=102435
Yes, mkdir can create a folder with a space at the end of its name, but only when you end the name with a slash. And other folder accessing functions also need this slash at the end of the folder name. So everywhere in the wget source where a folder name is used, one would have to add a slash. The alternative is to delete any trailing spaces before calling mkdir. The latter would be the simplest, because it will probably occur only once or perhaps a few times.
> Yes, mkdir can create a folder with a space at the end of its name,
> but only when you end the name with a slash...
Thanks for this, Kees.
That information would likely be relevant to the MSYS bug report too. Would you care to add an appropriate comment, (so you get the attribution), or shall I do so on your behalf?
Done.
Thanks, Kees.