Let us launch Windows processes from Bash
It'd be cool to launch VS Code from Bash instead of leaving & looking for the file in Windows Explorer to edit, as was shown in the Demo.
It'll allow automating build tasks involving both Linux and Windows tools with sh scripts
We’re delighted to announce that Windows 10 Insider build #14951 has just landed and includes Bash <–> Windows Interop.
never mind found it my self
$ mode.com con cols=150 lines=100
as simple as that ...you just need the .com to make it work
How to pipe from bash to windows ?
Where is the info on this I have a very simple application i would like to be able to pass a command & parameter% to cmd.exe
bash set some vars - cols=150 rows =100
cmd.exe run a dos command - mode con cols=%1 lines=%2
or pipe to windows cmd.exe < < "mode con cols=150 lines=100\n\r"
or something along those lines, I don't even care about return.... anything at this point
so how would i go about this, format a command in bash ....pipe the command to windows with parameters ....exact syntax would be awesome.
Oliver Smith commented
I'm really glad to hear this, but I can't seem to find any details of how the Interop works.
Those who are opposing this: "Windows Subsystem for Linux"... /Subsystem/. It is *specifically* not a container, not a zero-cost virtual machine, it is a part of Windows, it uses the WIndows Kernel through a thin layer that allows it to be accessed via the Linux Kernel ABI. Isolation would fatten the layer and essentially make it a redundant duplicate of container/virtualization products already available.
thomas lee commented
Can you explain how this interop enables us to launch windows processes from BASH?
Justin Chase commented
Awesome I will check it out!
Emmanuel Zoutas commented
Benjamin M commented
Steve Carter commented
My use-case is test infrastructure in python, make, bash, sed, awk etc that runs a system-under-test that is a Windows Console app. Say it's C:\build_dir\SUT.exe. I don't care if it's a bit of work on the ubuntu side to invoke the SUT, because I can script around it and bash's approach to escape characters means I can switch the slashes in paths and quote them to the windows executable fine. I'm envisioning a bash command like:
$ win_path /mnt/c/bibble/bobble
$ win_exe /mnt/c/build_dir/SUT.exe $(win_path testsuite1/testcase1/input_file)
win_exe would start the windows executable with the current directory and environment carried over from the bash shell and the parameters passed verbatim.
Jaka Bac commented
FFmpeg supports MSVC builds but requires MSYS for the build environment on Windows. I imagine that this is not the only cross-platform project's build setup that would benefit from this feature.
Another use case FWIW:
Being able to set my git editor and difftool to Windows desktop apps (eg, Sublime Text and Beyond Compare, respectively).
Rennie Allen commented
Any update on this? I would imagine the tricky part was getting the loader to load elf binaries, I would figure it wouldn't be too hard to coax the Windows loader into loading PE binaries ;-)
Yashar Fakhari commented
The original request is to be able to do development in VS Code on a project that you are working on in Windows 10 Bash.
For me, I am doing this everyday and happy with the existing features. Here is the easy workaround:
- Set your workspace, or where you have your project files at, are doing a git clone to on some path at /mnt/c/[path to my project]. I actually do all my work under c:\temp\ since everything is officially in a git repo and only on the local system temporarily to add a feature or resolve a bug.
- Open VS Code in Windows from the start menu, icon, taskbar, etc, and in it open the folder "c:\[path to my project]
Works for me in all my NodeJS development right now. I do all builds, git commands, deployments from Windows 10 Bash, while the code editing happens in VS Code. In isolated cases, I may even use notepad++ in windows, the files are all under /mnt/c aka c: of windows to access.
Kostis Anagnostopoulos commented
In Linux kernel there is the *binfmt* facility that allows the execution of ANY binary file, launched in its interpreter.
If you emulate the linux-module's operation of `/proc/sys/fs/binfmt_misc/register`, along with the *cbwin* project, you can provide this last mile for biderectional executuon of binaries.
Hi, take a look here: https://github.com/emavgl/windows-bash-contextmenu
Roman Semenov commented
To people that want to isolate WSL from windows: why don't you just use a VM? This is already possible for a long time with VirtualBox, Vagrant etc. WSL provides no major benefits relative to VM in this regard.
WSL is an attempt to integrate both systems so lets work in this direction and integrate them.
priority for me is to launch VS Code from bash, pointing to my project 'code .'
As I said, I oppose this but if anything, this should be done using a Windows side listener and explicit permissions. I want to use lxrun as a sandboxed container.
I'm actually of the opposing view. I'd like a way to seal off the Ubuntu environment so that it cannot access the Windows filesystem. This is something I'm going to run Firefox on Bash on Ubuntu on Windows as my primary browser.
Jim Howard commented
The prior Windows NT SFU environment could do this to useful effect. WSL should do so also.
In response to @DarkSim905: each environment has certain things they do best. It would be helpful if each environment can invoke commands in the other, as with pipelines. Some command combinations are - of course - completely unreasonable, many not so.
Many "workarounds" are possible (telnet, ssh, etc. as mentioned). But they are workarounds, and don't allow things like pipelines, etc. Not sufficient.
I agree with this. I currently use Cygwin to do this. I run a Shell script (Bash) taking advantage of what that offers to also test my windows application which is compiled in windows. But with this I cold also test my Linux Version at the same time from the same script. I do not have a Cygwin Version because of Cygwin Licensing Restrictions. I also use a Mac and nice to run the same scripts on Windows.