5 ms·

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 binari

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.
      - laumars 10y ago
        I'm not going to disagree with you there but then I did cover that point myself about 2 posts earlier.
        partycoder 10y ago
        The point you conceded is literally the only point I've trying to make since the original post. Go back each level and you will see the same point being made over and over again. You owe me like 20 HN karma now. Next time, rather than rushing to downvote, accuse of trolling and insult, read more carefully.
- ghshephard 10y ago
  The problem is, that C:\Windows\System32\bash.exe has nothing whatsoever to do with bash, the GNU shell. They are entirely unrelated. C:\Windows\System32\bash.exe is the component which initiates the WSL subsystem. With cygwin, when you run bash.exe - you are literally running the bash shell compiled for windows. Once C:\Windows\System32\bash.exe starts up, it then launches bash - the GNU shell.
deleted 10y ago
[deleted]

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.
    - laumars 10y ago
      I'm not going to disagree with you there but then I did cover that point myself about 2 posts earlier.
      - partycoder 10y ago
        The point you conceded is literally the only point I've trying to make since the original post. Go back each level and you will see the same point being made over and over again. You owe me like 20 HN karma now. Next time, rather than rushing to downvote, accuse of trolling and insult, read more carefully.
ghshephard 10y ago
The problem is, that C:\Windows\System32\bash.exe has nothing whatsoever to do with bash, the GNU shell. They are entirely unrelated. C:\Windows\System32\bash.exe is the component which initiates the WSL subsystem. With cygwin, when you run bash.exe - you are literally running the bash shell compiled for windows. Once C:\Windows\System32\bash.exe starts up, it then launches bash - the GNU shell.

deleted 10y ago

[deleted]