New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Confirm closing: incomplete operations doesn't work as expected anymore (ubuntu bash) #1097

Closed
Morgy93 opened this Issue Apr 10, 2017 · 8 comments

Comments

Projects
None yet
5 participants
@Morgy93

Morgy93 commented Apr 10, 2017

Versions

ConEmu build: 161206 x64
OS version: Windows 1703 (15063.13) x64
Used shell version (Far Manager, git-bash, cmd, powershell, cygwin, whatever): Bash on Ubuntu on Windows

Problem description

While there are no tasks currently running, ConEmu thinks there is one:
image

Steps to reproduce

  1. Get the Windows 10 Creators Update?
  2. Open any Bash on Ubuntu on Windows within ConEmu
  3. Try to close the window / tab

Actual results

Confirm closing window

Expected results

No confirm closing window

Additional notes

I think it happens since I installed the Creators Update ... or let's just say I don't have that issue for long and that's the only think I can think of that might have changed.

@Maximus5

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Apr 10, 2017

Owner

Sure it is not. Actually, it never was.
BashOnWindows

WinApi doesn't expose list of processes running in Linux subsystem.

Owner

Maximus5 commented Apr 10, 2017

Sure it is not. Actually, it never was.
BashOnWindows

WinApi doesn't expose list of processes running in Linux subsystem.

@Maximus5 Maximus5 closed this Apr 10, 2017

@teocasse

This comment has been minimized.

Show comment
Hide comment
@teocasse

teocasse Apr 18, 2017

Could you please elaborate on why this was closed? Is it the new expected behavior?

I can confirm that this is due to the Creators Update, as I upgraded 2 different machines. Both these machines did not ask for confirmation before the upgrade, and started asking for confirmation after the upgrade.

Could you please elaborate on why this was closed? Is it the new expected behavior?

I can confirm that this is due to the Creators Update, as I upgraded 2 different machines. Both these machines did not ask for confirmation before the upgrade, and started asking for confirmation after the upgrade.

@Maximus5

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Apr 18, 2017

Owner

I see now

Owner

Maximus5 commented Apr 18, 2017

I see now

@christoferd

This comment has been minimized.

Show comment
Hide comment
@christoferd

christoferd Jul 10, 2017

How to reproduce (Windows 10):

  1. Do something so that the diff will be longer than a page (in Cmder window)
  2. git diff

  3. Notice the ":" character at the bottom, press Page Down to continue
  4. Notice "END"
  5. Press Ctrl+C ... this looks like it closed the process and returns to the command prompt.
    Sometimes trying to use other commands or pressing some keys will result in ":" appearing.
    Closing the Cmder window using [X] button will result in the dialog box seen in issue report above.

How to reproduce (Windows 10):

  1. Do something so that the diff will be longer than a page (in Cmder window)
  2. git diff

  3. Notice the ":" character at the bottom, press Page Down to continue
  4. Notice "END"
  5. Press Ctrl+C ... this looks like it closed the process and returns to the command prompt.
    Sometimes trying to use other commands or pressing some keys will result in ":" appearing.
    Closing the Cmder window using [X] button will result in the dialog box seen in issue report above.
@Maximus5

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Jul 10, 2017

Owner

@christoferd This issue was fixed and closed.
From your description is absolutely not clear what versions did you use. Anyway, if you are talking about WSL, incomplete operations are not and will not be detected there.

Owner

Maximus5 commented Jul 10, 2017

@christoferd This issue was fixed and closed.
From your description is absolutely not clear what versions did you use. Anyway, if you are talking about WSL, incomplete operations are not and will not be detected there.

@AquaeAtrae

This comment has been minimized.

Show comment
Hide comment
@AquaeAtrae

AquaeAtrae Jun 24, 2018

@Maximus5 Thanks for all your hard work here. :)

I'm glad to hear this was fixed for "Bash on Ubuntu on Windows". I do see it works correctly when using bash.exe or wsl.exe directly.

However, the only documented method to show 256-colors involves calling scripts (a .cmd script which starts wslbridge and runs a .sh script within it). So understandably, we can no longer close the window without it thinking that I still have an incomplete process (the scripts).

I don't understand how wsl-con.cmd and its escape sequence (\e[9999H) enables 256 colors through the hidden RealConsole to appear properly within ConEmu. However, after a lot of experimentation I found a simpler method that works great. However, it only works once. The required Escape character is replaced with a "?" after closing ConEmu.

Can you fix the Task settings to permanently store all (unicode) characters including this Escape character? And can you document this or a better solution for those of us using WSL?

Here's the method's I've seen in your current documentation.

Closes nicely but only 16 colors...
based on "Preferred way to run WSL" .

set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & %ConEmuBaseDirShort%\conemu-cyg-64.exe --wsl -cur_console:pnm:/mnt -t bash

256 colors but appears as an Incomplete Operation when closing...
based on "How to get 24-bit colors working" which runs wsl-con.cmd and then wsl-boot.sh within WSL.

set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & %ConEmuBaseDirShort%\wsl\wsl-con.cmd -run

SUCCESS (...TEMPORARILY)
As I was working on documenting this, I believe I've come up with a Task definition that successfully accomplishes everything without the additional script layers. I'm posting the method I used in hopes that you and others might be able to reproduce my results.

set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & echo �[9999H & %ConEmuBaseDirShort%\conemu-cyg-64.exe --wsl -cur_console:pnm:/mnt -C~ -t bash

IMPORTANT: "echo {escape char}[9999H" is the actual escape character (Alt 027) which others can copy and paste from here since github won't present it as is.

https://i.imgur.com/CCARyWx.png

ConEmu 171025 [64]
Linux Mist 4.4.0-17134-Microsoft #112-Microsoft Thu Jun 07 22:57:00 PST 2018 x86_64 x86_64 x86_64 GNU/Linux
Description: Ubuntu 16.04.4 LTS

AquaeAtrae commented Jun 24, 2018

@Maximus5 Thanks for all your hard work here. :)

I'm glad to hear this was fixed for "Bash on Ubuntu on Windows". I do see it works correctly when using bash.exe or wsl.exe directly.

However, the only documented method to show 256-colors involves calling scripts (a .cmd script which starts wslbridge and runs a .sh script within it). So understandably, we can no longer close the window without it thinking that I still have an incomplete process (the scripts).

I don't understand how wsl-con.cmd and its escape sequence (\e[9999H) enables 256 colors through the hidden RealConsole to appear properly within ConEmu. However, after a lot of experimentation I found a simpler method that works great. However, it only works once. The required Escape character is replaced with a "?" after closing ConEmu.

Can you fix the Task settings to permanently store all (unicode) characters including this Escape character? And can you document this or a better solution for those of us using WSL?

Here's the method's I've seen in your current documentation.

Closes nicely but only 16 colors...
based on "Preferred way to run WSL" .

set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & %ConEmuBaseDirShort%\conemu-cyg-64.exe --wsl -cur_console:pnm:/mnt -t bash

256 colors but appears as an Incomplete Operation when closing...
based on "How to get 24-bit colors working" which runs wsl-con.cmd and then wsl-boot.sh within WSL.

set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & %ConEmuBaseDirShort%\wsl\wsl-con.cmd -run

SUCCESS (...TEMPORARILY)
As I was working on documenting this, I believe I've come up with a Task definition that successfully accomplishes everything without the additional script layers. I'm posting the method I used in hopes that you and others might be able to reproduce my results.

set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & echo �[9999H & %ConEmuBaseDirShort%\conemu-cyg-64.exe --wsl -cur_console:pnm:/mnt -C~ -t bash

IMPORTANT: "echo {escape char}[9999H" is the actual escape character (Alt 027) which others can copy and paste from here since github won't present it as is.

https://i.imgur.com/CCARyWx.png

ConEmu 171025 [64]
Linux Mist 4.4.0-17134-Microsoft #112-Microsoft Thu Jun 07 22:57:00 PST 2018 x86_64 x86_64 x86_64 GNU/Linux
Description: Ubuntu 16.04.4 LTS

@AquaeAtrae

This comment has been minimized.

Show comment
Hide comment
@AquaeAtrae

AquaeAtrae Jun 24, 2018

PS: I think I found a permanent solution that works despite special characters getting lost from the Settings. I do still suggest that would be good to fix as it may affect some with different languages and character sets.

Rather than present the magic escape sequence from Windows, I found it also works coming from within the WSL shell. (Again, I have no idea what it actually does to affect the colors.)

So I simplified my Start Task even further to be...

set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & %ConEmuBaseDirShort%\conemu-cyg-64.exe --wsl -cur_console:pnm:/mnt -C~ -t bash -l -i

Then, to enable true color support, I added the following line to my .bashrc file.

# Enables 256-color (true color) for ConEmu
echo -e '\e[9999H'

If you use zsh or fish in your Start Task, just add this to .zshrc or .fishrc (I believe).

SUCCESS (ALWAYS!)
And that seems to do the trick. I can now see 256 colors and can immediately close the wslbridge window as expected.

AquaeAtrae commented Jun 24, 2018

PS: I think I found a permanent solution that works despite special characters getting lost from the Settings. I do still suggest that would be good to fix as it may affect some with different languages and character sets.

Rather than present the magic escape sequence from Windows, I found it also works coming from within the WSL shell. (Again, I have no idea what it actually does to affect the colors.)

So I simplified my Start Task even further to be...

set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & %ConEmuBaseDirShort%\conemu-cyg-64.exe --wsl -cur_console:pnm:/mnt -C~ -t bash -l -i

Then, to enable true color support, I added the following line to my .bashrc file.

# Enables 256-color (true color) for ConEmu
echo -e '\e[9999H'

If you use zsh or fish in your Start Task, just add this to .zshrc or .fishrc (I believe).

SUCCESS (ALWAYS!)
And that seems to do the trick. I can now see 256 colors and can immediately close the wslbridge window as expected.

@Maximus5

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Jun 24, 2018

Owner

The echo is processed by ConEmu itself and you may just write echo "^[[9999H". Actually, 9999 may be not enough if you have specified greater number in the console buffer height.

Owner

Maximus5 commented Jun 24, 2018

The echo is processed by ConEmu itself and you may just write echo "^[[9999H". Actually, 9999 may be not enough if you have specified greater number in the console buffer height.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment