Re: Bug#833116: fgetty: Incorrect keystroke interpretation
On Thu, Dec 20, 2018 at 06:02:47PM +, Dmitry Bogatov wrote: > > Anton, could you please clarify, how locale is set up by this function > call if process inhereted no locale-related variables. I don't know. Anton Zinoviev
Re: Bug#833116: fgetty: Incorrect keystroke interpretation
[2018-12-19 10:42] Ricardo Peliquero > Anton Zinoviev > Wed, 5 Dec 2018 21:29:10 +0200: > > > On Wed, Dec 05, 2018 at 08:56:16AM +, Dmitry Bogatov wrote: > > > Suppose that we have a working bash shell with UTF-8 console where ñ > > displays properly. Then try this: > > > > LANG=C bash # run a subshell in a non-UTF8 locale > > > > If you press ñ, you will see (arg: 1). The programs (including a > > subshell) also work incorrectly because the locale is not UTF8. > > > > Reproduced with expected result (within both login and login1 ttys). I got idea. No code in fgetty calls setlocale(3), while all tools from src:shadow use setlocale(LC_ALL, ""). Maybe it could help? Anton, could you please clarify, how locale is set up by this function call if process inhereted no locale-related variables. Maybe it would be better to call setlocale(LANG, "C.UTF-8") in login process, that execs shell? > [...]
Re: Bug#833116: fgetty: Incorrect keystroke interpretation
Dear all,
I have tested Anton's suggestions with the following results.
Please, see below for more information.
Steps made:
; su - -c 'adduser testbash'
...
; cat /etc/passwd | grep testbash
testbash:x:1002:1002:Test Bash,,,:/home/testbash:/bin/bash
; cat /etc/inittab | grep /sbin/getty | grep -v '^#'
1:2345:respawn:/sbin/getty --noclear 38400 tty1
2:23:respawn:/sbin/getty --login-program /lib/fgetty/login1 38400 tty2
Following steps, see below.
Thank you!
Ricardo Peliquero
Anton Zinoviev
Wed, 5 Dec 2018 21:29:10 +0200:
> On Wed, Dec 05, 2018 at 08:56:16AM +, Dmitry Bogatov wrote:
> Suppose that we have a working bash shell with UTF-8 console where ñ
> displays properly. Then try this:
>
> LANG=C bash # run a subshell in a non-UTF8 locale
>
> If you press ñ, you will see (arg: 1). The programs (including a
> subshell) also work incorrectly because the locale is not UTF8.
>
Reproduced with expected result (within both login and login1 ttys).
> Now execute this:
>
> LANG=. (some UTF-8 locale)
>
> Now, if you press ñ, you will see (arg: 1) like before. The programs
> (including a subshell), however, will work correctly.
>
Within login1:
typing ñ echoes (arg: 1)
$ LANG=es_AR.UTF-8 bash
typing ñ echoes ñ
> Now execute this:
>
> export LANG
>
> Now also ñ works correctly.
typing ñ echoes ñ
$ exit
typing ñ echoes (arg: 1)
> If you are sure that the problem does not come from the locale,
> another thing to check is to compare the output of
>
> bind -v
> bind -p
>
> in bash where ñ works properly and in bash where ñ leads to (arg: 1).
; diff bind_-v_testbash_login.txt bind_-v_testbash_login1.txt
8c8
< set convert-meta off
---
> set convert-meta on
; diff bind_-p_login.txt bind_-p_login1.txt > \
diff_bind-p_login_login1.txt # (attached)
> Also make sure there are no files ~/.inutrc and the variable INPUTRC
> is unset.
; env # within both ttys
; diff env_login.txt env_login1.txt # (both attached)
2,3c2,4
< LANG=es_AR.UTF-8
< HUSHLOGIN=FALSE
---
> drop_caps=
> INIT_VERSION=sysvinit-
> CONSOLE=/dev/console
5a7
> PREVLEVEL=N
7c9,12
< MAIL=/var/mail/testbash
---
> UID=1002
> init=/sbin/init
> BOOT_IMAGE=Linux
> edd=off
10,11c15,17
< SHLVL=1
< LANGUAGE=es_AR:es
---
> rootmnt=/root
> RUNLEVEL=2
> SHLVL=2
13a20
> AUTOBOOT=YES
; set # within both ttys
; diff set_login.txt set_login1.txt
0a1
> AUTOBOOT=YES
10a12
> BOOT_IMAGE=Linux
11a14
> CONSOLE=/dev/console
22d24
< HUSHLOGIN=FALSE
24,25c26
< LANG=es_AR.UTF-8
< LANGUAGE=es_AR:es
---
> INIT_VERSION=sysvinit-
30d30
< MAIL=/var/mail/testbash
37c37,38
< PPID=2702
---
> PPID=1
> PREVLEVEL=N
41a43
> RUNLEVEL=2
44c46
< SHLVL=1
---
> SHLVL=2
48c50,54
< _=set
---
> _=env
> drop_caps=
> edd=off
> init=/sbin/init
> rootmnt=/root
4c4
< "\e\C-g": abort
---
> "\M-\C-g": abort
11,12c11,12
< "\eOD": backward-char
< "\e[D": backward-char
---
> "\M-OD": backward-char
> "\M-[D": backward-char
16,22c16,22
< "\e\C-h": backward-kill-word
< "\e\C-?": backward-kill-word
< "\e\e[D": backward-word
< "\e[1;5D": backward-word
< "\e[5D": backward-word
< "\eb": backward-word
< "\e<": beginning-of-history
---
> "\M-\C-h": backward-kill-word
> "\M-\C-?": backward-kill-word
> "\M-\M-[D": backward-word
> "\M-[1;5D": backward-word
> "\M-[5D": backward-word
> "\M-b": backward-word
> "\M-<": beginning-of-history
24,27c24,27
< "\eOH": beginning-of-line
< "\e[1~": beginning-of-line
< "\e[H": beginning-of-line
< "\e[200~": bracketed-paste-begin
---
> "\M-OH": beginning-of-line
> "\M-[1~": beginning-of-line
> "\M-[H": beginning-of-line
> "\M-[200~": bracketed-paste-begin
29c29
< "\ec": capitalize-word
---
> "\M-c": capitalize-word
31c31
< "\e\C-]": character-search-backward
---
> "\M-\C-]": character-search-backward
34,40c34,40
< "\e\e": complete
< "\e!": complete-command
< "\e/": complete-filename
< "\e@": complete-hostname
< "\e{": complete-into-braces
< "\e~": complete-username
< "\e$": complete-variable
---
> "\M-\M-": complete
> "\M-!": complete-command
> "\M-/": complete-filename
> "\M-@": complete-hostname
> "\M-{": complete-into-braces
> "\M-~": complete-username
> "\M-$": complete-variable
46c46
< "\e[3~": delete-char
---
> "\M-[3~": delete-char
48,59c48,59
< "\e\\": delete-horizontal-space
< "\e-": digit-argument
< "\e0": digit-argument
< "\e1": digit-argument
< "\e2": digit-argument
< "\e3": digit-argument
< "\e4": digit-argument
< "\e5": digit-argument
< "\e6": digit-argument
< "\e7": digit-argument
< "\e8": digit-argument
< "\e9": digit-argument
---
> "\M-\\": delete-horizontal-space
> "\M--": digit-argument
> "\M-0": digit-argument
> "\M-1": digit-argument
> "\M-2": digit-argument
> "\M-3": digit-argument
> "\M-4": digit-argument
> "\M-5": digit-argument
> "\M-6": digit-argument
> "\M-7": digit-argument
> "\M-8": digit-argument
> "\M-9": digit-argument
87,112c87,112
< "\eA": do-lowercase-version
< "\eB": do-lowercase-version
< "\eC": do-lowercase-version
< "\eD": do-lowercase-version
< "\eE": do-lowercase-version
< "\eF": do-lowercase-version
Re: Bug#833116: fgetty: Incorrect keystroke interpretation
>Suppose that we have a working bash shell with UTF-8 console where ñ >displays properly. Then try this: > >LANG=C bash # run a subshell in a non-UTF8 locale > >If you press ñ, you will see (arg: 1). The programs (including a >subshell) also work incorrectly because the locale is not UTF8. > >Now execute this: > >LANG=. (some UTF-8 locale) > >Now, if you press ñ, you will see (arg: 1) like before. The programs >(including a subshell), however, will work correctly. > >Now execute this: > >export LANG > >Now also ñ works correctly. > >If you are sure that the problem does not come from the locale, another > >thing to check is to compare the output of > >bind -v >bind -p > >in bash where ñ works properly and in bash where ñ leads to (arg: 1). > >Also make sure there are no files ~/.inutrc and the variable INPUTRC is >unset. > >Anton Zinoviev Thank you for your tips, Anton. I will certainly try your suggestions and let you both know. Ricardo Peliquero
Re: Bug#833116: fgetty: Incorrect keystroke interpretation
On Wed, Dec 05, 2018 at 08:56:16AM +, Dmitry Bogatov wrote: > > [ Added console-setup maintainers into thread ] > Hello, dear console-setup maintainers. Could you please take a look at > this bug? Maybe the locale is not set properly by some versions of getty? If bash is started in a non-UTF8 locale and some of the startup scripts of bash assigns an UTF-8 locale to the LANG variable, we can expect problems exactly like this. Suppose that we have a working bash shell with UTF-8 console where ñ displays properly. Then try this: LANG=C bash # run a subshell in a non-UTF8 locale If you press ñ, you will see (arg: 1). The programs (including a subshell) also work incorrectly because the locale is not UTF8. Now execute this: LANG=. (some UTF-8 locale) Now, if you press ñ, you will see (arg: 1) like before. The programs (including a subshell), however, will work correctly. Now execute this: export LANG Now also ñ works correctly. If you are sure that the problem does not come from the locale, another thing to check is to compare the output of bind -v bind -p in bash where ñ works properly and in bash where ñ leads to (arg: 1). Also make sure there are no files ~/.inutrc and the variable INPUTRC is unset. Anton Zinoviev
Re: Bug#833116: fgetty: Incorrect keystroke interpretation
[2018-12-03 10:48] Ricardo Peliquero > > [ Dmitry Bogatov ] > > Hi, two years after, with libreadline8 in archives, does problem still > > persist? > > > Yes, the problem still persists; but, after investigating a little bit > more, it seems to me that it could be a console-setup package problem. > > > I have also installed ksh and mksh to make some tests, with the > following results: > > * mksh works partially (e.g.: lower-case vowels and 'ñ' echo as > expected, but upper-case don't). > > * ksh works perfectly well with Spanish special characters > (e.g.: 'echo "áéíóú ÁÉÍÓÚ ïü ÏÜ ¡¿"') within the console at least > (before entering X). It works bad in terminal emulator within X. > > * rc(1), which depends on readline library works as bad as before. Thank you for prompt response. But I still have no clue. [ Added console-setup maintainers into thread ] Hello, dear console-setup maintainers. Could you please take a look at this bug? > Please, do have a look at the these posts and let me know if they could > give us any clue, or if you think it has nothing to do with this > problem. The discussion is too technical for me, I am afraid. Changes > mentioned there date from a few weeks before I started to see the > problem within login1. > https://salsa.debian.org/installer-team/console-setup/compare/1.142...1.143 > https://salsa.debian.org/installer-team/console-setup/commit/ebab2dc218faf708357ffb841d65e476dd5e1462 Unfortunately, I do not see anything enlightening.
