> From: Ian Abbott [mailto:[EMAIL PROTECTED]]
[sorry for this late answer, I haven't been able to answer before.] > The URL fragment "some%20what" could be converted to a filename > "some what" during the URL to filename conversion. If ' ' is > considered file-system safe, no further change is necessary. If ' ' > is considered file-system unsafe, it would have to be escaped to > "some<ESC>20what", where '<ESC>' is whatever the file-system escape > character is. Just another point, somewhat obvious but not mentioned before - while de-encoding characters not-unsafe on the current filename that filename still must be legal for browsers when reading the downloaded files on the local filesystem, e.g. index.html referring to "some file .html" or anything. > Or are you saying that if a DOS variable or positional parameter > gets its value set to a filename that happens to contain some % > characters, then these could possibly be further expanded after the > expansion of the positional parameters? I don't think batch files > expand variables more than once, e.g.: That's what I thought, too, but still I'm wondering _why_ the weird %->@ has ever been done - if not neccessary it wouldn't ever have been added. Possibly some old platform ? Some version of a shell with bugs or whatever ? > An alternative, but slightly bizarre approach would be to extend > the filename over a set of subdirectories using escape characters > at the end of the intermediate subdirectory names. E.g. > "verylongname" could become "verylon@\gfile" (where '@' is the > escape character and '\' is the DOS directory separator), and > "very.long.name" could become "very.lo@\ng.na@\me", or > "very@2El@\ong@2En@\ame", or something similar, but that is getting > very silly! Very interesting, but this solution would REALLY aggravate the max-path-and-filename-length limitation present on some filesystems (at least iso9660). > An alternative to naming every preset we can think of is to to > supply several commented examples in sample.wgetrc. It depends how complex that configuration part will become, but I think it would be better not including that kind of info in wgetrc: People could have a bunch of scripts all using different filters, or even possibly dynamically created filters - messing with the .wgetrc is not a thing to do imho. So we need a syntax to load a command-line specified configuration anyway, and probably that would mean reading it from a file (too complex to specify it all on commandline), so I'd say keep that stuff completely out of wgetrc (except a command specifying the default conversion rules file). Heiko -- -- PREVINET S.p.A. [EMAIL PROTECTED] -- Via Ferretto, 1 ph x39-041-5907073 -- I-31021 Mogliano V.to (TV) fax x39-041-5907087 -- ITALY
