2011/3/20, Glynn Clements <gl...@gclements.plus.com>: > > Maris Nartiss wrote: > >> You are overlooking issues coming from current GRASS architecture. We >> have CLI+GUI mixture and thus have to deal with both codepages at same >> time. > > We have to deal with Unicode and the current ANSI codepage. There's no > fundamental reason why we should need to deal with the OEM codepage. .bat files and input from CMD.
>> I wrote a small test example for wish GUI. > > Okay; I think that the immediate problem here is due to the > "FOR ... usebackq" trick. AFAICT, it treats the output from the > command within the backquotes as being in the OEM codepage, when it's > actually in the ANSI codepage. Correct. > Also: > echo "%HOME%" > out.txt > > will use the OEM codepage when writing the file, but anything which > reads it is going to assume the ANSI codepage. Correct. > Other than that, it would just mean that the console displays > non-ASCII characters incorrectly, which doesn't affect programs which > aren't actually using the console. > > I suspect that the simplest fix is to replace init.bat with e.g. a > Python version. Not that easy. I set up all GRASS env variables via TCL. g.gisenv started to work (horay!) and I managet to launch gis.m (double horray!). Tools like d.vect/d.rast, w.what, g.copy, g.region seemed to work, still v.in.ogr and r.in.gdal both where failing with "DSN not found" and "File doesn't exist" on different file separators (/, \ and \\). Being unable to import/export any data makes little sense to run GRASS. Also I haven't tested any heavy shell/.bat files. If in GRASS 7 we get rid of any non-python stuff for startup and modules, it migh work. > -- > Glynn Clements <gl...@gclements.plus.com> > Maris. _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
