bash clear not clearing

[ciaranj]

Just catching up on the end result of #96 (awesome stuff btw!) I imagine this is just a config issue combined with lack of experience on my part (the horror!) but 'clear' does not work as I expected in the cmd.com style bash terminal. It appears to reset the cursor back to the top of the visible area, but not actually cleanse the screen of any existing characters ('reset' does however cleanse the screen too)

(If I make the following alias, cls does behave as I expect)
alias cls='echo -ne "\033c"'

Potentially related but VI doesn't respect the cursor keys either?

Hopefully this is just a configuration issue, but if it is at least that response may help future issue visitors ;)

[dscho]

I can confirm, but I will be unable to do anything about it for 10 days. Maybe you have time to investigate a bit more?

[ciaranj]

I have both the time and the desire, but not a clue where to start :/ it affects the mintty variant too so presumably it isn't a console thing, I'll err hit Google a bunch :/

[poppyschmo]

Identical experience here with the screen not clearing (clean install, no bashrc). I've also been relying on a cls alias and would be willing to live with it if not for vim's being affected. Typically, I get residual detritus from the shell showing up 'behind' whatever I'm editing in a newly launched vim buffer (currently using an autocmd to clear). For what it's worth, the issue was also present for me in the version before this release candidate (2.4.1?) -- but only in ConEmu. To clarify, mintty was actually working fine in that version as was windows cmd when I'd invoke bash.exe from within it. It was only in ConEmu where I saw the artifacting. Prior to stumbling upon this thread, I was convinced it had something to do with the alternative screen buffer (and my own ignorance when configuring ConEmu). A few folks mentioned similar issues, last year, on Maximus5's old google code page (one example here). Thanks all for looking into this matter and ciaranj for raising it.

[dscho]

I have both the time and the desire, but not a clue where to start

@ciaranj This is what I would do if I were you, in this order:

1. look whether there is a difference of the TERM variable in msysGit and Git for Windows 2.x' Git Bash, and if there is, check whether an adjusted TERM fixes in Git Bash,
2. build the Bash by installing the Git SDK, then calling the msys2_shell.bat script, and issuing cd /usr/src/MSYS2-packages && git fetch origin && git checkout master && pacman -Sy base-devel binutils && ./makepkg -s, then making sure that the source in src/ is tracked via Git, then start the hunt by calling git grep '"clear"'
3. if necessary, litter the Bash source code with debug statements, build, and copy the result into a separate Git SDK to play with<

[lygstate]

lygstate@lygstate-PC MINGW64 ~/Desktop (master)
$ where clear
C:\Program Files\Git\usr\bin\clear.exe
lygstate@lygstate-PC MINGW64 ~/Desktop (master)
lygstate@lygstate-PC MINGW64 ~/Desktop (master)
$
lygstate@lygstate-PC MINGW64 ~/Desktop (master)
$ where clear
C:\Program Files\Git\usr\bin\clear.exe
lygstate@lygstate-PC MINGW64 ~/Desktop (master)
$ gstate@lygstate-PC MINGW64 ~/Desktop (master)
$ cls
lygstate@lygstate-PC MINGW64 ~/Desktop (master)
$
lygstate@lygstate-PC MINGW64 ~/Desktop (master)
lygstate@lygstate-PC MINGW64 ~/Desktop (master)
$ sh: cls: command not found

lygstate@lygstate-PC MINGW64 ~/Desktop (master)
$ clear

lygstate@lygstate-PC MINGW64 ~/Desktop (master)
$ whwere

lygstate@lygstate-PC MINGW64 ~/Desktop (master)
$ clear --version

lygstate@lygstate-PC MINGW64 ~/Desktop (master)
$

lygstate@lygstate-PC MINGW64 ~/Desktop (master)
$ clear

It's the problem of clear.exe

[dscho]

@lygstate this analysis is incomplete. You would have to rename clear.exe and run clear again to make sure that you are not running a Bash builtin (which I assume clear to be).

[lygstate]

@dscho sorry, when I rename clear.exe to other name, then clear can not be invoked. This may be a upstream msys2 issue.

[ciaranj]

Cheers @dscho I'll aim to investigate shortly

[ciaranj]

So, yes. In git 1.9.x TERM == cygwin. In git 2.x it is set to xterm-256color. If I set it to 'cygwin' in 2.x all is well in the world again. (I tried ansi as suggested in #175 but whilst this did fix clear and improve vim a bit vim still appeared to overwrite the console. cygwin however behaves exactly as expected)

[ciaranj]

I'm wondering if it is related to d4e943c ?

[ciaranj]

:( Just spent an hour fighting the installer build process to test that theory, but every installer I build runs (hangs until I kill a launched ssh-agent/ssh-add process) and completes but leaves me with a non-functional git-bash.exe (when clicked nothing appears to happen.) I don't think I can progress this if I can't build an installer :/

[poppyschmo]

Strange observation and probably a red herring, but I found that <esc>[H<esc>[2J, which is what 'clear' sends to stdout, suddenly works if you get rid of the 2 before the J. So, running echo -ne "\E[H\E[J" works and is consistent with the 'cd' entry in terminfo (which you can find via infocmp -C). Relatedly, in vim, running let &t_cl="^[[H^[[J" clears all the artifacts from the last term screen upon entering. (Not sure if you can assign persistent termcap vars in the git-bundled vim; it's built with the +terminfo feature, and I'm running the native Win-32 version.) Anyway, recompiling the xterm-256color binary file in /usr/share/terminfo/78 could fix things temporarily. Someone who knows what they're doing should probably weigh, though, to make sure it won't break anything else.

[dscho]

I'm wondering if it is related to d4e943c ?

I am almost certain of it. Will test.

[dscho]

I'm wondering if it is related to d4e943c ?

I am almost certain of it. Will test.

Confirmed!

[ciaranj]

result. Still not sure why I can't successfully build installers :(

[dscho]

@ciaranj if you cannot build the installers, please open a new ticket and paste the console log there.

[ciaranj]

I don't want to take this bug off-track, but I can build an installer, but the resulting installer when it completes leaves me with an installation that is broken (git-bash.exe does nothing when clicked.) I don't have sufficient detail to raise a bug on the back of this :/

[dscho]

I don't want to take this bug off-track, but I can build an installer, but the resulting installer when it completes leaves me with an installation that is broken (git-bash.exe does nothing when clicked.) I don't have sufficient detail to raise a bug on the back of this :/

Hmm. I fear we have to introduce a debug mode into the Git wrapper... Did you build the mingw-w64-git package yourself, did you upgrade all Pacman packages via pacman -Syu, or did you just let the Git SDK installer run its course (bundling the Git executables as built from /usr/src/git)?