Tue 01 Sep 2009 06:01:16 AM UTC, comment #3:
Well, if we did that, it would escape various characters unnecessarily, which wouldn't be ideal.
Probably, it should behave exactly like "unix", except with the additional requirement that colons are also escaped (and, probably, the ":port" should become "@port", as it does in Windows).
The magic is in the filechr_table array in url.c, and the macro FILE_CHAR_TEST. Each element of filechr_table is a bitmask of values for: control character, escape-on-windows, escape-on-unix, with a few macros representing shorthand combinations of those (UW = escape on unix and windows). As you'll see when you look at it, to keep the structure as it currently is, you'd just add a new bit value for mac os, and add a UM macro (for escape on unix and mac: all "U" entries would become "MU"), and a "MW" macro for the colon entry.
The logic for :port -> @port in FN_QUERY_SEP would also need adjusting.
|
Tue 01 Sep 2009 04:58:03 AM UTC, comment #2:
Is there a good reason to not just let:
--restrict-file-names=windows
--restrict-file-names=macos
actually do the same thing in the code?
This will be a new branch of code for me to look at. I'll take the assignment if you like, Micah.
|
Fri 24 Jul 2009 08:38:23 PM UTC, comment #1:
The ":" -> "/" thing is something Mac OS X is doing. If it's going to make that transformation, then it ought to continue supporting it for finding the files again :\
Perhaps this should take the form of an --restrict-file-names=macos option, since it's specific to MacOS.
The ":" in the converted links, though, ought to be percent-encoded, even if they aren't in the original filename, since otherwise it represents a scheme name.
As a workaround, consider using --restrict-file-names=windows, which will include ":" as a character that shouldn't be emitted, but won't currently use any characters that are unsafe for Unix.
|
Fri 24 Jul 2009 10:35:48 AM UTC, original submission:
I tried to download the Twitter apiwiki using
wget -rkp http://apiwiki.twitter.com/
Unfortunately the wiki uses ":" in links, which results in converted links of the form "twitter-search-api-method:-search"
Trying to follow these links results in an "unkown protocol" error by Firefox, because "twitter-search-api-method:" is being interpreted as a protocol part of an URL.
Also, the filenames seem to have ":" converted to "/", so the file is called "Twitter-Search-API-Method/-search". That also seems to cause semi-troubles on the OS X file system (some programs can open the file, others can't).
|