Community
Participate
Working Groups
Steps to reproduce: 1. launch any osgi runtime that embeds the gogo shell that listens for incoming tcp connections (telnet) 2. create a new telnet terminal and open a connection to gogo 3. notice that typing commands and executing them works 4. but if you try to type a command and then press backspace, the backspace key doesn't work My system is ubuntu linux 14.04 and my target osgi runtime is running this version of apache gogo shell org.apache.felix.gogo.shell_0.10.0.jar
just extra info, the arrow keys and delete key works, but just not backspace.
The gogo shell seems to expect the DEL character (127). But we are still sending the backspace character (8). See also bug 205765.
Is the behavior in gogo shell incorrect?
(In reply to Greg Amerson from comment #3) > Is the behavior in gogo shell incorrect? No, but most telnet servers accept both DEL and BS. It might make sense to file an enhancement request with the gogo shell to handle BS in the same way as DEL.
(In reply to Anton Leherbauer from comment #4) > (In reply to Greg Amerson from comment #3) > > Is the behavior in gogo shell incorrect? > > No, but most telnet servers accept both DEL and BS. It might make sense to > file an enhancement request with the gogo shell to handle BS in the same way > as DEL. However, both DEL and BS work as expected when I telnet directly to gogo shell, but just not from within terminal view. So does that mean that when I telnet from local xterm, it is sending a different charcode for BS to gogo?
(In reply to Greg Amerson from comment #5) > However, both DEL and BS work as expected when I telnet directly to gogo > shell, but just not from within terminal view. So does that mean that when > I telnet from local xterm, it is sending a different charcode for BS to gogo? Yes. Usually on Linux the backspace key creates a DEL character. Strictly speaking this depends on the terminal emulator and configuration (eg. you can also make xterm send a backspace character). The terminal view sends a BS character instead. This works in many cases where the BS and DEL character are handled equally. Unfortunately we cannot just switch to sending a DEL character as we might cause a regression with telnet servers which only support the BS character.
That makes sense. So here is my use case. From my team's Eclipse plugin (Liferay IDE) we would like to automatically create a telnet terminal connection for the user when they invoke some action like "Connect to Liferay's OSGi console". Then on behalf of the user action, our plugin could use the TCF terminal API to create an instance of a "telnet connection" where we provide some type of "setting" that would say this...."because I know my use-case and connection requirements, can you send always send a DEL instead of a BS just for this once instance of a telnet connection?" Doable?
(In reply to Greg Amerson from comment #7) > That makes sense. > > So here is my use case. From my team's Eclipse plugin (Liferay IDE) we > would like to automatically create a telnet terminal connection for the user > when they invoke some action like "Connect to Liferay's OSGi console". > > Then on behalf of the user action, our plugin could use the TCF terminal API > to create an instance of a "telnet connection" where we provide some type of > "setting" that would say this...."because I know my use-case and connection > requirements, can you send always send a DEL instead of a BS just for this > once instance of a telnet connection?" > > Doable? Sure, my preference is to send DEL by default (as this is the most common case) and allow to override this per connection instance. But currently the character to send for the backspace key is entirely hard-coded.
I'd like to help contribute if you don't have time to implement this API. Can you point me to which class I should look at first?
(In reply to Greg Amerson from comment #9) > I'd like to help contribute if you don't have time to implement this API. > Can you point me to which class I should look at first? The option whether to send DEL or BS needs to be added to org.eclipse.tm.internal.terminal.provisional.api.ITerminalControl perhaps similar to setVT100LineWrapping. This at least allows for setting the option at creation and connect time, but clients of the TCF Terminals API usually don't have control over creation and connection, therefore it is also necessary to add a property to the org.eclipse.tcf.te.core.terminals.interfaces.constants.ITerminalsConnectorConstants on the TCF side and consider this option at creation time. Note that the TCF Terminals code is going to be moved to the Target Management project in the near future, so I'd wait with any coding until the move is complete.
Hi Greg, The restructuring of the Terminal has been completed, and we'd really appreciate your contribution ! See the CONTRIBUTING guide here: http://git.eclipse.org/c/tm/org.eclipse.tm.terminal.git/tree/CONTRIBUTING Please let us know if you have any questions - we'll be glad to try and help ! Thanks, Martin
The Terminal component of the Eclipse Ecosystem has a new home. The Terminal is now part of the Eclipse CDT project[1]. This change means a new Git repo[2], P2 site[3] and Bugzilla component. The terminal will continue to be delivered as part of the quarterly Simultaneous Release of Eclipse as well. The marketplace entry[4] had not been updated in a few years. It will once again install the latest release of the terminal on the latest release of the whole IDE (currently 2020-03). If this bug is no longer relevant, please feel free to comment or close the bug. If you can confirm if this issues still occurs in the latest release please do let me know in a comment. [1] https://wiki.eclipse.org/CDT/User/NewIn911 [2] https://git.eclipse.org/c/cdt/org.eclipse.cdt.git (in the terminal directory) [3] current release is 9.11 - P2 site https://download.eclipse.org/tools/cdt/releases/9.11/ [4] https://marketplace.eclipse.org/content/tm-terminal (This comment was added to all open terminal bugs along with changing the Product/component pair to CDT/terminal.)
