1484
I made some experiments and I can confirm that the problem is the mess windows does with filenames for compatibility reasons.
The easiest solution could be that Eric adds a call inside NWCInfo to the OemToChar function before opening the files when the switch /list is used.
But what would happen if someone prepares a file list "manually" and that list is already in the ANSI charset?
Exactly the opposite of what happens now.
Adding another command line switch to NWCInfo, e.g. something like /OEM, to enable the charset conversion could be a simple, fast and convenient solution to the problem.
Someone has a better idea?
In the meantime I opted for a quick (and dirty) solution like that (lets call it NWCList.bat) that seems to work fine:
@echo off
echo Creating the list of the NWC files with its data
echo The results are in NWC_Catalog.TSV (tab-separated values)
echo N.B. The files .nwctxt are ignored
dir /b /s *.nwc | find /i /v ".nwctxt" | OEMToANSI | NWCInfo /list > NWC_Catalog.TSV
echo Done
pause
Of course, the juicy part is the line starting with "dir".
dir /b /s *.nwc prepares the list as usual (OEM charset)
find /i /v ".nwctxt" removes all the files *.nwctxt from the list
OEMToANSI is a small program I did to convert from locale codepage (OEM) to ANSI
NWCInfo /list > NWC_Catalog.TSV is the usual part.
If you want (and have time...) you can scan the full drive C: as already suggested: dir /b /s C:\*.nwc
With my big HD it's not a good idea.
If I'm right, I can not attach an executable here so it is downloadable from
http://rapidshare.com/files/167179223/NWCList.zip.html.
(N.B. It seems it's downloadable only 10 times and for 90 days. If we don't find a better solution I'll send it to Richard for the scripto)
Here I show the deplhi source code.
program OEMToANSI;
{$APPTYPE CONSOLE}
uses
Windows;
var
S: string;
begin
while not EOF(input) do
begin
readln(S);
OemToChar(PChar(S), PChar(S));
writeln(S);
end;
end.
Wow! What seemed a trivial operation...
Rick, the wizard of scripts, do you have a cleaner solution?
N.B. Erik, I think that, as Rick said, this thread is in need of a little clean-up. Sorry for all my cluttering.
1485
Hi Bob.
Yes, of course. And indeed this was my first though.
But in this case NWCInfo /list reads the list of filenames generated by piping the output of the dir command and parses each line as a filename. I have no control on it.
Luckily NWCInfo is aware of the problem of the blanks in the filenames and handles it correctly.
Not so for the non-ASCII letters.
Years ago I read something somewhere (vague enough? :-) about the problem of the command line commands outputting filenames in the OEM codepage while the windows GDI programs work with the ANSI (or, more recently, Unicode) charset.
Indeed, if I send the output of the dir command to a file, the filenames are in the OEM codepage.
I hoped in the command
%ComSpec% /a /c dir /s /b *.nwc > foo
but the result is unchanged.
Using the command
%ComSpec% /u /c dir /s /b *.nwc > foo
the result changes: the output file is empty! :-(
N.B. I'm using win2000, just in case...
