better handle scenarios with a weaker link to the windows console (tmux, xterm&co, etc.)

[xilun]

For now redirections are forced on pts, and there is OUTBASH_PORT and ~/.config/cbwin/outbash_port if launched with --outbash-session, but this far from ideal. In cases where we came from a Windows Console that is not there anymore (because we launched an xterm, a tmux, whatever) we just fail unless we manually unset OUTBASH_PORT and we somehow managed keep an --outbash-session running. Automating all of that would be preferable.

[HeathNaylor]

👍 I can not use tmux with cbwin right now.

[xilun]

@HeathNaylor yep, I thought about that precisely when trying tmux :)

[xilun]

I think an extra background outbash.exe should be automatically started by the first interactive one, and somehow kept running at least until WSL is shut down (not only all interactive outbash.exe; really the whole WSL session). Both ports of interactive and background outbash.exe would be communicated to the WSL session. Then, if the caller is not on a "real" console, it would not only force redirections but also use the background outbash.exe port. Also if the caller is on a real console but has no interactive port, only a session port, it should also force redirections.

However such a behavior presents a security risk if users only want to temporarily allow callback of Win32 from WSL, because they could not be aware that it might continue to be possible after all their interactive outbash.exe sessions are finished (if WSL is not stopped either because it still runs bash.exe sessions, or for other reasons) -- therefore a systray icon might be a good idea to indicate that the background process is running.

[xilun]

Also a flag shall be provided to launch an interactive outbash.exe without starting (if it does not exist) a session one.

[xilun]

Also, at least in a first time, the console window of the background outbash.exe shall be kept, preferably hidden but with an option through the systray icon to display it again, so that traces of the background process can be seen (for now they are exclusively emitted to stderr).

[xilun]

Also a flag shall be provided to launch an interactive outbash.exe without starting (if it does not exist) a session one.

Problem: the lack of a mandatory background session outbash.exe would render it difficult for the caller to choose which port to use in case there is no stdfd to a real console. Unfortunately connect() to a localhost closed port fails only after a 1s timeout (why???), which makes it not a good idea to try to fallback on another port; we must know the "good" one beforehand.

So to fix that pb, the caller must also know if it is in an outbash.exe with the backgroundless option -- in which case the env var (interactive) will be used if it exists; otherwise the env var will only be used if it exists and if the caller is on a "real" console.

[goreliu]

I think a new --outbash-daemon option is necessary, just write ~/.config/cbwin/outbash_port and run in background without running any bash.exe process.

--outbash-session also works, but I need to write a .js script to hide outbash.exe, and a bash is always running in WSL.

var ws = new ActiveXObject("WScript.Shell");
ws.Run("outbash.exe --outbash-session", 0, false);