VanDyke Software Forums

Go Back   VanDyke Software Forums > Secure Shell
User Name
Password
Register FAQ Members List Calendar Search Today's Posts Mark Forums Read

Reply
 
Thread Tools Display Modes
  #16  
Old 10-15-2010, 03:47 PM
mattsaccount mattsaccount is offline
Registered User
 
Join Date: Jun 2009
Posts: 20
OK long post as this is apparently a deep topic. The number of things that have to be correct for everything to work is ... significant

1) XTERM definitely has to be the terminal emulation in SecureCRT. Similarly, Linux needs to report the environment variable appropriately: TERM=xterm. I had it set to "Linux" for various reasons, but found that xterm is indeed the only one that works reliably.

2) Emacs really does need to be 23.2.1. My slightly older 23.1.1 version did not work even with xterm set appropriately.

3) I'm launching emacs with "emacs -nw -q" to ensure that no user-specific custom settings are loaded. This is a clean installation of emacs 23.2.1 anyway, so this is as standard as I can get. I think my .emacs file is not an issue, but this approach eliminates it as a variable.

4) The SecureCRT key bindings are the next part. Changing the terminal emulation + emacs installation as you recommended gets me this:
- Shift+Right and Shift+Down both work correctly, set the text, and are great. This suggests we're very close to having this working.
- Shift+Left and Shift+Up do not work as expected.

So, let's examine why Shift+Left/Up wouldn't work:

- The SecureCRT key map file associated with my current SecureCRT session contains this:

SE VK_LEFT "\033[1;2D"
SE VK_UP "\033[1;2A"
SE VK_RIGHT "\033[1;2C"
SE VK_DOWN "\033[1;2B"

I have posted my complete keymap file here for reference:
http://www.renzelmann.com/temp/securecrt_keys.txt

Using the keymap editor confirms that they are all set correctly as you listed in your post.

- Let's first consider SHIFT-UP. Background: we can first test SHIFT-RIGHT, which works, a different way. By loading emacs, we can type:

ALT [
1
;
2
SHIFT C (capital C)

where each line shows the keys to type at once, with no spaces. This approach also works, as expected. Typing those keys does select one character to the right. Now, if I try:

ALT [
1
;
2
SHIFT A (capital A)

The same thing, except capital A, I get an emacs error in the emacs status bar:

<select> is undefined.

I get the same message if I simply press "SHIFT-UP" as expected, since I've mapped SHIFT-UP to that string. So, it consistently doesn't work. This result suggests that I've mapped the key correctly, but for some reason this specific string doesn't work. And just to be crystal clear, if I either type "ALT-[ 1 ; 2 SHIFT-B" in emacs or press "SHIFT-DOWN", it works fine. Just SHIFT-UP fails in both cases.

So, SHIFT-UP does not work for some reason. I don't understand why. I can't make it work using either the mapped key or by typing the keys directly into emacs.

- Now let's examine SHIFT-LEFT. This result adds even more mystery, as I can make it work if I type the keys manually, but not if I use the mapped key. Thus, if I type:

ALT [
1
;
2
SHIFT D (capital D)

in emacs it works fine! But, when I use the mapped key, it does not work. This suggests a key mapping problem. So, I attempted to DISABLE the key combination entirely, by selecting "Disabled" instead of "Send String" in the "Keymap Editor" dialog.

However, even DISABLING SHIFT-LEFT results in the following:

prompt> cat -v
^[[2D

If I disable some other key, then cat -v displays nothing when I press it, as expected. This result is bizarre. For some reason, SecureCRT is sending the keystrokes shown with cat -v, even though I've DISABLED SHIFT-LEFT. The keymap file confirms:

SE VK_LEFT DISABLED
SE VK_UP "\033[1;2A"
SE VK_RIGHT "\033[1;2C"
SE VK_DOWN "\033[1;2B"

Now, to test the theory that it's some other issue on my machine, I used a backup user account with no other applications running. I installed a fresh version of SecureCRT specific to that account, I mapped the key, and it worked fine! Woohoo.

Thus, the SHIFT-LEFT issue relates to some other application incompatibility with my current Windows user account and the applications it has running, so we can consider this one resolved as it's my fault and I can take it from here.

Nevertheless, testing the SHIFT-UP key with the fresh SecureCRT installation and no other apps running still does not work Typing the keys manually also fails. All fail with the same "<select> is undefined" error message.

Therefore, the only remaining question is: Why would SHIFT-UP not work at all, even if I type the keys in emacs manually? What's different about that key?
Reply With Quote
  #17  
Old 10-16-2010, 12:14 PM
mattsaccount mattsaccount is offline
Registered User
 
Join Date: Jun 2009
Posts: 20
Another riveting development:

<select> in Emacs apparently refers to the VT_SELECT virtual terminal command. I tried adding the line. Normally, this key is bound to the END key on the keyboard (next to HOME).

I tried adding this line to my .emacs file:
(define-key global-map [select] 'end-of-line)

Curiously, with SHIFT-UP mapped as before, I can go to the end of the line either by pressing SHIFT-UP -or- by pressing the END key. Thus, it seems that the strings \033[1;2A and the VT function VT_SELECT both accomplish the same thing from the perspective of SecureCRT keymap. Similarly, if I actually type out "ALT-[ 1 ; 2 A" in emacs, with the .emacs file set appropriately, it goes to the end of the line.

Now I'm quite puzzle about how to proceed. If both END and SHIFT-UP map to the same thing, is it possible to support both a working END key and the SHIFT-UP selection functionality?
Reply With Quote
  #18  
Old 10-16-2010, 01:05 PM
mattsaccount mattsaccount is offline
Registered User
 
Join Date: Jun 2009
Posts: 20
Another datapoint: I've got a virtual machine running CentOS 5.5 (latest updates). I installed emacs 23.2.1, logged in via SSH, and observed the same behavior. SHIFT-UP does not work and emacs reports "<select> is undefined"

Curiously, SHIFT-LEFT worked as expected. When I logged in to the other machine SHIFT-LEFT still returns "M-[ 2 d is undefined" in emacs. Further investigation revealed that I had accidentally mapped a key to SHIFT-LEFT in the Session options / Terminal / Emulation / Mapped Keys section that caused the problem. I think it was leftover from last time I was experimenting with this Thus, SHIFT-LEFT/RIGHT/DOWN all work correctly now.

Nevertheless, that's not the source of the SHIFT-UP problem as there are no additional, conflicting mapped keys in that section of the session options configuration.

Thanks and regards,
Matt

Last edited by mattsaccount; 10-16-2010 at 01:11 PM.
Reply With Quote
  #19  
Old 10-18-2010, 06:11 AM
mattsaccount mattsaccount is offline
Registered User
 
Join Date: Jun 2009
Posts: 20
Just a quick update on some configuration details:
- I'm no longer using the global key map file. Options -> Session -> Terminal -> Emulation -> Select an Alternative Keyboard Emulation checkbox is unchecked. Just plain XTERM
- All keys are mapped in the Session -> Terminal -> Emulation -> Mapped Keys section now.

Same problem as before. Shift-Left/Right/Down work, Shift-Up fails.

And just to reiterate that everything I can think of is correct:

Here's what's displayed in SecureCRT if I press SHIFT-UP/SHIFT-DOWN/SHIFT-RIGHT/SHIFT-LEFT:

~> cat -v
^[[1;2A^[[1;2B^[[1;2C^[[1;2D

As expected, SHIFT-UP looks good.

Similarly, the same keystrokes in my native xterm terminal (no SecureCRT, just gnome xterm terminal):

~> cat -v
^[[2A^[[2B^[[2C^[[2D

But emacs still complains in SecureCRT. I start it with emacs -nw -q and attempt to edit a file. Only shift-up doesn't work:

-----------
<select> is undefined

in the emacs status bar.

In addition, using SecureCRT, I've remapped the keyboard END key to send the string:

\eOF

and emacs treats that appropriately. Pressing the END key with this mapping goes to the end of the line.

So, I'm still stuck on SHIFT-UP sending the "SELECT" virtual key.

Finally, I tried commenting out my ~/.inputrc file just to be sure that wasn't an issue. It wasn't. Even with an empty ./.inputc file it doesn't work--same error. Note that I tried with an empty ~/.inputrc, so that overrides the system's inputrc file.
Reply With Quote
  #20  
Old 10-18-2010, 06:41 AM
miked's Avatar
miked miked is offline
Registered User
 
Join Date: Feb 2004
Posts: 2,040
This really is still an emacs question, not SecureCRT. If SecureCRT is sending the correct sequences, which you have verified, and emacs is not interpreting them, I'd look at emacs, .emacs, etc..

Using a default SecureCRT configuration and a simple shell .login file on your host will probably help (don't set $TERM on the host, don't use non-standard keymap files, etc.). On both hosts I've tested, all four Shift-arrow keys work as expected, when using default settings on the client and server.
__________________
Mike
VanDyke Software
Technical Support
[http://www.vandyke.com/support]
Reply With Quote
  #21  
Old 10-18-2010, 06:51 AM
mattsaccount mattsaccount is offline
Registered User
 
Join Date: Jun 2009
Posts: 20
Fair enough, you're absolutely right. I'm just glad you verified that you've seen it working under several configurations, so we can consider the issue resolved. I will try some of the things you suggested.

Thanks again!
Matt
Reply With Quote
  #22  
Old 10-18-2010, 07:12 AM
miked's Avatar
miked miked is offline
Registered User
 
Join Date: Feb 2004
Posts: 2,040
Hi Matt,

In case it helps at all, the two operating systems I tested on were CentOS and Ubuntu, though it shouldn't matter. I double checked the SecureCRT keymap file you sent and the settings were correct, so you're mapping keys correctly.

As far as continued testing, to test a default session with no key mapping, use Quick Connect. It will connect using settings from the default session's .ini file. Enabling the Save session checkbox in the lower right corner will allow you to test with this session again later. After connecting you can modify your keymap settings in the session.

If you have modified your default settings and want to quickly test a default SecureCRT configuration folder, you can either rename your configuration folder (specified in Global Options / General), or start SecureCRT using the /F command line option:
SecureCRT /F C:\Temp\DefaultConfig
If using /F, make sure an empty folder you're going to use (such as C:\Temp\DefaultConfig) exists before running the command.
__________________
Mike
VanDyke Software
Technical Support
[http://www.vandyke.com/support]
Reply With Quote
  #23  
Old 10-28-2010, 07:28 PM
mattsaccount mattsaccount is offline
Registered User
 
Join Date: Jun 2009
Posts: 20
I know this is outside the scope of the forum to some extent, but I thought for the benefit of any one following this I might as well post my eventual solution:

export TERM=xterm-vt220

before running Emacs, or set it in ~/.bash_profile. That solves the problem, and shift-arrow for all arrows works appropriately. I still don't know why you (MikeD) were able to get it working without this change. I've tried it on two different machines running CentOS 5.x with Emacs 23.2, and in each case this change (forcing TERM=xterm-vt220") was necessary. Obviously that's counter to your experience.

To be clear, I'm using xterm emulation in SecureCRT along with mappings for shift-arrow keys as specified, but no additional mapping for the home/end keys, etc:

cat -v
^[[1~
^[[4~

Home / end respectively are shown above.

For reference, this is the thread that led me to try it:
http://debbugs.gnu.org/cgi-bin/bugreport.cgi?bug=1737

For some reason, Emacs was interpreting the END key as a "SELECT" key, which doesn't exist. By changing this TERM environment variable, Emacs interprets the key appropriately.

Finally, for what it's worth, mapping CTRL-SHIFT-ARROW as follows with SecureCRT also works in Emacs:

CTRL-SHIFT-UP:
\033[1;6A

CTRL-SHIFT-DOWN:
\033[1;6B

CTRL-SHIFT-RIGHT:
\033[1;6C

CTRL-SHIFT-LEFT:
\033[1;6D

The purpose of these keys is to select whole words / paragraphs all at once rather than just one character/line at a time.

So, you were certainly correct that it was an Emacs issue, but I'll probably remain forever puzzled as to why it worked for you without this change. At least we can consider the matter successfully resolved

Last edited by mattsaccount; 10-28-2010 at 07:43 PM.
Reply With Quote
  #24  
Old 10-29-2010, 01:27 PM
miked's Avatar
miked miked is offline
Registered User
 
Join Date: Feb 2004
Posts: 2,040
Thanks for posting the solution, Matt!
__________________
Mike
VanDyke Software
Technical Support
[http://www.vandyke.com/support]
Reply With Quote
  #25  
Old 11-25-2010, 09:51 PM
hogu hogu is offline
Registered User
 
Join Date: Nov 2010
Posts: 1
Don't know if anyone still cares, but I spent a decent amount of time scratching this itch, so I wanted to put it somewhere so other people could find it

I run emacs like this

export TERM=xterm-256color; emacs -nw

as the OP said, shift up does not work, but all the other shift arrow keys work

I was trying to figure out what was different between xterm-vt220 and the rest.. I ended up rebuilding xterm-256color and that fixed the problem.

sudo cp /lib/terminfo/x/xterm-256color /lib/terminfo/x/xterm-256color.backup
infocmp xterm-256color > xterm.tmp
tic xterm.tmp
sudo cp ~/.terminfo/x/xterm-256color /lib/terminfo/x/xterm-256color

and that does the trick

I just tried it for regular xterm, and it fixes the problem as well

no idea why rebuilding helps, but the rebuilt files are a different size......
Reply With Quote
  #26  
Old 11-26-2010, 10:39 AM
bgagnon bgagnon is offline
VanDyke Technical Support
 
Join Date: Oct 2008
Posts: 1,797
Hi hogu,

Thanks for posting the information here.

I am certain many will find it useful.
__________________
Thanks,
--Brenda

VanDyke Software
Technical Support
support@vandyke.com
(505) 332-5730
Reply With Quote
  #27  
Old 09-07-2012, 05:29 AM
tniemi tniemi is offline
Registered User
 
Join Date: Sep 2012
Posts: 1
I know this is a two years old thread, but still:
Quote:
Originally Posted by hogu View Post
sudo cp /lib/terminfo/x/xterm-256color /lib/terminfo/x/xterm-256color.backup
infocmp xterm-256color > xterm.tmp
tic xterm.tmp
sudo cp ~/.terminfo/x/xterm-256color /lib/terminfo/x/xterm-256color
Thank you for this.

I run emacs in terminal mode (tty) and had all the other keys working except shift-up. Re-compiling the terminal file fixed the issue.
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 02:51 AM.


copyright 1995-2014 VanDyke Software, Inc.