0

I'm using Cygwin 64-bits, up-to-date (for today) on Windows 7; and in my terminal window I either work on the local machine or ssh into some other machine (Linux). Now, sometimes, when I scroll back in the history of bash commands, and pass some longer commands (especially in the case of commands running over the end of the line with the prompt and into the next line) - continuing to scroll prints other commands on the prompt line, but keeps characters from (one/some) older command/s if the new command is shorter, e.g.:

[me@mine /some/where]$ the quick brown fox jumped over the lazy dog. the
quick brown fox jumped over the lazy dog.

[me@mine /some/where]$ another command altogether over the lazy do

[me@mine /some/where]$ yet another command jumped over the lazy do

now, not all the characters are retained. Also, this doesn't always happen - I'm not sure exactly what triggers it.

However, if I just ssh into the remote host using, say, putty, not going through cygwin - I don't get this behavior, so it seems it's an issue with Cygwin or its bash.

  • What's happening, exactly?
  • What's the cause?
  • Can I fix it / avoid it happening / work around it (other than by running clear I mean)?
2
  • I can't verify it on my system, but does shopt -s checkwinsize help with the issue?
    – undercat
    Aug 23, 2018 at 6:16
  • @undercat: I'm not using Windows these days, so I can't say. The question was asked a year and a half ago.
    – einpoklum
    Aug 23, 2018 at 7:55

2 Answers 2

2

The usual problem with line-length in bash is the prompt (PS1) which typically is configured to use colors. If the escape sequences are not bracketed with \[ and \], then bash makes incorrect assumptions about the position of the cursor. Usually that is reported when editing a command, but scrolling through history is not really different.

If there's no local customization of PS1, the next place to look is at the terminal description (value of TERM). A fairly recent Cygwin uses mintty as a terminal window. That is a descendant of putty ... It sets TERM=xterm. But there are differences between mintty behavior and xterm (just as putty differs). Running tack for instance, it advises that bw (backward-wrap) is incorrect. bash doesn't appear to use that directly (though some script may). Its forward-wrap (am) differs from xterm as well (seen with vttest), and bash may have some dependency on xterm's behavior.

If you used xterm from Cygwin and compared that with mintty from Cygwin, you might get a better comparison.

2
  • But surely the default PS1 value can't be nisconfigured... Can it?
    – einpoklum
    Feb 19, 2017 at 12:12
  • using \[ and \] around my colours sorted out my cygwin garbled history scrolling problem - thanks!
    – Paul Evans
    Mar 6, 2019 at 11:35
0

Possible issues:

  • Some part of the TTY pipeline has the wrong idea about your terminal width

  • Something's gotten confused about Unicode

  • You're in the alternate screen, and characters aren't being overwritten correctly (the memory I'm using for this idea is vague and I might have the details wrong on this one)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .