I'm running GNUPLOT Version 5.0 patchlevel 0 last modified 2015-01-01, installed it from precompiled binary gp500-win32-mingw.exe. Windows 8.1.
I start wgnuplot.exe, type letter 'я' (russian language) - wgnuplot exits.
Same for gnuplot.exe - letter 'я' and gnuplot exits.
All other russian letters work, i can type them in any combination and everything's fine. The single letter 'я' makes wgnuplot finish work and exit.
What character encoding does your input use?
Have you set this correctly in the environment?
'я' in UTF8 should be harmless
'я' in iso-8859-5 (Windows code page 28595) is \0239,
which I expect is also harmless
'я' in Windows code page 1251 is \0255 (8-bit representation of -1),
which I could imagine could cause problems if the input method
interprets it instead as end-of-file.
"show encoding" produces following output:
nominal character encoding is default
however LC_CTYPE in current locale is Russian_Russia.1251
"show locale":
gnuplot LC_CTYPE Russian_Russia.1251
gnuplot encoding default
gnuplot LC_TIME Russian_Russia.1251
gnuplot LC_NUMERIC C
"Encoding" page in documentation (http://gnuplot.sourceforge.net/docs_4.2/node179.html) shows just available codepages.
I also found something similar with encodings - http://gnuplot.10905.n7.nabble.com/Unicode-Input-in-Gnuplot-s-Interactive-Console-Windows-7-64bit-td19156.html.
and
https://sourceforge.net/p/gnuplot/bugs/1270/ (fixed, closed).
How should i correctly change/init environment for (w)gnuplot?
Confirmed. The bug is related to the fact that e.g.
msdos_getch()is returning acharwhere it should really return anint. Thusreadlineconfuses (char)0xff with EOF, which is (int)-1.This bug also applies to 4.6 and earlier and other platforms like e.g. OS/2.
Seems like it would be worth changing all those platform-specific functions in readline.c to
int func() rather than char func(). I see
msdos_getch
os2_getch
win_getch
Are there others?
Sorry for the delay. Fixed in CVS for version 5.1.