bugGforth - Bugs: bug #57340, ekey goes into strange mode when...

 
 

bug #57340: ekey goes into strange mode when reading shift-backspace

Submitter:  None
Submitted:  Mon 02 Dec 2019 06:02:49 AM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  paysan
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 03 Dec 2019 11:19:40 AM UTC, comment #9: 

twm does not catch alt-tab.  LANC=C xterm produces 137 for alt-tab, while LANC=C.UTF-8 xterm produces 194 137 (i.e., the same code point).

Anton Ertl <anton>
Group administrator
Tue 03 Dec 2019 10:50:42 AM UTC, comment #8: 

I added a fix for both problems (not recognizing shift-tab, sticking in line-mode style when the unkeys buffer is not empty) to the v0-7 git branch.  Both fixes are backports from the current development branch, so the development branch has no problem.

Linux terminal has yet another escape sequence for shift/alt-tab, esc+tab; on other terminals you can't enter alt-tab, because the window manager will catch it.

Bernd Paysan <paysan>
Group administrator
Tue 03 Dec 2019 06:59:37 AM UTC, comment #7: 

I can reproduce this (shift-tab) in gforth 0.7.2 on an xterm in Debian 8, and in gforth-0.7.3 on an xterm that's connected to an Ubuntu 18.04 system through ssh, and on an lxterm running on the Ubuntu 18.04 system displaying through an ssh connection.  So it looks like Gforth is at fault.

On Gforth 0.7.9_20191128, this works as it should.

I notice that 0.7.3 does not know the escape-sequence and only returns the ESC, while 0.7.9_20191128 returns $9000001D, i.e., "k-tab k-shift-mask or".  If I disable recognizing this escape sequence, 0.7.9_20191128 still does not exhibit this line-mode-like behaviour.

So the bug is fixed in the development version.  Do we want to do anything about the bug in 0.7.3?

A workaround is to define

get-current esc-sequences set-current
$9000001D s" [Z" esc-sequence
set-current

This will get you the proper behaviour for shift-tab.  I expect that for other escape-sequences that Gforth does not know, Gforth will still show the line-mode-like behaviour.

Anton Ertl <anton>
Group administrator
Mon 02 Dec 2019 11:43:13 PM UTC, comment #6: 

I'M SO SORRY -- I don't know why I typed shift-backspace

What I meant (really) was shift-tab

could you give that a try?

(again my apologies... some weird dissonance)

Anonymous
Mon 02 Dec 2019 11:22:11 PM UTC, comment #5: 


comment #3:

> On another machine (Ubuntu submodule of Windows 10) it is:
> lrwxrwxrwx 1 root root 15 Jun 1  2019 /etc/alternatives/x-terminal-emulator -> /usr/bin/lxterm


But you likely aren't using that in the WSL, because there's no graphical session in WSL, only a terminal session.  You are using the terminal from Windows.  You can use it directly if you start an Xserver on Windows, and then start lxterm on the WSL instance.

I have Windows 1909, and there, using the mintty based terminal Microsoft has now (replacing the old cmd.exe-style terminal) works as it should.

> To further test, I also used termux on android to access the linux mint PC.  It also shows the same ekey effect. I can't tell you the etc/alternatives/x-terminal-emulator, because termux doesn't have that.


So you are using termux to access the PC, which means there's another remote connection (ssh? what? please say) in between your termux and the PC, which you don't mention.

> Next I did a fresh install of gforth on an Ubuntu VPS installed on vultr.com (using sudo apt-get install gforth).  Tried ekey with shift-backspace there -- same effect from both PCs as well as Android termux.


You definitely don't sit in front of this cloud computer.  You have some remote connection.  This is likely the interesting part.

> I also accessed the VPS from a browser based terminal. However, that terminal did not seem to allow shift-backspace.  shift-backspace registered in gforth as just backspace.


Yes, that's the normal way.  There is no shift-backspace on the normal terminal.  It's not about “allow”, it's very likely that the remote connection software you are using intercepts shift-backspace, and when you press it, the terminal goes into line mode (without Gforth knowing about this).

> Finally, I tried XTerm on Windows 10, connecting to the ubuntu LSM.  There, keystrokes also don't show after ekey, but shift-backspace is captured as 27 (ESC).


Still, the interesting part is how you connect.

For us, Linux is on our PC right before us, not in a VM, not in the cloud.  The terminal is running on our computer.

> Oh, I also tried xterm on the Mint 18 (Ubuntu xenial equiv), but same effect.


So here you run an xterm locally and start gforth locally, or is there some other program in between that might filter out shift-backspace?

Bernd Paysan <paysan>
Group administrator
Mon 02 Dec 2019 10:58:28 PM UTC, comment #4: 

One more thing:  I have created a test account on the VPS that runs Ubuntu, in case you would like to log onto that machine and test with your terminal.

Just let me know, and I'll email you the login details.

cheers.

RdR

Anonymous
Mon 02 Dec 2019 10:47:40 PM UTC, comment #3: 

On one machine (Linux Mint 18) the output of ls -l /etc/alternatives/x-terminal-emulator is:

lrwxrwxrwx 1 root root 31 Feb 16  2019 /etc/alternatives/x-terminal-emulator -> /usr/bin/xfce4-terminal.wrapper

On another machine (Ubuntu submodule of Windows 10) it is:
lrwxrwxrwx 1 root root 15 Jun 1  2019 /etc/alternatives/x-terminal-emulator -> /usr/bin/lxterm

To further test, I also used termux on android to access the linux mint PC.  It also shows the same ekey effect. I can't tell you the etc/alternatives/x-terminal-emulator, because termux doesn't have that.

Next I did a fresh install of gforth on an Ubuntu VPS installed on vultr.com (using sudo apt-get install gforth).  Tried ekey with shift-backspace there -- same effect from both PCs as well as Android termux. 

I also accessed the VPS from a browser based terminal. However, that terminal did not seem to allow shift-backspace.  shift-backspace registered in gforth as just backspace.

Finally, I tried XTerm on Windows 10, connecting to the ubuntu LSM.  There, keystrokes also don't show after ekey, but shift-backspace is captured as 27 (ESC).


Oh, I also tried xterm on the Mint 18 (Ubuntu xenial equiv), but same effect.


Anonymous
Mon 02 Dec 2019 02:32:08 PM UTC, comment #2: 

I also cannot reproduce this.  I tried it with gforth 0.7.3 on an xterm on Ubuntu 18.04, and Shift-Backspace just produced 127 from EKEY, without any other noticable effects.

My guess is that the terminal emulator used may play a role here.  If you use the default one, then showing us the output of

ls -l /etc/alternatives/x-terminal-emulator

would help.

Anton Ertl <anton>
Group administrator
Mon 02 Dec 2019 10:04:13 AM UTC, comment #1: 

Can't reproduce at all.  Is this some key the terminal processes by itself?  Which terminal do you use? If it's WSL, which version of Windows?  The earlier versions of WSL had a very botched up terminal, before Microsoft switched to a mintty-based terminal emulation.

Bernd Paysan <paysan>
Group administrator
Mon 02 Dec 2019 06:02:49 AM UTC, original submission:  

to duplicate issue: ekey (press enter, then shift-backspace)

gforth no long echoes key strokes.  For example, enter .S  and you'll not see the .S while typing but you will see the it and the stack contents after pressing enter.  Echoing of key strokes is only restored by exiting and restarting gforth.

Also, after `ekey (enter) shift-backspace` subsequent ekey readings give unexpected results (e.g. the backspace key doesn't return 9 but 91)

tested on gforth 0.7.2 and 0.7.3 on ubuntu 18

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by anton (Posted a comment)
  • -email is unavailable- added by paysan (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-12-14 paysan Open/ClosedOpen Closed
    2019-12-03 paysan StatusConfirmed Fixed
    2019-12-03 anton StatusNeed Info Confirmed
    2019-12-02 paysan StatusNone Need Info
        Assigned toNone paysan

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code