$ | >

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

1,146 votes
Sign in
(thinking…)
Password icon
Signed in as (Sign out)

We’ll send you updates on this idea

Redmor shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

37 comments

Sign in
(thinking…)
Password icon
Signed in as (Sign out)
Submitting...
  • Anonymous commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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.

  • Steve Carter commented  ·   ·  Flag as inappropriate

    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
    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  ·   ·  Flag as inappropriate

    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.

  • Anonymous commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    Rich,

    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  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    In Linux kernel there is the *binfmt* facility[1] 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.

    [1] https://www.kernel.org/doc/Documentation/binfmt_misc.txt

  • Roman Semenov commented  ·   ·  Flag as inappropriate

    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.

  • keith commented  ·   ·  Flag as inappropriate

    priority for me is to launch VS Code from bash, pointing to my project 'code .'

  • Tester commented  ·   ·  Flag as inappropriate

    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.

  • Tester commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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.

  • d21mike commented  ·   ·  Flag as inappropriate

    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.

← Previous 1

Feedback and Knowledge Base