[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 594
  • Last Modified:

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
0
tel2
Asked:
tel2
  • 6
  • 5
  • 2
  • +2
5 Solutions
 
Zephyr ICTCloud ArchitectCommented:
Maybe too obvious, but did you try with the latest (0.63) version of Putty? http://www.chiark.greenend.org.uk/~sgtatham/putty/
0
 
SandyCommented:
Or i would suggest to have a look on SecureCRT.. Another good option to be checked.

TY/SA
0
 
Gerwin Jansen, EE MVETopic Advisor Commented:
Current version of PuTTY (0.63), connected to a Linux host, with the perl command you gave, followed by a 'reset' will reset the terminal just fine.
0
What is SQL Server and how does it work?

The purpose of this paper is to provide you background on SQL Server. It’s your self-study guide for learning fundamentals. It includes both the history of SQL and its technical basics. Concepts and definitions will form the solid foundation of your future DBA expertise.

 
serialbandCommented:
That's because you happened upon the escape sequence (esc ])to set the title bar name and followed it up with random gibberish then closed it with character 007.  You also possibly overflowed the title buffer to cause strange behavior elsewhere.  Depending on how long that title name sequence is and how well the program handles the buffer, you may not get it back without restarting the window.  You're also sending other escape sequences to change the terminal behavior too.  These all go back to X, even if you're not running X, or tunneling X through putty.  Many of those settings you can change in the putty GUI can be done with escape sequences.

Here's how you set bash to print the username@hostname with the working directory in your title bar in bash.  Save the sequence to a variable in your shell and you can call it to restore your title bar when you accidentally set it.

Set this is your login profile.
PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME}: ${PWD}\007"'

Run this.
$PROMPT_COMMAND

You can look up how to do it for other shells.
http://tldp.org/HOWTO/Xterm-Title-4.html

This should work in putty, exceed, osx terminal, and, of course, any standard xterm.  I've never used secureCRT, but it will likely work there if they followed standard X terminal protocol.

@Sandy  -- you sure respond with a lot of non sequitur and somewhat off topic quick posts just to get points.
0
 
tel2Author Commented:
Thanks spractek,
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}: ${PWD}\007"'
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}: ${PWD}\007"
So should I workaround the error by putting something like this in my profile:
    PC='echo -ne "\033]0;${USER}@${HOSTNAME}: ${PWD}\007"'  # To store it
    $PC   # To run it
then type $PC if the title gets messed up.  How's that sound?
0
 
serialbandCommented:
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.
0
 
Gerwin Jansen, EE MVETopic Advisor Commented:
>> I had noticed I wasn't on the latest.  Might try upgrading sometime.
Just give portable PuTTY a try: http://portableapps.com/apps/internet/putty_portable - download and install it on a thumb drive.
0
 
tel2Author Commented:
> 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.
0
 
serialbandCommented:
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.
0
 
tel2Author Commented:
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.
0
 
serialbandCommented:
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
0
 
tel2Author Commented:
> 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.
0
 
serialbandCommented:
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.
0
 
tel2Author Commented:
> 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.
0
 
tel2Author Commented:
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/mydomain.com/tel2/new/1396567319.H676808P30912.myserver.mydns.com,S=9751

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
0

Featured Post

Microsoft Certification Exam 74-409

Veeam® is happy to provide the Microsoft community with a study guide prepared by MVP and MCT, Orin Thomas. This guide will take you through each of the exam objectives, helping you to prepare for and pass the examination.

  • 6
  • 5
  • 2
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now