On 16 Jan 2002 at 17:27, Hrvoje Niksic wrote: > "Ian Abbott" <[EMAIL PROTECTED]> writes: > > File-names used within the internals of Wget need to be converted > > to an external form which deals with illegal characters or illegal > > sequences of characters in the file-name. > > I'm not quite following you here. Specifically, I don't see a reason > to make a distinction between internal and external file names. Why > not just make url_filename perform all the transformations? (This is > how Wgat works now, except it needlessly ties the transformations to > URL syntax.)
My original post was a bit muddled. Okay, just think of the internal form as a file-name for an ideal file-system with no naming restriction (other than names being null-terminated). They don't have to persist - it's just a logical point in the transformation to an external file-name. They may not exist at all if two transformations are combined into one. Perhaps "ideal file-name" would be a better description. Most (all?) of the escape sequences within URLs should be decoded before transforming to an external file-name. The point between the two is my "internal" or "ideal" file-name, but the two steps can be combined. > Someone submitted the %->@ patch to me at some point. If % is indeed > legal under Windows, I'd prefer to use that instead, so that we use > the same character on Windows and Unix. If you enter an invalid file-name in Windows Explorer, an alert pops open, which (in the English version) says: A filename cannot contain any of the following characters: \ / : * ? " < > | I guess we'll have to check back in the mail archives to find out the original argument for the %->@ patch. The ChangeLog entry is dated 1997-01-18.
