Using outbash with urxvtc and Xming about cbwin HOT 22 CLOSED

Hi fpqc, what do you mean by "outbash_port gets reset on every restart"?

from cbwin.

I dunno, maybe I'm wrong, but there is an environment variable that gets set called OUTBASH_PORT that changes for each instance of outbash.exe. I was wondering if there was a way to make it so OUTBASH_PORT stays static so I can launch things from urxvtc.

Basically, I want to leave a single cbwin instance running, then be able to do wstart from any vterm I open, or alternatively, and better, have some way that if I use outbash.exe to launch a VTerm in Xming, I can still use it. The purpose of this is so I can do

wstart browser http://google.com

from urxvtc and have it launch my browser.

The problem is that if I do outbash.exe -c "urxvtc", it doesnt work because the "outbash daemon" closes immediately.

from cbwin.

I see. For now the only way outbash.exe works is per Windows console, and each instance sets up its own port to get this locality.

When you wcmd something without redirections, is is just launched by the corresponding outbash.exe and inherits its Win32 standard console handles, so it can detect it and use the whole Win32 console API (to the good Windows console instance) instead of being limited to printing characters in a stream. This is even more important than under a Unix TTY, because the Win32 console API is more based on specific functions, and less on control characters.

I'll try to use urxvt and Xming to see if I can come up with something practical. For commands that actually output something it will need to always redirect the stream (because urxvt can not be driven by the Win32 console API) even when the wcmd caller process detects its standard fds are a tty. I'm not really sure if I'll support this scenario in the end, but I'll take a look to see if something simple, and with somewhat acceptable results given the compromises, can be done.

from cbwin.

@fpqc how did you get urxvt working? I only can get

$  urxvtc
urxvt: protocol error while reading pty/tty fds from helper process, aborting.

when I try to launch it.

from cbwin.

Open one bash terminal and run

urxvtd -q -o -f (the daemon)

Once the Daemon is running, you can run with

bash.exe -c urxvtc

from cbwin.

Ok I understand the situation: the new terminal uses the environment variables of the urxvtc, which in the scenario you envisioned is never useful for the OUTBASH_PORT variable (either points to the Windows console from where urxvtc has been called, or just does not exist)

from cbwin.

I think one of the outbash.exe could be used as a session outbash and export its port through a mean more wide than an environment variable, then wcmd/wrun/wstart commands would fallback to that port if OUTBASH_PORT does not exist, and would always use redirections in this case.

from cbwin.

Works for me to have a fallback like you have described!

In the future, once Microsoft upgrades conhost to not be total crap, this kind of hack should not be needed, since outbash will be running in a good Terminal Emulator =]!

I am only running urxvt until MS makes conhost better with 256color and mouse support, although it would be pretty cool if you could figure out a way to have outbash (not just the callers) keep running until all processes spawned by the original outbash.exe die in the nice way that you did it with the Windows console. That would probably mean rewriting outbash as a Windows service that could track instances of bash.exe by PID., which would be a lot more work than just setting up a fallback outbash port.

from cbwin.

Yes, I don't think I'll be writing a Windows service anytime soon. Actually outbash might very well be quite short-lived if MS implement a decent way to call Win32 processes from WSL soon, as they told they eventually will.

from cbwin.

However, I'm intrigued by your last paragraph.

Do you mean you would like outbash.exe waiting on the WSL processes? Is this because it would run as long as urxvtd does? I'm not sure this is possible reliably, even for a Windows service (at least by only using public Windows APIs). Actually, for now, urxvtd will probably be killed by WSL if you close all your Windows consoles that ran bash.exe

from cbwin.

It will, but if you use run.exe (on Xming website) and a special script to open urxvtd (basically, run urxvtd -q -o -f then $SHELL) (because of the problem you mentioned), you can get it to run in the background at startup, although very weirdly, running outbash instead of bash with run.exe does not properly set the env variable "OUTBASH_PORT".

from cbwin.

Note: the explanation for the lack of OUTBASH_PORT environment variable is probably that bash was not launched in interactive mode, because the way that environment variable is set is by using a custom --rcfile, which bash interprets only in interactive mode.

from cbwin.

For info: commit fb6f0b1 changes the way the OUTBASH_PORT is set. OUTBASH_PORT should now be set regardless of the command line parameters, and not only when bash is launched in interactive mode. This, in itself, does not solve this issue, though.

from cbwin.

I can just hack it anyway by adding a line to my urxvtd startup script

echo export OUTBASH_PORT=$OUTBASH_PORT > ~/.cbwin
chmod +x ~/.cbwin

and then add a line to my .bashrc
source ~/.cbwin

I think this will work.

Edit: It still didn't work when using run.exe.

Edit2: Working now! I had to make a script to start wstart inside of VolFS.

Now there's another problem with urxvt crashing when clicking links (not related to cbwin, since it happens with WSL firefox too), but at least if I run my script

winbrowser url

it opens up the url in my Windows browser.

Thanks for all of your help, xilun!

from cbwin.

You're welcome!
I think I'll add a session mode anyway, so that the caller forces redirections when running under non-windows console. That way text win32 programs will display their output (the best they can) and accept (simple) input in such context.

from cbwin.

For what it's worth, xilun, I don't think Microsoft is going to actually do a built-in version of what cbwin does, since it will require them to actually write the linux-side callers/listeners. The best we can hope for is some kind of IPC directly from the Linux side to the Windows side and vice-versa (since right now, cbwin is forced to make use of IP ports in a way that is insecure as you noted.

I guess one way you could make it secure is by also adding a keycheck so that when you launch outbash, it starts the listener however you do that, but also requires the caller to meet a password check on each call, which could be set for when outbash launches bash so it does
bash.exe -c "(OUTBASH_PORT=generated_port OUTBASH_PASS=generated_uuid /bin/bash)"
and make it so the callers wcmd, wstart, etc pass the password whenever they are invoked (I am guessing this is also how you might be doing sessions?)

from cbwin.

I'm not so sure about MS not eventually providing builtin functions equivalent or better than cbwin. They are less constrained because they can tune what they want on the Win32, console, WSL, and NT kernel sides. They might find a way to get Win32 and Posix pipes compatible enough to be connected directly. The equivalent of the caller could be implemented using an equivament of binfmt_misc and some kinds of parasyscalls. There are a lot of questions to solve though: which win32 processes should be visible with WSL pids, how should they react to signals, ... I've not thought much about all that, but there are prior and existing examples (sfu&co, cygwin) they can consider and see if doing similar things would be possible and a good idea with wsl.

from cbwin.

About the pwd idea, I actually would prefer to filter using Windows firewall if this is possible, but it might be unavailable so this kind of pwd technique is also to consider.

from cbwin.

Commit 260cd55 let you do the following:

• you launch one outbash.exe, that you somehow manage to get long-lived, with --oubash-session as its first param. The way to get it long-lived is left to your imagination (to do my tests I used a shortcut launching: run.exe outbash.exe --outbash-session -c "urxvtd -q -o -f ; bash"
• --oubash-session as a first param is interpreted by outbash.exe and is not forwarded to bash. It yields to the creation of ~/.config/cbwin/outbash_port with the port number of that outbash.exe. OUTBASH_PORT is also set as usual.
• when a caller does not find OUTBASH_PORT (for example because of a direct call of bash.exe and not outbash.exe for launching those WSL processes), it tries to use the port defined in ~/.config/cbwin/outbash_port. If OUTBASH_PORT is defined, ~/.config/cbwin/outbash_port is never tried, even if the content of OUTBASH_PORT is invalid.
• when the port came from ~/.config/cbwin/outbash_port, the caller forces redirections.

Usage example:

• on a system with Xming running, start one urxvtd with the command: run.exe outbash.exe --outbash-session -c "urxvtd -q -o -f ; bash" (run.exe is from Xming)
• launch new urxvt consoles with C:\Windows\System32\bash.exe -c urxvtc
• from an urxvt (or any bash launched directly with bash.exe), you can do e.g. wcmd dir c:\\ or wstart notepad, while the outbash.exe --outbash-session is running.
• you can still launch other outbash.exe. The advantage in this case is that Win32 processes launched with wcmd from here can access directly to the Win32 Console API, because they are not redirected. (This advantage is somehow limited because of bad interactions when both Win32 and WSL processes have their stdio on the same Windows Console, but it uses less resources, reacts more quickly to Ctrl-Z in the Windows Console, there are probably some programs that can write Unicode correctly in UTF-16 on the Console while they would try a "random" DOS CP if redirected - while redirections to WSL needs UTF-8, etc...)

@fpqc can you tell me if this is useful, if you think of small adjustments, or any other ideas? I can do a binary release if you need.

from cbwin.

Haha, that sounds amazing!

I guess the only improvement I would suggest is seeing if you could add a tray icon for when it is in session mode (and/or ask the Xming guy Colin if you can redistribute with run.exe)?

But yeah, totally do a binary release, that's amazing!
Also yeah I would totally use

from cbwin.

Actually I guess it would be better to have a session process separated from the console ones, to also cover the cases where the Console you launched from disappear. But that's more work, I'll think about it later :) In this case maybe it would get a tray icon, but that's not my priority (especially since I don't know about graphical Win32)

On the caller side it would then be nice to have a more reliable way to detect if we are not in a Windows Console even if OUTBASH_PORT is set, for example outbash.exe -> do some work in the console, start an xterm without unsetting OUTBASH_PORT -> wcmd in the xterm won't force redirections, while ideally it should.

But well, for now the scenario with Xming/urxvtd/urxvtc is good enough, given it's already necessarily hacky to get urxvtd running in the background.

I'll make a binary release of the current version very soon.

from cbwin.

Dled new binary release. Works great! I was able to delete all of my custom scripts!

from cbwin.