grass start up: buggy to_text_string

[martinl]

GRASS fails even start on Windows when username contains non-ascii characters

Traceback (most recent call last):
  File "C:\Program Files\GRASS GIS 7.4.0\etc\grass74.py", line 2003, in <module>
    main()
  File "C:\Program Files\GRASS GIS 7.4.0\etc\grass74.py", line 1854, in main
    set_paths(grass_config_dir=grass_config_dir)
  File "C:\Program Files\GRASS GIS 7.4.0\etc\grass74.py", line 620, in set_paths
    os.environ['MANPATH'] = to_text_string(addons_man_path)
  File "C:\Program Files\GRASS GIS 7.4.0\Python27\lib\os.py", line 420, in __setitem__
    putenv(key, item)
UnicodeEncodeError: 'ascii' codec can't encode character u'\u017e' in position 10: ordinal not in range(128)
Press any key to continue . . .

When I change line source:grass/trunk/lib/init/grass.py#L620​

            os.environ['MANPATH'] = to_text_string(addons_man_path)

to

            os.environ['MANPATH'] = addons_man_path

then GRASS starts and even MANPATH variable is set up correctly (including non-ascii characters). Function to_text_string is apparently buggy. Tested on Czech (cp1250) Windows 8.1.

[martinl]

to_text_string has been introduced 3 years ago in r65780

[wenzeslaus]

Right. The code is similar to _get_encoding()/decode()/encode() group in source:grass/trunk/lib/python/script/utils.py#L159​ from r65787. Do these functions work for you (assuming you can get around the startup issue)? All is basically based around locale.getdefaultlocale()[1].

[mlennert]

I think this is a classical case of it being better not to mess around with the original byte string. All we do is taking a string from an environment variable, adding two new path elements and putting it back into another environment variable:

addon_base = os.getenv('GRASS_ADDON_BASE')
[...]
addons_man_path = os.path.join(addon_base, 'docs', 'man')
os.environ['MANPATH'] = to_text_string(addons_man_path)

Do we really have to worry about encoding/decoding in that context ?

[martinl]

Replying to mlennert:

Do we really have to worry about encoding/decoding in that context ?

Encoding/decoding doesn't seems to be needed in this case.

addons_man_path = os.path.join(addon_base, 'docs', 'man')

perfectly works on my testing computer.

[hellik]

Replying to martinl:

Replying to mlennert:

Do we really have to worry about encoding/decoding in that context ?

Encoding/decoding doesn't seems to be needed in this case.

addons_man_path = os.path.join(addon_base, 'docs', 'man')

perfectly works on my testing computer.

a related ticket: #3500

[martinl]

In 72374:

disable to_text_string() in grass.py, see #3508

[martinl]

to_text_string() disabled in r72374. Planning backport to 7.4 and 7.2 branches, any objections?

[mlennert]

Replying to martinl:

to_text_string() disabled in r72374. Planning backport to 7.4 and 7.2 branches, any objections?

None from me.

[martinl]

In 72401:

disable to_text_string() in grass.py, see #3508 (merge r72374 from trunk)

[martinl]

In 72402:

disable to_text_string() in grass.py, see #3508 (merge r72374 from trunk)

[martinl]

Fixed in all affected branches: grass74 and grass72.