5 ms·

My remarks were directed at the product being discussed ("Bash on Windows"), a name that I think is incorrect for objective reasons. You can agree or disagree,

My remarks were directed at the product being discussed ("Bash on Windows"), a name that I think is incorrect for objective reasons. You can agree or disagree, but the comment was technical in nature, not trolling. People do not use "Bash on Windows" just for the sake of using Bash (the shell), they use it to access GNU/Linux software through the WSL ABI.

ghshephard 10y ago
I'm wondering if you are misguided here - and what Microsoft is working on right now is "Bash on Windows" - I.E. The console environment that people want to interact with when writing quick scripts, connecting to remote servers, maybe running a little bit of a local web instance. Speaking for myself, personally - if I want to run GNU/Linux software through the Linux ABI - I'm not going to be doing it on WSL - I'll do it on a VM or on a farm of VPS/EC2 instances somewhere. The attraction to me for WSL is the ability to have all my rich windows software, tools in the same environment that I'm connecting to those hosts from (which I normally do with OS X). Note that the vast number of improvements (consoling, ping, vt100 support, launching windows apps from linux, etc...) in Creators Update are about improving the CLI/Shell experience for users.
- partycoder 10y ago
  Bash is merely a Unix shell, one of many. What you describe is the GNU/Linux userland. They are working on people being able to execute unmodified Linux binaries on Windows machines through an Application Binary Interface that implements the Linux system calls and translates them into Windows system calls, among other things... and doing it in the most transparent way possible (not requiring specific builds of each software, like Cygwin). This is the inverse operation of what WINE does. No need to rush to downvote a comment that is actually correct.
  - laumars 10y ago
    Everyone you're replying to understands how WSL and UNIX shells work. The error is on your part because you keep misunderstanding that the Windows executable one runs to invoke WSL is literally C:\Windows\System32\bash.exe Sure, once you've started bash you can then probably switch to whichever shell you want afterwards (NOTE: I say that but I've not tested to see if other shells work). But to use your WINE example, the Windows Bash.exe PE is the equivalent executable to the wine ELF. Now you are welcome to rant about how the WSL "invoker" should be isolated from the POSIX shell, but that's very different from the point you keep raising and thus keep getting down voted for.
    - partycoder 10y ago
      When I say bash, I am referring to GNU bash, the shell that has existed for decades now on Linux, BSD, macOS, Solaris and an endless list of other operating systems. I do not care if Microsoft couples their ABI and the shell and decides to call that "bash". GNU bash will continue to be what it has been for decades now. I also do not care if a lot of people want to take the entire GNU/Linux userland and decide to call that "bash". That is not bash either, and will never be no matter how many people insist on it, not even Microsoft. bash is GNU Bash, a project that you can learn from here: https://www.gnu.org/software/bash/ https://www.gnu.org/software/bash/ Finally, if Microsoft decided to couple bash with WSL, think that they went through the effort of replicating most Linux system calls. Having bash as a default shell is not a technical requirement on their part. Maybe now it will be, for backward compatibility reasons, but that's a different issue. Then, you can downvote and insult all you want, that won't make you right.
      - laumars 10y ago
        bash.exe on Windows is also GNU Bash: C:\Users\laumars>bash --version GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu) Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. The rest of the subsystem isn't called "bash", it's called "Windows System for Linux". It just happens that bash.exe on Windows contains the WSL hooks rather than being a straight port of GNU Bash. Frankly bash across Linux, FreeBSD and Solaris will differ anyway due to differences in the way PTYs are registered, variations in supported signals and different syscalls (all issues I've ran into when writing my own cross-platform Linux/Unix shell by the way). So you'll find hundreds of compile-time conditions defined in Bash's source code which alter the behaviour of the outputted ELF (and I don't just mean your typical libc linker differences). So MS and Canonical integrating the WSL hooks into bash.exe isn't massively different enough for your argument to stand.
        partycoder 10y ago
        Linux, BSD, Solaris, etc. have significant differences among them, and the source code needs to be aware of them. Same with all crossplatform software. But from the perspective of a Linux binary running on WSL, running on WSL should be the same as running on Linux. If bash is an exception to that, that seems more like a hack on Microsoft's part. If they implemented the execve() syscall and others, starting whatever other user specified shell should not be problematic.
  - deleted 10y ago
    [deleted]

ghshephard 10y ago

I'm wondering if you are misguided here - and what Microsoft is working on right now is "Bash on Windows" - I.E. The console environment that people want to interact with when writing quick scripts, connecting to remote servers, maybe running a little bit of a local web instance. Speaking for myself, personally - if I want to run GNU/Linux software through the Linux ABI - I'm not going to be doing it on WSL - I'll do it on a VM or on a farm of VPS/EC2 instances somewhere. The attraction to me for WSL is the ability to have all my rich windows software, tools in the same environment that I'm connecting to those hosts from (which I normally do with OS X). Note that the vast number of improvements (consoling, ping, vt100 support, launching windows apps from linux, etc...) in Creators Update are about improving the CLI/Shell experience for users.

partycoder 10y ago
Bash is merely a Unix shell, one of many. What you describe is the GNU/Linux userland. They are working on people being able to execute unmodified Linux binaries on Windows machines through an Application Binary Interface that implements the Linux system calls and translates them into Windows system calls, among other things... and doing it in the most transparent way possible (not requiring specific builds of each software, like Cygwin). This is the inverse operation of what WINE does. No need to rush to downvote a comment that is actually correct.
- laumars 10y ago
  Everyone you're replying to understands how WSL and UNIX shells work. The error is on your part because you keep misunderstanding that the Windows executable one runs to invoke WSL is literally C:\Windows\System32\bash.exe Sure, once you've started bash you can then probably switch to whichever shell you want afterwards (NOTE: I say that but I've not tested to see if other shells work). But to use your WINE example, the Windows Bash.exe PE is the equivalent executable to the wine ELF. Now you are welcome to rant about how the WSL "invoker" should be isolated from the POSIX shell, but that's very different from the point you keep raising and thus keep getting down voted for.
  - partycoder 10y ago
    When I say bash, I am referring to GNU bash, the shell that has existed for decades now on Linux, BSD, macOS, Solaris and an endless list of other operating systems. I do not care if Microsoft couples their ABI and the shell and decides to call that "bash". GNU bash will continue to be what it has been for decades now. I also do not care if a lot of people want to take the entire GNU/Linux userland and decide to call that "bash". That is not bash either, and will never be no matter how many people insist on it, not even Microsoft. bash is GNU Bash, a project that you can learn from here: https://www.gnu.org/software/bash/ https://www.gnu.org/software/bash/ Finally, if Microsoft decided to couple bash with WSL, think that they went through the effort of replicating most Linux system calls. Having bash as a default shell is not a technical requirement on their part. Maybe now it will be, for backward compatibility reasons, but that's a different issue. Then, you can downvote and insult all you want, that won't make you right.
    - laumars 10y ago
      bash.exe on Windows is also GNU Bash: C:\Users\laumars>bash --version GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu) Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. The rest of the subsystem isn't called "bash", it's called "Windows System for Linux". It just happens that bash.exe on Windows contains the WSL hooks rather than being a straight port of GNU Bash. Frankly bash across Linux, FreeBSD and Solaris will differ anyway due to differences in the way PTYs are registered, variations in supported signals and different syscalls (all issues I've ran into when writing my own cross-platform Linux/Unix shell by the way). So you'll find hundreds of compile-time conditions defined in Bash's source code which alter the behaviour of the outputted ELF (and I don't just mean your typical libc linker differences). So MS and Canonical integrating the WSL hooks into bash.exe isn't massively different enough for your argument to stand.
      - partycoder 10y ago
        Linux, BSD, Solaris, etc. have significant differences among them, and the source code needs to be aware of them. Same with all crossplatform software. But from the perspective of a Linux binary running on WSL, running on WSL should be the same as running on Linux. If bash is an exception to that, that seems more like a hack on Microsoft's part. If they implemented the execve() syscall and others, starting whatever other user specified shell should not be problematic.
- deleted 10y ago
  [deleted]