3 ms·

Where does it say this can't? I understood the opposite: ...we decided to grow our command line family by adding real, native Bash and with it support for Linu

Where does it say this can't? I understood the opposite: ...we decided to grow our command line family by adding real, native Bash and with it support for Linux command-line tools which run directly on Windows in an environment that behaves like Linux!" edit: note that Bash and Linux tools cannot interact with Windows applications and tools, and vice-versa. So you won’t be able to run Notepad from Bash, or run Ruby in Bash from PowerShell. So, which is it?

xorblurb 11y ago
I think it won't be able to run windows program, at least at first, and the reason is probably mainly technical: detecting fork/exec pairs of calls where it should be possible to spawn a PE is non-trivial, especially since you mainly aim at standard Linux syscall compat with unmodified pre-existing GNU/Ubuntu userspace (and Linux does not even uses fork() but clone() as a syscall -- which makes the issue even more difficult to handle). Now as for what it could be useful for, I guess a lot of people will reclaim a solution to be able to run windows program from that environment, because one of the scenario is build-systems and leaving that to a separated environment would be too bad. At least I will. In the meantime, maybe we will be able to cope with ssh. Now back to technical stuff, I think the best way to allow execution of windows program from that environment would be a small custom program that uses a special syscall and to spawn a windows process. The end result would not be transparent (you would have to launch let's say "windows cl" instead of "cl" from the Linux env, but this is an extremely small price to pay, since: build-system already often can prepend things to command lines, for example to use ccache, we can actually implement this solution without even needing syscall support but instead TCP/IP (and maybe ssh) and switch to an accelerated para-syscallized solution when it is available -- but then the classical problem of inheriting the environment will reappear (env var to translate with heuristics, etc...) So maybe MS thought about all that and decided they will "never" do it (until they change their mind in 10 years), and we actually should just stick to MSYS for that kind of stuff? Would be a little sad, but it's not like we are without an existing working solution.
- Keyframe 11y ago
  MinGW with native bash would be really cool. That way, I would have the same, and native, build environment on Linux, OSX, and Windows.
  - xorblurb 11y ago
    Well, MSYS/MSYS2 lets do that today. It would just be more elegant to use native unported Linux binaries from an existing repository (which probably has more tools available too), but even with the low level syscall thing being solved, the other stuff MSYS fixes will reappear (mainly problems about path and environment translation, which is crucially important in build-sys). So we can guess it is at least not for the first version... Edit: reading your comment again, maybe you will be happy with building your windows exe with a MinGW cross compiler fully running under the Linux subsystem under Windows. That covers some needs, but not all. For example I really need to be able to e.g. launch cl from there with standard Makefiles and GNU Make.
    - Keyframe 11y ago
      Ah yes, I have yet to venture into the magical realm of cross compiling!
- JdeBP 11y ago
  See https://news.ycombinator.com/item?id=11417545 https://news.ycombinator.com/item?id=11417545 for another aspect of this.

xorblurb 11y ago

I think it won't be able to run windows program, at least at first, and the reason is probably mainly technical: detecting fork/exec pairs of calls where it should be possible to spawn a PE is non-trivial, especially since you mainly aim at standard Linux syscall compat with unmodified pre-existing GNU/Ubuntu userspace (and Linux does not even uses fork() but clone() as a syscall -- which makes the issue even more difficult to handle). Now as for what it could be useful for, I guess a lot of people will reclaim a solution to be able to run windows program from that environment, because one of the scenario is build-systems and leaving that to a separated environment would be too bad. At least I will. In the meantime, maybe we will be able to cope with ssh. Now back to technical stuff, I think the best way to allow execution of windows program from that environment would be a small custom program that uses a special syscall and to spawn a windows process. The end result would not be transparent (you would have to launch let's say "windows cl" instead of "cl" from the Linux env, but this is an extremely small price to pay, since: build-system already often can prepend things to command lines, for example to use ccache, we can actually implement this solution without even needing syscall support but instead TCP/IP (and maybe ssh) and switch to an accelerated para-syscallized solution when it is available -- but then the classical problem of inheriting the environment will reappear (env var to translate with heuristics, etc...) So maybe MS thought about all that and decided they will "never" do it (until they change their mind in 10 years), and we actually should just stick to MSYS for that kind of stuff? Would be a little sad, but it's not like we are without an existing working solution.

Keyframe 11y ago
MinGW with native bash would be really cool. That way, I would have the same, and native, build environment on Linux, OSX, and Windows.
- xorblurb 11y ago
  Well, MSYS/MSYS2 lets do that today. It would just be more elegant to use native unported Linux binaries from an existing repository (which probably has more tools available too), but even with the low level syscall thing being solved, the other stuff MSYS fixes will reappear (mainly problems about path and environment translation, which is crucially important in build-sys). So we can guess it is at least not for the first version... Edit: reading your comment again, maybe you will be happy with building your windows exe with a MinGW cross compiler fully running under the Linux subsystem under Windows. That covers some needs, but not all. For example I really need to be able to e.g. launch cl from there with standard Makefiles and GNU Make.
  - Keyframe 11y ago
    Ah yes, I have yet to venture into the magical realm of cross compiling!
JdeBP 11y ago
See https://news.ycombinator.com/item?id=11417545 https://news.ycombinator.com/item?id=11417545 for another aspect of this.