Bug#833116: fgetty: Incorrect keystroke interpretation
Your patch below works perfectly well. Again, I have implemented it with
and without my custom .rcrc and everything will work just as expected.
Thank you very much. I've learned a lot with this.
Kindest regards,
Ricardo Peliquero
> From 200b7d217ee3ac54b376116e7d64ce0844ecbed9 Mon Sep 17 00:00:00 2001
> From: Dmitry Bogatov
> Date: Tue, 1 Jan 2019 22:52:18 +
> Subject: [PATCH] Fix #833116
>
> ---
> login2.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/login2.c b/login2.c
> index 8aaf6d6..156105b 100644
> --- a/login2.c
> +++ b/login2.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -61,6 +62,8 @@ main(int argc,char *argv[]) {
>char *shell=getenv("SHELL");
>char *Argv[]={"-sh",0};
>char *login=getenv("USER");
> +
> + setenv("LANG", "C.UTF-8", 1);
>if (getuid()==0) { /* checkpassword honored "nosetuid" */
> char *tmp=getenv("UID");
> char *tty=getenv("TTY");
>
>
Bug#833116: fgetty: Incorrect keystroke interpretation
[2018-12-31 13:46] Ricardo Peliquero
> > * setenv("LANG", "C.UTF-8", 1)
>
> It works as a breeze.
> Able to type 'ñandú' and other stuff with LANG=C.UTF-8.
> I can always put LANG=es_AR.UTF-8 and LANGUAGE=es_AR:es into .rcrc in
> order to fit my local needs, and it still works perfectly well.
Great. Seems we found solution. Let us make it minimal. I believe
of three places, changed in previous patch, only one is truly required.
Please try patch in this mail (at bootom).
> > * setenv("LC_ALL", "C.UTF-8", 1)
>
> It works, but LC_ALL variable might not be neccessary here. I'll of
> course respect your choice.
Of course, I agree that LC_ALL is big hammer here, that will overrule
user preferences, which is not apporiate.
> Thank you very much, and happy new year!
Thank you. It is pleasure to work with you.
From 200b7d217ee3ac54b376116e7d64ce0844ecbed9 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Tue, 1 Jan 2019 22:52:18 +
Subject: [PATCH] Fix #833116
---
login2.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/login2.c b/login2.c
index 8aaf6d6..156105b 100644
--- a/login2.c
+++ b/login2.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
@@ -61,6 +62,8 @@ main(int argc,char *argv[]) {
char *shell=getenv("SHELL");
char *Argv[]={"-sh",0};
char *login=getenv("USER");
+
+ setenv("LANG", "C.UTF-8", 1);
if (getuid()==0) { /* checkpassword honored "nosetuid" */
char *tmp=getenv("UID");
char *tty=getenv("TTY");
Bug#833116: fgetty: Incorrect keystroke interpretation
Dmitry Bogatov Sat, 29 Dec 2018 18:33:11 +:
> Could you try replace calls to `setlocale(LC_ALL, "")` in previous
> patch with (different variants)
> * setlocale(LC_ALL, "C.UTF-8")
Does not work (patch applies ok but won't be able to type 'ñandú').
> * setenv("LANG", "C.UTF-8", 1)
It works as a breeze.
Able to type 'ñandú' and other stuff with LANG=C.UTF-8.
I can always put LANG=es_AR.UTF-8 and LANGUAGE=es_AR:es into .rcrc in
order to fit my local needs, and it still works perfectly well.
> * setenv("LC_ALL", "C.UTF-8", 1)
It works, but LC_ALL variable might not be neccessary here. I'll of
course respect your choice.
> Also, could you please use unified diffs (diff -U) -- they are easier
> to read? Thank you.
Certainly; suggestion appreciated.
Thank you very much, and happy new year!
Bug#833116: fgetty: Incorrect keystroke interpretation
[2018-12-27 21:07] Ricardo Peliquero
> Dmitry Bogatov Sat, 22 Dec 2018 13:33:18 +:
>
> > $ dgit clone fgetty
> > $ cd fgetty
> > $ git am /path/to/this/message
> > $ dgit build
> > $ sudo debi
>
> I had to specify xx.changes location to last instruction.
> ; su -c 'debi ../fgetty_0.7-4_multi.changes'
>
> Patch applied, but no changes after it. Please, let me know if I made
> something wrong.
>
> Indeed, I completely purged fgetty and followed instructions again to
> make sure that the patched package is used. But, no success.
Thank you for your patience.
> [...]
Sorry, I did not understood what you suggest from your experiments with
mksh, except that it has something to do with "C.UTF-8" locale. But I
have some more experiments to propose about it:
Could you try replace calls to `setlocale(LC_ALL, "")` in previous patch
with (different variants)
* setlocale(LC_ALL, "C.UTF-8")
* setenv("LANG", "C.UTF-8", 1)
* setenv("LC_ALL", "C.UTF-8", 1)
Also, could you please use unified diffs (diff -U) -- they are easier to
read? Thank you.
Bug#833116: fgetty: Incorrect keystroke interpretation
Dmitry Bogatov Sat, 22 Dec 2018 13:33:18 +:
> $ dgit clone fgetty
> $ cd fgetty
> $ git am /path/to/this/message
> $ dgit build
> $ sudo debi
I had to specify xx.changes location to last instruction.
; su -c 'debi ../fgetty_0.7-4_multi.changes'
Patch applied, but no changes after it. Please, let me know if I made
something wrong.
Indeed, I completely purged fgetty and followed instructions again to
make sure that the patched package is used. But, no success.
But, I think that mksh package might give us some light:
; LANG=C apt-cache depends mksh
mksh
Depends: libc6
Recommends: ed
; su - -c 'aptitude install mksh'
; su - -c 'adduser --shell /bin/mksh testmksh'
; ls -la /home/testmksh/
total 28
drwxr-xr-x 2 testmksh testmksh 4096 dic 27 18:44 .
drwxr-xr-x 8 root root 4096 dic 27 18:44 ..
-rw-r--r-- 1 testmksh testmksh 220 dic 27 18:44 .bash_logout
-rw-r--r-- 1 testmksh testmksh 3526 dic 27 18:44 .bashrc
-rw-r--r-- 1 testmksh testmksh 2181 dic 27 18:44 .kshrc
-rw-r--r-- 1 testmksh testmksh 1703 dic 27 18:44 .mkshrc
-rw-r--r-- 1 testmksh testmksh 807 dic 27 18:44 .profile
; cat /home/testmksh/.mkshrc # ... showing interesting part only:
# force sane environment (e.g. for scripting), Debian-specific libc
# patch
#\\builtin export LC_ALL=C.UTF-8
# - or - switch to a slightly user-friendly and more portable locale
#\\builtin unset LANGUAGE LC_ADDRESS LC_ALL LC_COLLATE
#LC_IDENTIFICATION LC_MONETARY \
#LC_NAME LC_NUMERIC LC_TELEPHONE LC_TIME
#p=en_GB.UTF-8
#\\builtin export LANG=C LC_CTYPE=$p LC_MEASUREMENT=$p LC_MESSAGES=$p
#LC_PAPER=$p
# in either case: sync mksh UTF-8 mode to current locale (expected on
# GNU)
\\builtin set -U; [[ ${LC_ALL:-${LC_CTYPE:-${LANG:-}}} = \
*[Uu][Tt][Ff]?(-)8* ]] || \\builtin set +U
#\\builtin unset p
Let's test it:
; cat /etc/inittab | grep '^[1-3]:'
1:2345:respawn:/sbin/getty --noclear 38400 tty1
2:23:respawn:/sbin/getty --login-program /lib/fgetty/login1 38400 tty2
3:23:respawn:/sbin/fgetty tty3
; su - -c reboot
testmksh@tty1:~ $ echo áéíóú ÁÉÍÓÚ ïü ÏÜ ñÑ > test_tty1.txt
testmksh@tty1:~ $ cat test_tty1.txt
testmksh@tty1:~ $ áéíóú ÁÉÍÓÚ ïü ÏÜ ñÑ
testmksh@tty[2-3]:~ $ echo áéíóú ◈^◈◈^◈◈^◈◈^◈◈^◈ ïü ◈^◈◈^◈ ñ◈^◈ \
>> test_tty2-3.txt
cat test_tty2-3.txt
áéíóú ÁÉÍÓÚ ïü ÏÜ ñÑ
áéíóú ÁÉÍÓÚ ïü ÏÜ ñÑ
... Made some changes in .mkshrc:
testmksh@et1:~ $ diff .mkshrc.old .mkshrc # garbage cut off
< #\\builtin unset LANGUAGE LC_ADDRESS LC_ALL LC_COLLATE \
< # LC_IDENTIFICATION LC_MONETARY \
< # LC_NAME LC_NUMERIC LC_TELEPHONE LC_TIME
---
> \\builtin unset LANGUAGE LC_ADDRESS LC_ALL LC_COLLATE \
> LC_IDENTIFICATION LC_MONETARY \
> LC_NAME LC_NUMERIC LC_TELEPHONE LC_TIME
< #p=en_GB.UTF-8
< #\\builtin export LANG=C LC_CTYPE=$p LC_MEASUREMENT=$p \
< # LC_MESSAGES=$p LC_PAPER=$p
---
> p=es_AR.UTF-8
> \\builtin export LANG=C LC_CTYPE=$p LC_MEASUREMENT=$p \
> LC_MESSAGES=$p LC_PAPER=$p
< #\\builtin unset p
---
> \\builtin unset p
testmksh@tty[1-3]:~ exit
login tty1, tty2, tty3: testmksh
et voilà!
typing áéíóú ÁÉÍÓÚ ïü ÏÜ ñÑ will show all characters
just as expected.
By the way, if I happen to type 'ñandú' at tty3 login, that is within
fgetty, before applying any environmental variable from any shell
script, the characters will show OK, while tty1,2 login will only show
'and'.
Regards,
Ricardo
Bug#833116: fgetty: Incorrect keystroke interpretation
[2018-12-21 13:52] Anton Zinoviev
> 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.
Okay. Thank you for knowledge you already shared.
[ I believe we could drop Anton from thread for now ]
Dear sumbitter, could you please try following patch. I believe the
simpliest way to do it is to use bin:dgit and bin:devscripts
$ dgit clone fgetty
$ cd fgetty
$ git am /path/to/this/message
$ dgit build
$ sudo debi
From daef6bd98ba309a89c4e126884cae417572b61a3 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Fri, 21 Dec 2018 19:52:00 +
Subject: [PATCH] Set locale
---
fgetty.c | 4
login.c | 4
login2.c | 2 ++
3 files changed, 10 insertions(+)
diff --git a/fgetty.c b/fgetty.c
index 6cadbdd..a18c1c4 100644
--- a/fgetty.c
+++ b/fgetty.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include "fmt.h"
@@ -268,6 +269,9 @@ int main(int argc,char *argv[]) {
char *logname;
int i;
char hostname_end='.';
+
+ setlocale(LC_ALL, "");
+
tty=argv[1];
if (!tty)
error("usage: fgetty 1\n"
diff --git a/login.c b/login.c
index 6cd81c3..a4b035a 100644
--- a/login.c
+++ b/login.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
void die(const char *message) {
__write2(message); __write2("\n");
@@ -66,6 +67,9 @@ main(int argc,char *argv[]) {
char password[100];
int pwlen;
char *Argv[]={"checkpassword",LOGIN2,0};
+
+ setlocale(LC_ALL, "");
+
pid_t child;
int utmpfd,wtmpfd;
{
diff --git a/login2.c b/login2.c
index 8aaf6d6..91cd710 100644
--- a/login2.c
+++ b/login2.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
@@ -61,6 +62,7 @@ main(int argc,char *argv[]) {
char *shell=getenv("SHELL");
char *Argv[]={"-sh",0};
char *login=getenv("USER");
+ setlocale(LC_ALL, "");
if (getuid()==0) { /* checkpassword honored "nosetuid" */
char *tmp=getenv("UID");
char *tty=getenv("TTY");
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
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? > [...]
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
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
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
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.
Bug#833116: fgetty: Incorrect keystroke interpretation
> control: tags -1 moreinfo > > It seems to me now that is more a libreadline6/libtinfo5 problem > > than especifically of fgetty/login1. > > Hi, two years after, with libreadline8 in archives, does problem still > persist? > Dear Dmitry, 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. 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 Kindest regards, Ricardo Peliquero
Bug#833116: fgetty: Incorrect keystroke interpretation
control: tags -1 moreinfo [2016-08-10 14:40] Ricardo Fabian Peliquero > You are right. > > It seems to me now that is more a libreadline6/libtinfo5 problem than > especifically of fgetty/login1. Hi, two years after, with libreadline8 in archives, does problem still persist?
Bug#833116: fgetty: Incorrect keystroke interpretation
You are right.
It seems to me now that is more a libreadline6/libtinfo5 problem than
especifically of fgetty/login1.
Thank you very much! I have learned a lot with this testing.
I've applied your suggestion to .rcrc and have all ttys working as expected.
Regards,
Ricardo
On Wed, Aug 10, 2016 at 12:29:54PM +0300, Dmitry Bogatov wrote:
>
> control: tags 833116 +help +reproduce -moreinfo
> > [...]
>
> I am sorry. I have to admit, that I do not know, how to help further.
> In your particular case, you may want to add
>
> if (~ $RC_BOOTSTRAPPED ()) {
> RC_BOOTSTRAPPED = 1
> exec $SHELL
> }
>
> into your .rcrc.
>
> Try debian-user@, I wish you find someone, who knows more about
> teminals, locales and keys.
>
> --
> Accept: text/plain, text/x-diff
> Accept-Language: eo,en,ru
> X-Web-Site: sinsekvu.github.io
Bug#833116: fgetty: Incorrect keystroke interpretation
control: tags 833116 +help +reproduce -moreinfo
> [...]
I am sorry. I have to admit, that I do not know, how to help further.
In your particular case, you may want to add
if (~ $RC_BOOTSTRAPPED ()) {
RC_BOOTSTRAPPED = 1
exec $SHELL
}
into your .rcrc.
Try debian-user@, I wish you find someone, who knows more about
teminals, locales and keys.
--
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io
Bug#833116: fgetty: Incorrect keystroke interpretation
On Thu, Aug 04, 2016 at 03:47:19AM +0300, Dmitry Bogatov wrote: > Please, do following things: > > - set emacs (or anything that is interactive and does not link >readline) as login shell and tell, whether bug arises ngetty + ed is working ok. ngetty + francine is working wrong. > - since you said that good shell and bad shell differs in terminal >configuration, use `stty(1)' to configure bad shell as good one, >and via-verse. Mmm. I cannot reproduce this. stty -a is giving the same output now. It doesn't change anything stty -isig or stty isig > - replace login1 with following shell script (extremely insecure, >do not forget to revert) > #!/bin/bash > /bin/bash >and test following cases: > + ngetty with such login1 > + fgetty with such login1 I have tested `echo ñandú' in both cases, with the following results: + ngetty with login1 with bash script prints: echo and (while typing) and + fgetty with login1 with bash script script (I can't see anything while typing) outputs: and But, if I replace login1 with: #!/bin/sh /bin/sh + fgetty with login1 with sh script prints: (it won't print anything while typing 'echo ñandú') but the result is: ñandú + ngetty with login1 with sh script prints: # echo ñandú ñandú And, if I replace login1 with: #!bin/sh /bin/tcsh + fgetty with tcsh script echo \303\261and\303\272 ñandú + ngetty with tcsh script echo \303\261and\303\272 ñandú > > -- > Accept: text/plain, text/x-diff > Accept-Language: eo,en,ru > X-Web-Site: sinsekvu.github.io
Bug#833116: fgetty: Incorrect keystroke interpretation
On Thu, Aug 04, 2016 at 03:47:19AM +0300, Dmitry Bogatov wrote: > > > > > When trying to login with fgetty, I could read my password on the > > > > screen while typing. Did not continue. > > > > ngetty + login behaves good > > > > ngetty + login1 will get in well, but no key press will echo on the > > > > console. > > > > > > Sorry, I assumed you read C. This is intended behaviour. Please, > > > continue and tell, whether rest is OK. I expect terminal to be not in > > > good shape, but after `reset` I expect fancy letter to work. > > > > fgetty_patched + login1: ? doesn't show up, (arg: 1) instead, even after > > reset. > > > > ngetty + login1: no letter will show up after logging in, but they are > > there (except ?); that is, if I (blindly) type > > I am almost out of ideas. Let me sum all we have done: > > - problem raises in /bin/bash and /usr/bin/rc, but not in /bin/sh. That is correct. Also, I have installed csh, which depends on libbsd0 and libc6, and I can type my beloved word "ñandú". But, this is new, tcsh, which depends on libtinfo5 produces this: ~> echo \303\261and\303\272 ~> ñandú >Noteworthy, that /bin/sh does not link to libreadline. No, it links to dash(1), which depends on libc6 only. > - problem still present, even if we remove every terminal-manipulation >code from fgetty, login1, login2 It seems so. > - problem happens with root and non-root logins That's correct. It doesn't matter the priviledge that the user has. > - problem disappear in child process, and this child process have a bit >different terminal configuration: -isig vs isig OK, I suppose so. > - problem happens without fgetty binary, with only login1 and login2. That is correct. I tested login1 by configuring: # /etc/inittab: 5:23:respawn:/sbin/ngetty tty5 6:23:respawn:/sbin/ngetty tty6 # /etc/ngetty/Conf: Password: # options format: # [ttyX]=option[=value] #=debug =environ=,TERM=linux tty5=echo-off tty5=login-prog=/lib/fgetty/login1 tty5 will behave the same as tty4 (ngetty will behave as bad as fgetty when using login1). > - `reset' does not help I think that reset did something by applying the patch. I can look again. > > Please, do following things: > > - set emacs (or anything that is interactive and does not link >readline) as login shell and tell, whether bug arises OK. I will try with ed. > - since you said that good shell and bad shell differs in terminal >configuration, use `stty(1)' to configure bad shell as good one, >and via-verse. OK. I will be back to you with these testings. > - replace login1 with following shell script (extremely insecure, >do not forget to revert) > #!/bin/bash > /bin/bash >and test following cases: > + ngetty with such login1 > + fgetty with such login1 > > -- > Accept: text/plain, text/x-diff > Accept-Language: eo,en,ru > X-Web-Site: sinsekvu.github.io
Bug#833116: fgetty: Incorrect keystroke interpretation
> > > When trying to login with fgetty, I could read my password on the screen > > > while typing. Did not continue. > > > ngetty + login behaves good > > > ngetty + login1 will get in well, but no key press will echo on the > > > console. > > > > Sorry, I assumed you read C. This is intended behaviour. Please, > > continue and tell, whether rest is OK. I expect terminal to be not in > > good shape, but after `reset` I expect fancy letter to work. > > fgetty_patched + login1: � doesn't show up, (arg: 1) instead, even after > reset. > > ngetty + login1: no letter will show up after logging in, but they are > there (except �); that is, if I (blindly) type I am almost out of ideas. Let me sum all we have done: - problem raises in /bin/bash and /usr/bin/rc, but not in /bin/sh. Noteworthy, that /bin/sh does not link to libreadline. - problem still present, even if we remove every terminal-manipulation code from fgetty, login1, login2 - problem happens with root and non-root logins - problem disappear in child process, and this child process have a bit different terminal configuration: -isig vs isig - problem happens without fgetty binary, with only login1 and login2. - `reset' does not help Please, do following things: - set emacs (or anything that is interactive and does not link readline) as login shell and tell, whether bug arises - since you said that good shell and bad shell differs in terminal configuration, use `stty(1)' to configure bad shell as good one, and via-verse. - replace login1 with following shell script (extremely insecure, do not forget to revert) #!/bin/bash /bin/bash and test following cases: + ngetty with such login1 + fgetty with such login1 -- Accept: text/plain, text/x-diff Accept-Language: eo,en,ru X-Web-Site: sinsekvu.github.io
Bug#833116: fgetty: Incorrect keystroke interpretation
On Wed, Aug 03, 2016 at 11:52:57AM +0300, Dmitry Bogatov wrote: > > > When trying to login with fgetty, I could read my password on the screen > > while typing. Did not continue. > > ngetty + login behaves good > > ngetty + login1 will get in well, but no key press will echo on the console. > > Sorry, I assumed you read C. This is intended behaviour. Please, > continue and tell, whether rest is OK. I expect terminal to be not in > good shape, but after `reset` I expect fancy letter to work. fgetty_patched + login1: ñ doesn't show up, (arg: 1) instead, even after reset. ngetty + login1: no letter will show up after logging in, but they are there (except ñ); that is, if I (blindly) type "echo ñandú", it will return "and". But, after reset, I can see "echo and" while typing "echo ñandú" with the same result "and". This time, (arg: 1) appears when typing "ñ", and just a beep while typing key stroke sequence for "ú". > > (Sure, it is not secure and you are encouraged to reinstall version > from sid afterward). Probably I have one idea for your case. OK. Let me know if there is anything I can do. > > -- > Accept: text/plain, text/x-diff > Accept-Language: eo,en,ru > X-Web-Site: sinsekvu.github.io
Bug#833116: fgetty: Incorrect keystroke interpretation
> When trying to login with fgetty, I could read my password on the screen > while typing. Did not continue. > ngetty + login behaves good > ngetty + login1 will get in well, but no key press will echo on the console. Sorry, I assumed you read C. This is intended behaviour. Please, continue and tell, whether rest is OK. I expect terminal to be not in good shape, but after `reset` I expect fancy letter to work. (Sure, it is not secure and you are encouraged to reinstall version from sid afterward). Probably I have one idea for your case. -- Accept: text/plain, text/x-diff Accept-Language: eo,en,ru X-Web-Site: sinsekvu.github.io
Bug#833116: fgetty: Incorrect keystroke interpretation
> control: tags -moreinfo +help
>
I have applied the following patch as instructed. Please, see the results at
the bottom.
> - please apply following patch and tell, if anything changes
--- a/login.c
+++ b/login.c
@@ -45,17 +45,9 @@ void die(const char *message) {
struct termios oldtermios;
static void echo_off() {
- struct termios foo;
- if (tcgetattr(0,))
-die("tcgetattr failed");
- foo=oldtermios;
- foo.c_lflag &= ~(ECHO | ECHOE | ECHOK | ECHONL);
- tcsetattr(0, TCSANOW, );
}
static void echo_on() {
- oldtermios.c_lflag |= ECHO | ECHOE | ECHOK;
- tcsetattr(0, TCSANOW, );
}
main(int argc,char *argv[]) {
--- a/fgetty.c
+++ b/fgetty.c
@@ -32,11 +32,6 @@ void error(char *message,int exitcode) {
}
static void echo_off() {
- struct termios foo;
- if (!tcgetattr(0,)) {
-foo.c_lflag &= ~(ECHO | ECHOE | ECHOK | ECHONL);
-tcsetattr(0, TCSANOW, );
- }
}
int doutmp() {
---
---
> $ cd /tmp
> $ apt-get source fgetty
> $ save-my-last-email-to /tmp/email
> $ cd fgetty-0.7
> $ quilt import ../tmp/email
> $ dpkg-buildpackage -us -uc
> $ sudo debi
When trying to login with fgetty, I could read my password on the screen while
typing. Did not continue.
ngetty + login behaves good
ngetty + login1 will get in well, but no key press will echo on the console.
>
> --
> Accept: text/plain, text/x-diff
> Accept-Language: eo,en,ru
> X-Web-Site: sinsekvu.github.io
Bug#833116: fgetty: Incorrect keystroke interpretation
Made some experiments below. Will continue tonight. On Tue, Aug 02, 2016 at 02:37:02PM +0300, Dmitry Bogatov wrote: > > control: tags -moreinfo +help > > Seems I managed to somehow reproduce it. I can reproduce only with > root login. I need some time to accustomize myself to `la-latin1' and > take a look, what can be different in root and non-root logins. Awesome. Our first typing lesson here is "asdf ñlkj". I rarely login as root, prefer "su -c 'command arg'" than "su -". `sudo' is not even installed. Anyway, this root uses /bin/bash, but will change to /bin/sh for this experiment, I use rc(1). > Do you have problems with non-root login? - 'ñ' is echoed ok with /bin/sh for root and non-root logins, either with /bin/login and /lib/fgetty/login1 > Also, in my case problem is a bit another: > > - everything is perfect with non-root login > > - /bin/sh as root behaves good > > - /bin/bash (/bin/rc) behaves bad, and all its childs too. > > > > Also, let me ask you to check some of my wild guesses: > > > > > > - please, invoke `stty -a' in bad and good shells and tell, > > >if there is any difference. Yes: -isig vs. isig. Please, see below: # In ngetty with /lib/fgetty/login1 non-root /bin/rc: (arg: 1) echo ; stty-a speed 38400 baud; rows 48; columns 170; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0; -parenb -parodd -cmspar cs8 hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc ; ; ## Reset won't help ; reset ; (arg: 1) echo ; /usr/bin/rc ; echo ñ ñ ; ; exit ; (arg: 1) echo ; exit # In ngetty with /bin/login (tty5) non-root /bin/rc: ; echo ñ ñ ; stty-a speed 38400 baud; rows 48; columns 170; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0; -parenb -parodd -cmspar cs8 hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc # In ngetty with /lib/fgetty/login1 (tty6) root /bin/sh: # echo ñ ñ # stty -a speed 38400 baud; rows 48; columns 170; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0; -parenb -parodd -cmspar cs8 hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc # In ngetty with /bin/login root /bin/sh: # echo ñ ñ # stty -a speed 38400 baud; rows 48; columns 170; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0; -parenb -parodd -cmspar cs8 hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc > Still waiting for this experiments. > > /bin/sh works well in all the six shells > > Very intresting. Please try: > - absolute clean bash and zsh shells ($HOME/.bashrc, $HOME/.bash_profile, > etc) > - set something interactive, that does not link to readline (for example, > emacs or ghci) > > > > - please apply following patch and tell, if anything changes > > I will have to learn how to apply patches first. Please, be patient. > > $ cd /tmp > $ apt-get source fgetty > $ save-my-last-email-to /tmp/email > $ cd fgetty-0.7 > $ quilt import ../tmp/email > $ dpkg-buildpackage -us -uc > $ sudo debi Thank you for this. You saved me hours of investigation. I will definitely try it out. > > -- > Accept: text/plain, text/x-diff > Accept-Language: eo,en,ru > X-Web-Site: sinsekvu.github.io >
Bug#833116: fgetty: Incorrect keystroke interpretation
control: tags -moreinfo +help > Made some progress here! I haven't tried all your suggestions yet, but please > see below. Great. > On Mon, Aug 01, 2016 at 10:06:49PM +0300, Dmitry Bogatov wrote: > > > > How insert this fancy letter "?"? I tried to `loadkeys es', but I > > failed to locate this letter. > My keyboard layout is Latin American Spanish: `loadkeys la-latin1' > The "�" is one key to the right of "l" (in qwerty) (where the ";" > key is in English layout). That is keycode 39. Seems I managed to somehow reproduce it. I can reproduce only with root login. I need some time to accustomize myself to `la-latin1' and take a look, what can be different in root and non-root logins. Do you have problems with non-root login? Also, in my case problem is a bit another: - everything is perfect with non-root login - /bin/sh as root behaves good - /bin/bash (/bin/rc) behaves bad, and all its childs too. > > Also, let me ask you to check some of my wild guesses: > > > > - please, invoke `stty -a' in bad and good shells and tell, > >if there is any difference. > > - please, try to call 'reset' in bad shell and see, whether it helps Still waiting for this experiments. > > - please, change your shell to /bin/sh and tell, whether anything changes > >(/bin/sh does not have .rc file, to make more clean experiment) > Hmmm. /bin/sh works well in all the six shells!!! That is something. Very intresting. Please try: - absolute clean bash and zsh shells ($HOME/.bashrc, $HOME/.bash_profile, etc) - set something interactive, that does not link to readline (for example, emacs or ghci) > > - please apply following patch and tell, if anything changes > I will have to learn how to apply patches first. Please, be patient. $ cd /tmp $ apt-get source fgetty $ save-my-last-email-to /tmp/email $ cd fgetty-0.7 $ quilt import ../tmp/email $ dpkg-buildpackage -us -uc $ sudo debi -- Accept: text/plain, text/x-diff Accept-Language: eo,en,ru X-Web-Site: sinsekvu.github.io
Bug#833116: fgetty: Incorrect keystroke interpretation
Made some progress here! I haven't tried all your suggestions yet, but please
see below.
On Mon, Aug 01, 2016 at 10:06:49PM +0300, Dmitry Bogatov wrote:
>
> How insert this fancy letter "?"? I tried to `loadkeys es', but I
> failed to locate this letter.
My keyboard layout is Latin American Spanish: `loadkeys la-latin1'
The "ñ" is one key to the right of "l" (in qwerty) (where the ";" key is in
English layout). That is keycode 39.
>
> Also, let me ask you to check some of my wild guesses:
>
> - please, invoke `stty -a' in bad and good shells and tell,
>if there is any difference.
> - please, try to call 'reset' in bad shell and see, whether it helps
> - please, change your shell to /bin/sh and tell, whether anything changes
>(/bin/sh does not have .rc file, to make more clean experiment)
Hmmm. /bin/sh works well in all the six shells!!! That is something.
> - please apply following patch and tell, if anything changes
I will have to learn how to apply patches first. Please, be patient.
>
> --- a/login.c
> +++ b/login.c
> @@ -45,17 +45,9 @@ void die(const char *message) {
> struct termios oldtermios;
>
> static void echo_off() {
> - struct termios foo;
> - if (tcgetattr(0,))
> -die("tcgetattr failed");
> - foo=oldtermios;
> - foo.c_lflag &= ~(ECHO | ECHOE | ECHOK | ECHONL);
> - tcsetattr(0, TCSANOW, );
> }
>
> static void echo_on() {
> - oldtermios.c_lflag |= ECHO | ECHOE | ECHOK;
> - tcsetattr(0, TCSANOW, );
> }
>
> main(int argc,char *argv[]) {
> --- a/fgetty.c
> +++ b/fgetty.c
> @@ -32,11 +32,6 @@ void error(char *message,int exitcode) {
> }
>
> static void echo_off() {
> - struct termios foo;
> - if (!tcgetattr(0,)) {
> -foo.c_lflag &= ~(ECHO | ECHOE | ECHOK | ECHONL);
> -tcsetattr(0, TCSANOW, );
> - }
> }
>
> int doutmp() {
>
> ---
> ---
>
> --
> Accept: text/plain, text/x-diff
> Accept-Language: eo,en,ru
> X-Web-Site: sinsekvu.github.io
>
Bug#833116: fgetty: Incorrect keystroke interpretation
> > Do I understand correctly, that /bin/bash, which is execed directly by
> > fgetty behaves bad, but any it's child is okay?
> That is correct. If /bin/bash -or other command interpreters
> available in Debian- are accessed through fgetty, they b ehave bad
> (interpretting [�-�] or "�" key presses as escape
> sequences). Besides, when trying to type [�-�,�], the system just
> beeps, that is: no "(arg: 1) " appear.
How insert this fancy letter "�"? I tried to `loadkeys es', but I
failed to locate this letter.
Also, let me ask you to check some of my wild guesses:
- please, invoke `stty -a' in bad and good shells and tell,
if there is any difference.
- please, try to call 'reset' in bad shell and see, whether it helps
- please, change your shell to /bin/sh and tell, whether anything changes
(/bin/sh does not have .rc file, to make more clean experiment)
- please apply following patch and tell, if anything changes
--- a/login.c
+++ b/login.c
@@ -45,17 +45,9 @@ void die(const char *message) {
struct termios oldtermios;
static void echo_off() {
- struct termios foo;
- if (tcgetattr(0,))
-die("tcgetattr failed");
- foo=oldtermios;
- foo.c_lflag &= ~(ECHO | ECHOE | ECHOK | ECHONL);
- tcsetattr(0, TCSANOW, );
}
static void echo_on() {
- oldtermios.c_lflag |= ECHO | ECHOE | ECHOK;
- tcsetattr(0, TCSANOW, );
}
main(int argc,char *argv[]) {
--- a/fgetty.c
+++ b/fgetty.c
@@ -32,11 +32,6 @@ void error(char *message,int exitcode) {
}
static void echo_off() {
- struct termios foo;
- if (!tcgetattr(0,)) {
-foo.c_lflag &= ~(ECHO | ECHOE | ECHOK | ECHONL);
-tcsetattr(0, TCSANOW, );
- }
}
int doutmp() {
---
---
--
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io
Bug#833116: fgetty: Incorrect keystroke interpretation
control: tags 833116 +moreinfo Thank you for your fast response. > > > When running virtual ttys with fgetty, I cannot type any spanish > > accented vowel nor the "eñe" into the console shell. > > What do you call 'console shell'? /bin/bash? The problem only happens after logging into virtual ttys called from fgetty (or ngetty configured to use login1). I use /usr/bin/rc as default shell; but, in order to discard any shell configuration, I have chsh /bin/bash and reboot. Indeed, I have created a new user with adduser to discard any .profile issue. The problem remains in both cases. > Do I understand correctly, that /bin/bash, which is execed directly by > fgetty behaves bad, but any it's child is okay? That is correct. If /bin/bash -or other command interpreters available in Debian- are accessed through fgetty, they behave bad (interpretting [á-ú] or "ñ" key presses as escape sequences). Besides, when trying to type [Á-Ú,Ñ], the system just beeps, that is: no "(arg: 1) " appear. But, if I execute any of these command interpreters again as a child process, or if I run any editor (e.g. ed), or even if I run script(1) or ttyrec, key strokes will echo the correct letters. > More information here, please. More detailed instruction how to reproduce > problem. script(1) would help. As I said, if I execute script(1), the keys will work OK. Anyway, I try to detail some extra information below. I hope it helps to debbug. # In /etc/inittab : 1:23:respawn:/sbin/fgetty tty1 2:23:respawn:/sbin/getty 38400 tty2 3:23:respawn:/sbin/mingetty tty3 4:23:respawn:/sbin/rungetty tty4 5:23:respawn:/sbin/ngetty tty5 6:23:respawn:/sbin/ngetty tty6 # In /etc/ngetty/Conf : # tty6=echo-off # (same result with this line enabled) tty6=login-prog=/lib/fgetty/login1 # 'dpkg -L fgetty' output is: /. /lib /lib/fgetty /lib/fgetty/login1 /lib/fgetty/login2 /usr /usr/share /usr/share/lintian /usr/share/lintian/overrides /usr/share/lintian/overrides/fgetty /usr/share/doc /usr/share/doc/fgetty /usr/share/doc/fgetty/changelog.Debian.gz /usr/share/doc/fgetty/changelog.gz /usr/share/doc/fgetty/copyright /usr/share/doc/fgetty/README /usr/share/man /usr/share/man/man8 /usr/share/man/man8/fgetty.8.gz /usr/share/man/man8/checkpassword.login.8.gz /sbin /sbin/fgetty /bin /bin/checkpassword.login # reboot and login into tty[1-6] # in tty5 type: ; ps -a PID TTY TIME CMD 2155 tty1 00:00:00 login1 2157 tty2 00:00:00 rc 2159 tty3 00:00:00 rc 2161 tty4 00:00:00 rc 2153 tty5 00:00:00 rc 2162 tty5 00:00:00 ps 2149 tty6 00:00:00 login1 # By pressing "ñ" key in: tty1: the console shows: "(arg: 1)" tty2: the console shows: "; ñ" tty3: the console shows: "; ñ" tty4: the console shows: "; ñ" tty5: the console shows: "; ñ" tty6: the console shows: "(arg: 1)" # I run /usr/bin/rc in tty1 and type "ñ". The screen displays: ; /usr/bin/rc ; ñ # By exiting this child program with ^d: ; exit # Press "ñ" key again, and: (arg: 1) ; /bin/bash : $ ñ # ps -a | grep tty1: 2817 tty1 00:00:00 bash ; ^d # Now, on other tty: ; ps -a | grep tty1 ; # Nothing there, as kindly expected from login1 :) # If I exit again with ^d and type "ñ": login: ñ ### Please, let me know any other information that might help. > > -- > Accept: text/plain, text/x-diff > Accept-Language: eo,en,ru > X-Web-Site: sinsekvu.github.io >
Bug#833116: fgetty: Incorrect keystroke interpretation
control: tags 833116 +moreinfo > When running virtual ttys with fgetty, I cannot type any spanish > accented vowel nor the "eñe" into the console shell. What do you call 'console shell'? /bin/bash? > I suspect it is a checkpassword.login problem. > If I run a subshell (e.g. bash, rc, dash) or a readline dependant > program (e.g. dvtm, mutt) it will succeed in printing out > áéíóúñ. Otherwise, the shell will interpret the key as an escape > secuence, and print "(arg: 1) _". The environment variables remain > the same, though. Do I understand correctly, that /bin/bash, which is execed directly by fgetty behaves bad, but any it's child is okay? > I don't have this problem in ttys started with standard login > program (through mingetty, ngetty, getty). But, if I in voke > checkpassword.login within this scenario, the problem reappears. More information here, please. More detailed instruction how to reproduce problem. script(1) would help. -- Accept: text/plain, text/x-diff Accept-Language: eo,en,ru X-Web-Site: sinsekvu.github.io
Bug#833116: fgetty: Incorrect keystroke interpretation
Package: fgetty Version: 0.7-1 Severity: normal Dear Maintainer, When running virtual ttys with fgetty, I cannot type any spanish accented vowel nor the "eñe" into the console shell. I suspect it is a checkpassword.login problem. If I run a subshell (e.g. bash, rc, dash) or a readline dependant program (e.g. dvtm, mutt) it will succeed in printing out áéíóúñ. Otherwise, the shell will interpret the key as an escape secuence, and print "(arg: 1) _". The environment variables remain the same, though. I don't have this problem in ttys started with standard login program (through mingetty, ngetty, getty). But, if I invoke checkpassword.login within this scenario, the problem reappears. I have already reconfigured the keymap, encoding and fonts without any luck. Any advise will be appreciated. Kind regards, Ricardo -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.6.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) -- ; cat /etc/default/keyboard XKBMODEL="pc105" XKBLAYOUT="latam" XKBVARIANT="" XKBOPTIONS="" BACKSPACE="guess" -- ; cat /etc/inittab | grep fgetty 1:23:respawn:/sbin/fgetty tty1 2:23:respawn:/sbin/fgetty tty2 3:23:respawn:/sbin/fgetty tty3 -- ; cat /etc/default/console-setup ACTIVE_CONSOLES="/dev/tty[1-6]" CHARMAP="UTF-8" CODESET="Uni1" FONTFACE="Fixed" FONTSIZE="8x16" VIDEOMODE= -- no debconf information
