I am working on recovering my workstation setup after a disk crash and have one problem getting 4.61 AbsoluteTelnet set up. I am using VT100 as the terminal type with a slightly customer .cskmp file, but which does not mention cursor keys. The properties are set for 8-bit with ISO8859-1 characters because we are using the upper register characters for line drawing. But, the cursor keys seem to be sending 9B then a letter instead of 1B, i.e., escape, and then a letter, i.e., the high bit of the escape has been turned on. I don't see any setup options related to this and don't recall having this problem previously. Where should I control this?
You must have 8-bit control sequences turned on.
On options->Properties->VTOptions, have AbsoluteTelnet send 7-bit control sequences instead of 8-bit.
Brian
Yes, I need 8-bit because the line drawing characters are in the upper half of the character set.
This was working previously, so it isn't as if I am trying something new.
That setting doesn't have anything to do with how AbsoluteTelnet interpprets what it receives. It only affects the control sequences *sent* by things such as function keys, arrows, etc...
Brian
OK, I do see that it says "sends". Changing it seems to work within my Progress application, but at the bash prompt, it seems to work something like 2-3 out of 4 times. E.g., if I am at the prompt and pressing up arrow to look at the command history, I will get a couple that will pop up as expected, then the cursor will suddenly jump up a couple lines on the screen instead of giving me the next command. If I keep pressing, I might get two more and then it jumps up 7 lines. None of it consistent.
What you're seeing is a result of your prior misconfiguration of the control option. You have some 8-bit escape sequences embeded in your command history that cause they display to get garbled when you revisit those commands using the arrow keys.
You need to first clear your history, then all should be well. You can do this by removing your history file (for bash, usually ~/.bash_history). Exit your shell, then login again.
Hope this helps.
Well, peculiar .... neither /root/.bash_history nor /home/root/.bash_history has in it the commands which I have been most recently using. It does appear that, if I put in a series of commands with no issues and then use up arrow on that set of commands, it behaves properly, but clearing both of those files did not seem to actually clear the history, Nor did I see any apparent 8 bit characters in either file. Logging in and logging out doesn't seem to have changed things and I can still go back into the history of prior sessions. I also see that if I use the history command, I am getting garbled listings. Some is OK, but some is not. When I say garbled, there is no obvious garbage characters, but e.g.,
"vi junk" (used to test what was being sent) is displaying as "bi junk". Also the line numbers go 18, 19, 20, 21, 22, 30, 38, 39, 40, 41, 42, 43, 44, 45, 49, 50. Peculiar.
Peculiar, but I still think it can all be explained by having embeded 8-bit cursor movements in your history file. You won't see garbage, just things out of place.
In bash, you can change the location of your history file by setting the HISTFILE environment variable. Make sure you remove the correct one. If you're using some other shell, the history may be kept elsewhere. Try removing the file again. Then, do an 'ls' to make sure it is gone. Now, log out and back in. Use 'ls' again to make sure the history file is gone.
if I put in a series of commands with no issues and then use up arrow on that set of commands, it behaves properly
This is what I expect. using the 'history' command goes too far back and hits the bad entries.
Well, it seems to have taken a couple of tries, but I *might* be there. Apparently, even if the file is erased, when one logs out the file is created with commands used during that session ... possibly buffered waiting for a full sector to write. So, I had to do very little and very simple things and then when I logged in I had a very small and uncontaminated .bash_history ... and so far, anyway, it seems to be behaving itself.
