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

👍 I can not use tmux with cbwin right now.

from cbwin.

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

from cbwin.

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.

from cbwin.

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

from cbwin.

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).

from cbwin.

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.

from cbwin.

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);

from cbwin.