Reset PuTTY Emulator
Hi Experts,
I've been using the PuTTY terminal emulator for years, mainly with bash on Linux, and occasionally I'll do something which upsets the screen a bit, e.g. when I display some "unprintable" characters. You may be able to reproduce this problem with a command like this:
perl -e 'print chr(rand(256)) for 0..9999'
(Notice also how that messes up the wording on PuTTY's title bar. Why does that happen?)
After that, when I press up-arrow in the bash command line, to edit/reuse a previous command (especially those which are longer than one physical line long), and try to edit them (e.g. press left-arrow to take me back to the 50th character), things get messed up. The only resolution I've had so far is to start another session, because the following don't seem to help:
- The Linux "stty sane" command.
- The Linux "reset" command.
- The Linux "clear" command.
- The PuTTY "Reset Terminal" menu option.
Any proper solutions for when this problem happens?
I'm using PuTTY 0.52 on Windows.
Thanks.
tel2
I've been using the PuTTY terminal emulator for years, mainly with bash on Linux, and occasionally I'll do something which upsets the screen a bit, e.g. when I display some "unprintable" characters. You may be able to reproduce this problem with a command like this:
perl -e 'print chr(rand(256)) for 0..9999'
(Notice also how that messes up the wording on PuTTY's title bar. Why does that happen?)
After that, when I press up-arrow in the bash command line, to edit/reuse a previous command (especially those which are longer than one physical line long), and try to edit them (e.g. press left-arrow to take me back to the 50th character), things get messed up. The only resolution I've had so far is to start another session, because the following don't seem to help:
- The Linux "stty sane" command.
- The Linux "reset" command.
- The Linux "clear" command.
- The PuTTY "Reset Terminal" menu option.
Any proper solutions for when this problem happens?
I'm using PuTTY 0.52 on Windows.
Thanks.
tel2
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
It looks like you're in a chroot jail. You may not be able to run or configure certain things. It should be fine to put it in another variable if your admin allows it.
BTW. putty 0.52 is several years old and insecure.
BTW. putty 0.52 is several years old and insecure.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
> BTW. putty 0.52 is several years old and insecure.
Thanks serialband. I'm now having trouble reproducing the problem, even in this old version. Maybe my Perl one-liner:
perl -e 'print chr(rand(256)) for 0..9999'
only rarely happens to generate character sequences that create the problem, though it worked for me when I was posting this question.
I plan to upgrade to 0.63 after I can reproduce the problem, so I can easily tell whether the upgrade has fixed it, then close this question if appropriate. Either way, I intend to use 0.63 long term.
> Just give portable PuTTY a try...
Thanks Gerwin. Will bear that option in mind. Could be handy.
Thanks serialband. I'm now having trouble reproducing the problem, even in this old version. Maybe my Perl one-liner:
perl -e 'print chr(rand(256)) for 0..9999'
only rarely happens to generate character sequences that create the problem, though it worked for me when I was posting this question.
I plan to upgrade to 0.63 after I can reproduce the problem, so I can easily tell whether the upgrade has fixed it, then close this question if appropriate. Either way, I intend to use 0.63 long term.
> Just give portable PuTTY a try...
Thanks Gerwin. Will bear that option in mind. Could be handy.
Portable putty just puts the config in local files instead of the registry, so that you can put it on a USB and take it with you.
The perl one-liner is generating random characters. Unless you're always generating that particular sequence that includes esc+] followed eventually by the \007 (aka ctrl+g aka bell) before you encounter a ctrl+c or break character, you will not get that behavior every time.
The upgrade shouldn't "fix" that sequence. There is no fix. It's supposed to allow your shell to change your title. You should upgrade now. Don't wait. That behavior is not going to change.
The perl one-liner is generating random characters. Unless you're always generating that particular sequence that includes esc+] followed eventually by the \007 (aka ctrl+g aka bell) before you encounter a ctrl+c or break character, you will not get that behavior every time.
The upgrade shouldn't "fix" that sequence. There is no fix. It's supposed to allow your shell to change your title. You should upgrade now. Don't wait. That behavior is not going to change.
ASKER
Hi serialband,
> Portable putty just puts the config in local files instead of the registry, so that you can put it on a USB and take it with you.
I know. That could be handy for me, as mentioned in my last post. I doubt it will help with the issues I've raised here, though.
> The perl one-liner is generating random characters.
I know. I wrote it.
> Unless you're always generating that particular sequence that includes esc+] followed eventually by the \007 (aka ctrl+g aka bell) before you encounter a ctrl+c or break character, you will not get that behavior every time.
I know. That's why I wrote this in my last post:
"...only rarely happens to generate character sequences that create the problem..."
> The upgrade shouldn't "fix" that sequence. There is no fix. It's supposed to allow your shell to change your title.
It sounds as if you are under the impression that the title change is my main issue. Is that correct, serialband? It's not. That was a side issue, and that's why I put it in parentheses in my original post, like this:
"(Notice also how that messes up the wording on PuTTY's title bar. Why does that happen?)"
My main issue is as follows, also from my original post:
"After that, when I press up-arrow in the bash command line, to edit/reuse a previous command (especially those which are longer than one physical line long), and try to edit them (e.g. press left-arrow to take me back to the 50th [for example] character), things get messed up."
> You should upgrade now. Don't wait. That behavior is not going to change.
I have always had serious doubts that upgrading would fix either of the 2 issues I raised, but I'm no expert on PuTTY, so I don't want to assume that. (I don't think it can help with my side issue re the title.) Some experts have implied that it might help (presumably with my main issue). If I can prove it won't help, I plan to post my results here, and experts can give further suggestions if they have any. This proof will also help me to award points appropriately.
For my main issue, I expect there is some control sequence that would put things back to normal behaviour, so I can again up-arrow through my command history, and edit even long commands without a problem.
> Portable putty just puts the config in local files instead of the registry, so that you can put it on a USB and take it with you.
I know. That could be handy for me, as mentioned in my last post. I doubt it will help with the issues I've raised here, though.
> The perl one-liner is generating random characters.
I know. I wrote it.
> Unless you're always generating that particular sequence that includes esc+] followed eventually by the \007 (aka ctrl+g aka bell) before you encounter a ctrl+c or break character, you will not get that behavior every time.
I know. That's why I wrote this in my last post:
"...only rarely happens to generate character sequences that create the problem..."
> The upgrade shouldn't "fix" that sequence. There is no fix. It's supposed to allow your shell to change your title.
It sounds as if you are under the impression that the title change is my main issue. Is that correct, serialband? It's not. That was a side issue, and that's why I put it in parentheses in my original post, like this:
"(Notice also how that messes up the wording on PuTTY's title bar. Why does that happen?)"
My main issue is as follows, also from my original post:
"After that, when I press up-arrow in the bash command line, to edit/reuse a previous command (especially those which are longer than one physical line long), and try to edit them (e.g. press left-arrow to take me back to the 50th [for example] character), things get messed up."
> You should upgrade now. Don't wait. That behavior is not going to change.
I have always had serious doubts that upgrading would fix either of the 2 issues I raised, but I'm no expert on PuTTY, so I don't want to assume that. (I don't think it can help with my side issue re the title.) Some experts have implied that it might help (presumably with my main issue). If I can prove it won't help, I plan to post my results here, and experts can give further suggestions if they have any. This proof will also help me to award points appropriately.
For my main issue, I expect there is some control sequence that would put things back to normal behaviour, so I can again up-arrow through my command history, and edit even long commands without a problem.
Upgrade now, because you're using an INSECURE putty.
The upgrade will not help you "fix" anything because it's not "broken". You are encountering terminal escape sequences or console codes. They're expected behavior for the terminal. If correctly implemented, your terminal should accept all terminal escape sequences. That's how the cursor controls are set too. You can replace keystrokes with terminal escape keys and control keys. It's not technically broken.
These were much more useful long ago in a more text only world. You could look at the source code of putty to see how he sets some of those settings when you click on the configuration check boxes. If you actually want to try it out, then you should change your perl command to include the escape sequences in order, followed by some text that separates and identifies each sequence. You can then more easily figure out which character was generated to alter your cursor. By running it randomly, you can't narrow down the sequences that "break" your cursor key.
In X, there's also xmodmap to remap your keys and change your keyboard layout. Some people want to change their keyboard layouts.
I don't know the escape sequence off-hand, but here's a bunch of links that should direct you to the right place.
http://linux.about.com/library/cmd/blcmdl4_console_codes.htm
http://www.tldp.org/HOWTO/Bash-Prompt-HOWTO/bash-prompt-escape-sequences.html
http://tldp.org/LDP/abs/html/special-chars.html
The upgrade will not help you "fix" anything because it's not "broken". You are encountering terminal escape sequences or console codes. They're expected behavior for the terminal. If correctly implemented, your terminal should accept all terminal escape sequences. That's how the cursor controls are set too. You can replace keystrokes with terminal escape keys and control keys. It's not technically broken.
These were much more useful long ago in a more text only world. You could look at the source code of putty to see how he sets some of those settings when you click on the configuration check boxes. If you actually want to try it out, then you should change your perl command to include the escape sequences in order, followed by some text that separates and identifies each sequence. You can then more easily figure out which character was generated to alter your cursor. By running it randomly, you can't narrow down the sequences that "break" your cursor key.
In X, there's also xmodmap to remap your keys and change your keyboard layout. Some people want to change their keyboard layouts.
I don't know the escape sequence off-hand, but here's a bunch of links that should direct you to the right place.
http://linux.about.com/library/cmd/blcmdl4_console_codes.htm
http://www.tldp.org/HOWTO/Bash-Prompt-HOWTO/bash-prompt-escape-sequences.html
http://tldp.org/LDP/abs/html/special-chars.html
ASKER
> Upgrade now, because you're using an INSECURE putty.
I know it's insecure. You highlighted that before. I've been reading your posts. But I've been using this version for years, and a bit longer is unlikely to make much difference.
> The upgrade will not help you "fix" anything because it's not "broken"...
I expect you are right, as indicated in my last post, but see my last post for more details on why I want to test first.
> By running it randomly, you can't narrow down the sequences that "break" your cursor key.
I think I could. I was planning to redirect the output of my one-liner to a file, then "cat" that, and if it reproduced my main problem, then I could split the file into 2 halves and try "cat"ting each half in a new session. If one caused the problem, then I'd split that. If neither half worked, then I may have split it part way through the culprit control sequence, so I'd have to split it somewhere else. I'd continue to do that (binary search style), until I'm down to just a few characters. Painful, I expect it would work.
Thanks for the rest of your comments and links.
I know it's insecure. You highlighted that before. I've been reading your posts. But I've been using this version for years, and a bit longer is unlikely to make much difference.
> The upgrade will not help you "fix" anything because it's not "broken"...
I expect you are right, as indicated in my last post, but see my last post for more details on why I want to test first.
> By running it randomly, you can't narrow down the sequences that "break" your cursor key.
I think I could. I was planning to redirect the output of my one-liner to a file, then "cat" that, and if it reproduced my main problem, then I could split the file into 2 halves and try "cat"ting each half in a new session. If one caused the problem, then I'd split that. If neither half worked, then I may have split it part way through the culprit control sequence, so I'd have to split it somewhere else. I'd continue to do that (binary search style), until I'm down to just a few characters. Painful, I expect it would work.
Thanks for the rest of your comments and links.
You really should be able to reproduce the result even in the newer version. Putty doesn't need to be "installed". I always just extract it from the zip file and put it in a path of my own choosing. You can put both copies in place at the same time. If you already have a file with the "random" codes, you can pipe it through both interfaces and see the same result.
Get the codes from the links I've posted. Write a script using those codes in order. You can insert random characters after it, if that suits your fancy. You can also just search for the sequences and break at the where they start. Since escape sequences come in pairs, there shouldn't be too many of them to isolate. That's probably easier than sorting through all that random gibberish through an exhaustive binary search. Read the section about character sets in that first link I've posted. It describes why the reset doesn't always work.
It's definitely an escape sequence or control code that changes your settings. I played around with those long ago, but haven't had a need to change my terminal in a very long while. It has nothing to do with putty versions or other ssh client versions. If you ran this in OSX terminal.app, you should get the same behavior. If you ran this in a linux or unix terminal, you should get the same behavior. It's a defined terminal control or escape sequence. If you output a binary file to the terminal, it would do a similar thing, depending on which control & escape sequences are in the file.
cat BINARY_FILE would do something similar.
P.S. Good thing you don't work where I've worked before. You'd be automatically scanned and blocked for running such an old version putty with known security holes. The security guy implemented some hard core scans due to the corporate policies. Some users would even attempt to hack your connection for fun.
Get the codes from the links I've posted. Write a script using those codes in order. You can insert random characters after it, if that suits your fancy. You can also just search for the sequences and break at the where they start. Since escape sequences come in pairs, there shouldn't be too many of them to isolate. That's probably easier than sorting through all that random gibberish through an exhaustive binary search. Read the section about character sets in that first link I've posted. It describes why the reset doesn't always work.
It's definitely an escape sequence or control code that changes your settings. I played around with those long ago, but haven't had a need to change my terminal in a very long while. It has nothing to do with putty versions or other ssh client versions. If you ran this in OSX terminal.app, you should get the same behavior. If you ran this in a linux or unix terminal, you should get the same behavior. It's a defined terminal control or escape sequence. If you output a binary file to the terminal, it would do a similar thing, depending on which control & escape sequences are in the file.
cat BINARY_FILE would do something similar.
P.S. Good thing you don't work where I've worked before. You'd be automatically scanned and blocked for running such an old version putty with known security holes. The security guy implemented some hard core scans due to the corporate policies. Some users would even attempt to hack your connection for fun.
ASKER
> You really should be able to reproduce the result even in the newer version.
I think you've implied this before, and as I implied in previous posts, I believe you are right, but would like to prove it for the reason I've previously given, before I award points, etc. But let's stop repeating ourselves.
> Putty doesn't need to be "installed". I always just extract it from the zip file and put it in a path of my own choosing.
Yes, that's what I do, too.
Other points taken.
I think you've implied this before, and as I implied in previous posts, I believe you are right, but would like to prove it for the reason I've previously given, before I award points, etc. But let's stop repeating ourselves.
> Putty doesn't need to be "installed". I always just extract it from the zip file and put it in a path of my own choosing.
Yes, that's what I do, too.
Other points taken.
ASKER
Hi Experts,
Sorry for the delay in getting back to you on this.
After weeks of continuing to use my old version of PuTTY, to try to see if I could find out what kind of commands reproduce this problem, the problem became very scarce, and I decided to switch to the new version a couple of weeks ago.
In the new version, I've seen the problem a couple of times, and the last time was when I entered a long command almost exactly like this:
cat /home/myaccount/mail/mydom
I had pasted the filename after the 'cat' command, after doing an 'ls -l'.
After seeing the problem, I opened a new PuTTY session (same new version of PuTTY), and pasted the command into it, but the problem did not occur there. So, I give up as to what caused the problem in this instance, and possibly in others. We are allowed to give up at EE, aren't we?
Thanks to all of you for your time and help. Some of you may not have helped me resolve the problem I specified, but most of you helped me in some way, so I have tried to award points in a way I think is fair.
tel2
Sorry for the delay in getting back to you on this.
After weeks of continuing to use my old version of PuTTY, to try to see if I could find out what kind of commands reproduce this problem, the problem became very scarce, and I decided to switch to the new version a couple of weeks ago.
In the new version, I've seen the problem a couple of times, and the last time was when I entered a long command almost exactly like this:
cat /home/myaccount/mail/mydom
I had pasted the filename after the 'cat' command, after doing an 'ls -l'.
After seeing the problem, I opened a new PuTTY session (same new version of PuTTY), and pasted the command into it, but the problem did not occur there. So, I give up as to what caused the problem in this instance, and possibly in others. We are allowed to give up at EE, aren't we?
Thanks to all of you for your time and help. Some of you may not have helped me resolve the problem I specified, but most of you helped me in some way, so I have tried to award points in a way I think is fair.
tel2
ASKER
I had noticed I wasn't on the latest. Might try upgrading sometime.
Hi Sandy,
Thanks, but I don't really want to change emulator just to fix this occasional minor irritation.
Hi Gerwin,
The problem with my perl one-liner is, it's random, so it may not have reproduced the problem for you. I just ran it again and this time it did not reproduce the problem for me. Hopefully I can work out what characters cause it, sometime.
Hi serialband,
Well said.
Regarding the title name, I haven't tried putting that in my profile yet, but should I be able to test this by running the following from the command line?:
PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME
I'm in a shared hosting environment on CentOS (I think), and if I run the above from the command line, I get this error:
-jailshell: PROMPT_COMMAND: readonly variable
Any ideas why this would happen on the shared hosting environment?
But I can run this:
echo -ne "\033]0;${USER}@${HOSTNAME
So should I workaround the error by putting something like this in my profile:
PC='echo -ne "\033]0;${USER}@${HOSTNAME
$PC # To run it
then type $PC if the title gets messed up. How's that sound?