Open alexsigmund opened 6 years ago
I had made a typo on the ConEmu build version.
ConEmu build: 180626 preview x64
Video: https://ibb.co/k0PKCJ
I've already seen bugs in ssh.exe
from system32. This implementation of ssh does not pass ANSI sequences to terminal (ConEmu) but calls WinApi functions.
To be sure, you may run ConEmu64.exe -basic -log -run {cmd}
, start ssh
and mutt
and upload log files
Hi, I am having a similar issue. First noticed several weeks ago on a colleagues notebook, but decided the issue looks too improbable and is likely device specific.
Now (i suspect once my windows device caught up with updates), I am suffering from the same issue. First noticed it on "mc" - midnight commander, but based on alexsigmunds comments also tried mutt - same issue, exactly as the video above.
You can find my logs on sedspace
I should note, that I have noticed this issue on CMDer, that is currently running of the "stable" version of ConEmu. As this is a somewhat dated version, not sure if it's still relevant.
I have therefore tested also the "preview" version of ConEmu, same results (sendspace)
@CargoCoder Windows version? ssh version?
Dear Maximus5, thank you for your prompt response - and please forgive my delayed one. Based on your response, I am only testing the "preview" version (will be happy to test the alfa version if required).
Hopefully this (sendspace) is the log you were looking for. I am connecting from Windows 10 ( Ver. 1803, build 17134.112 - not sure it means anything). The OpenSSH I was connecting to while logging was OpenSSH_6.4p1-hpn14v2, OpenSSL 1.0.2h. The server is running Gentoo.
Since that IS somewhat dated version of OpenSSH, I have also tested against OpenSSH_7.5p1-hpn14v12, OpenSSL 1.0.2n , ( sendspace ). Again running Gentoo.
I also encounter similar issue when using vifm (you need to enter :help
mode to reproduce). Can confirm the behavior of mc
and Vim mentioned above. I think there have to be something in common between mutt
, mc
and vifm
.
Also this is not happening to ssh.exe
in Git Bash, so probably we should work with OpenSSH team (or PowerShell team) to figure out a fix.
Cause of this issue may be the same as #1649.
I've already seen bugs in ssh.exe from system32. This implementation of ssh does not pass ANSI sequences to terminal (ConEmu) but calls WinApi functions.
What does that mean? Do they simply paint the color themselves? Isn't that the job of terminal?
I also confirm this behavior for mc under ssh. Really bad flickering, you cannot use it anymore.
Hello Guys, first apologize for my english. I had the same flashing problem with mc in ssh in win10 since april win10 update. After some research and to do short: ssh in now include in win10 and is used by default in conemu (Cmder) and this is cause the flashing. If you go cd to C:\Program Files\cmder\vendor\git-for-windows\usr\bin and then enter .\ssh , connect to your favorite serveur and run mc : no more pb. I hope this help. I just found it this morning in holidays to Santorini Bye
EDIT: The best way for me is to remove openssh in optional applications of win10
EDIT 2: Ok not wake up. I read again this post and I realize my environnement is not the same as describe. But I think this problem come from windows ssh version not from conemu.
Dear Kicknride, damned - that is it! I can confirm that removing the windows native ssh client (that I had no idea was there) and restarting the computer fixed the issue.
Uninstalling the Windows OpenSSH Client immediately solved the problem for me. I didn't even have to restart. 👍
I wasn't aware that this was present, as I specifically installed the latest OpenSSH with the scoop package manager.
@sdellenb @CargoCoder Note that this issue explicitly specified “windows-build-in ssh” in title. The SSH in MSYS2 is known not to have this issue. (It has other issues though, but that’s beyond the scope of this issue report.)
And Git-on-Windows also brings the MSYS2, so anyone using their OpenSSH is also not affected by this issue (after they uninstall the built-in one, of course).
I also hit this issue today and only some googling brought me to this.
I would suggest that Cmder is tweaked to use own ssh even if system one is installed, or at least produce a warning.
Too bad that Cmder does not have a proper installer that would be offering this option or just removal of system openSSH
@onkami Suggestion of Cmder should go to https://github.com/cmderdev/cmder.
@franklinyu I opened it there, but don't you think it may be a ConEmu issue, that Cmder uses as is? :)
@onkami I have never used Cmder, but "being tweaked to use own SSH" doesn't make sense in ConEmu, because there is no "own SSH". ConEmu doesn't come with any SSH at all. If Cmder includes SSH then they are the ones to bind SSH to whatever terminal they use. It's like blaming Hunts when McDonald's put the ketchup in Coke.
Removing system SSH would be more absurd for ConEmu (though it may make sense for Cmder).
In contrast, "making ConEmu work with OpenSSH" (or even "making OpenSSH-Win32 work with ConEmu") is what this issue targets.
Thanks for the clarification :)
Same isssue. @Maximus5 don't you use ssh client in ConEmu? :)
Open-ssh is not a good choice. I use ssh from git-for-windows.
I tried it:
-bash-4.1$ mc 0 [main] ssh 12400 C:\Program Files\Git\usr\bin\ssh.exe: *** fatal error - cmalloc would have returned NULL Stack trace: Frame Function Args 00180000000 0018005E0DE (00180230639, 00180230C39, 000FFFFA0E0, 000FFFF9270)
Same for me when using mc
(Midnight commander) inside vagrant box.
My ConEmu version is 180626 preview x64.
Also noticed that
my cmder also flashing on 2 condition
I wonder is that cmder is conflict with cygwin open-ssh?
and how to solve this? thank you...
Adding c:\tools\Cmder\vendor\git-for-windows\usr\bin;
to cmder Settings->Startup->Environment did the trick for me.
As I'm not using cmder but git for windows, setting this environment variables worked for me:
set PATH=%ConEmuBaseDir%\Scripts;%PATH%
set PATH=%ProgramFiles%\Git\usr\bin;%PATH%
For anyone who encountered this issue and does not want to change windows openss-client I can advice to launch mc in a new tmux window. It works perfectly with conemu.
Got the same issue on Windows 10 with vagrant ssh and mc inside.
Vagrantfile
Vagrant.configure("2") do |config|
config.vm.box = "ubuntu/bionic64"
config.vm.provider "virtualbox" do |vb|
vb.memory = "1024"
end
config.vm.provision "shell", inline: <<-SHELL
apt update && apt install -y mc
SHELL
end
Commands to reproduce it in ConEmu console:
vagrant up && vagrant ssh
mc
tmux helps, but it disables the scrollbar.
The trick is to put a non-windows ssh
client (e.g. coming from MSYS2 or Git-for-Windows) into PATH
environment variable of Windows OS. This way there is no need to uninstall built-in Windows ssh client.
Then Vagrant and other programs will use it and this bug (blinking) will not happen.
But the question is: which downsides are if using non-builtin Windows ssh client?
What I noticed so far is colors of PS1
are gone (with Windows builtin ssh they are worked fine). Maybe there are some other downsides like non-working ssh-agent or something like this?
@xak2000 Author is using Git Bash himself so I imagine that Git Bash would have less issues, and issues about Git Bash will be fixed more actively. For example, I have created two issues here, #1726 was closed while #1649 is still open.
Guys, any updates?
SSH.exe from latest Git for windows doesn't work too: when mc
is called console is just hanging.
If I run the same from true powershell console it is working fine.
Update: I just disabled ConenumHk.dll injection in settings and ssh started working just fine. So looks like ConenumHk.dll is culprit.
I can confirm too, that @re3lex solution works, When "Inject ConemuHk" is un-checked, mc htop and other applications with console UI work fine!
Can also confirm that disabling the library: ConenumHk.dll
in:
Settings --> Features --> [Main PANEL] [In-console options SECTION] Inject ConEmuHk
Fixes the problem... But probably breaks a load of other stuff I haven't noticed yet.
In the lastest version of Conemu (191012 x64, run in Cmder) right clicking into the Cmder window seems to fix the issue as well.
Dear Kicknride, damned - that is it! I can confirm that removing the windows native ssh client (that I had no idea was there) and restarting the computer fixed the issue.
Confirm that uninstalling of OpenSSH fixes the issue with ficker/fluttering/flashing of Midnight Commander through SSH in ConEmu.
Adding /nix_tools 2
into Settings-Startup-Tasks-cmd::Cmder fixes it:
See: https://github.com/cmderdev/cmder/issues/1875#issuecomment-473488955
Can also confirm that disabling the library:
ConenumHk.dll
in:
Settings --> Features --> [Main PANEL] [In-console options SECTION] Inject ConEmuHk
Fixes the problem... But probably breaks a load of other stuff I haven't noticed yet.
This also fixed terminal speed more 120 times!
conemu.221218
ssh to linux server and test
test in disabling the library: ConenumHk.dll
time for i in {1..1000000}; do echo $i; done
...
999999
1000000
real 0m5.850s user 0m2.255s sys 0m0.802s
test in enable the library: ConenumHk.dll
time for i in {1..1000000}; do echo $i; done
...
999999
1000000
real 2m10.831s user 0m2.355s sys 0m0.751s
tmux stops the flashing. In Conemu, connect to a linux server using Windows SSH. Run emacs directly, flashing. Run tmux first, then emacs, no flashing.
ConEmu build: 180526 preview x64 OS version: Windows 10.0.17134.112 x64
When I start a console (cmd or powershell) and connect to my ssh server via the ssh command (which comes with windows) and open mutt, the screen starts flashing. It seems that the screen switches between mutt and the normal console.
It appears that this comes from the fact that mutt runs in console fullscreen mode (like nano or vim) but produces output in the normal console. Other console fullscreen applications like nano are working normally.
On the normal cmd on Windows and on putty, mutt is working normally.