[GRASS-dev] WinGRASS and non-latin letters

Maris Nartiss maris.gis at gmail.com
Sun Mar 20 11:44:07 EDT 2011


2011/3/20, Glynn Clements <glynn at 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 <glynn at gclements.plus.com>
>

Maris.


More information about the grass-dev mailing list