 |
lua-l archive |
|
|
||
|
steve donovan wrote:
Well, I never tried parsing dir /B, so I suppose there could be problem only if filenames contained 8-bit non-ASCII chars. Fairly common in Italy when file names are chosen by non-programmers, since several common words in our language contain accented vowels (not so many as French, but still many more than English). Feeding non-ASCII chars through different "layers" have always been a mess in my experience. I remembering having to feed the names of files containing German chars generated from a Perl script (not written by me) to a command-line tool written in Java (by me) and spending some days to track down why all those chars were messed-up when passing through WinXp shell redirection and passing-through unaltered when written to a text file! Moreover, if I fed the names directly from the shell to my tool they got messed-up in a different way!!! (ugh!) :-( The solution (I don't remember the details now - ~6 years ago) had to do with setting the codepage to a Reader class in Java, but discovering the codepage code was a matter of trial and error (had to try more than 20something codepages!!!)On Tue, Nov 2, 2010 at 11:50 AM, Lorenzo Donati <lorenzodonatibz@interfree.it> wrote:But is it not the parsing of console programs output a bit too brittle? I use a localized (Italian) WinXP and all the commandline tools are localized, so their output is full of codepage specific chars (eg. ийм).That's a good point. I would hope that commands that give 'bare' output (like dir /B) would work, but the filenames might be odd?
templates and high level OO stuff) so I'm not a big fan of makefiles - I wish there could be a better tool, but I acknowledge it is standard, so (sigh!) ... .OK, time for an advertisment (we are all allowed this once a month ;)) http://github.com/stevedonovan/Lake (just needs luafilesystem)
I followed briefly the annoucement, but is it still in alpha/beta stage? And does it allow installation without luarocks? (didn't have the time to chek it out) -- Lor