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.
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.
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.
Getting bash to run was a major milestone. Getting that application (which hooks into IO, process control, console output, devices, security, among many, many other things) is orders of magnitude more complex than getting something like awk running (and it still isn't 100% complete). I guess, from my perspective, the major deliverable for WSL was bash. You could have gotten hundreds of other subsystems in the LTP delivered, and dozen of the major products like nginx, cassandra, etc.. running - but until I could hop onto the system with bash, it wasn't an environment that I could interact with (as opposed to my programs).
There are many userland binaries that require far more system calls than bash. Take any general purpose programming language, like Python, Ruby or JavaScript on node as a simple example. Their libraries expose a lot of functionality that would finally translate into syscalls.
So no. I disagree that bash was a major final milestone.
In particular, check out this tidbit:
“Until you run Bash, no Linux process can run on your machine. As soon as you open Bash, you can choose to start any background services you want to have run. If you want to have MySQL or FSH or ssh or Postgres or Apache or whatever run, you can start them manually or autostart then with the .bashrc file,” Turner pointed out. “But as soon as you close the Bash console, we tear down any running Linux processes. So if you close the console window, you can no longer access your system via ssh, from your machine or any other.”
Whats interesting about this, is bash really plays a significant role in anchoring the entire windows subsystem for linux - more so than what you would normally expect out of merely a shell - to some degree, it is your user environment.
The limitation you are referring to is purely artificial, since WSL implements those system calls (they're required to implement bash itself) and I bet they are going to be fixing it soon.
I recommend you the following book: http://man7.org/tlpi , go to Chapter 24. kthx
I'm curious as to whether you realize that you've now taken so strong a position on this issue that you've blinded yourself to the evidence? I just gave you some information that showed that, the center of activity for Creators Edition is Bash. Bash is the only way that you can launch your linux subsystem on windows. Lots of work has been done on this Bash environment. It's entirely reasonable for Microsoft to say, "What's new in Bash/WSL and Windows Console" - as that's where they've done all the work. Bash is not just a Unix Shell in Microsoft's particular implementation - unlike every instance of Unix I've ever used (Starting with SunOs in 1993, but including zillions of iterations of Linux, OpenBSD, Solaris, etc...) - your shell on WSL is not just an entry into /etc/passwd, but instead is your operating environment - that, when it goes away, takes the entire process tree with it.
I kind of get what you are saying, that you are irked that Microsoft is trying to take some ownership of Bash, when it's really a GNU property - but, honestly, this is more like a temporary fork. Right now, for Anniversary Edition and Creators Edition - Bash is the center of gravity (along with the console environment - tons of awesome stuff there). And I agree with you, that this feels like a temporary hook, and that in the future, WSL will be able to run without Bash - and that will be a good (great!) thing - crontab! And then, Bash will hopefully just return to being what it was before - just a shell. (Perhaps with a few extra WSL hooks than vanilla GNU Bash - but we've already agreed that each implementation of Bash will have those hooks, so nothing new there.)
How about we both agree that Bash is a shell. Developed and Maintained by GNU. That is required by WSL right now to launch the linux subsystem, and therefore work by Microsoft on their Bash environment is important to WSL.
Stop adding noise/personal remarks and stick to relevant information.
> Bash is the only way that you can launch your linux subsystem on windows
For now. On Windows only. Bash has never been a requirement to run Linux software, they're not coupled in any way.
> Bash is not just a Unix Shell in Microsoft's particular implementation
Then it's no longer GNU bash. It's something else. Feel free to invite Microsoft to provide a new, non-ambiguous name for it. And then rename their binary: <something else>.exe so users like yourself don't get confused.
In addition, Microsoft should not couple the ABI with a particular shell. There are many shells and people should be able to select the one they prefer.
Finally, if WSL cannot run bash's unmodified Linux binary, then WSL is a leaky abstraction and not a true Linux ABI. In that case you are better off just running Linux from a VM for the time being.
Okay - you make some good points, and I'm coming around to seeing things your way. Note that the bash (the shell) that you are running inside WSL appears to be binary identical to a stock ubuntu distro - so from that perspective, the bash you are running turns out to be exactly GNU bash, totally unmodified.
shephard@singtest:~$ uname -a
Linux singtest 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
shephard@singtest:~$ ls -lart /bin/bash
-rwxr-xr-x 1 root root 1037528 Jun 24 2016 /bin/bash
shephard@singtest:~$
root@Skully:~# uname -a
Linux Skully 4.4.0-43-Microsoft #1-Microsoft Wed Dec 31 14:42:53 PST 2014 x86_64 x86_64 x86_64 GNU/Linux
root@Skully:~# ls -lart /bin/bash
-rwxr-xr-x 1 root root 1037528 Jun 24 2016 /bin/bash
And once WSL has been fired up, you can run any shell you want to .
root@Skully:~# fish
Welcome to fish, the friendly interactive shell
Type help for instructions on how to use fish
Reading around the web - I note that Microsoft appears to be very careful about referring to "Bash/WSL" as a joint unit to refer to the Bash.exe component of WSL. Perhaps everyone on this thread (minus you and a few others) are the ones who are confused - perhaps the "Bash.exe" in Bash/WSL really is completely unrelated to "bash" the Bash shell? It may be the case that when I type "Bash.exe" from the start menu on Windows, the binary I'm running is completely unrelated to "bash" the linux shell - and this entire thing is a branding exercise. (as I think you've very patiently been trying to point out). Perhaps it would have made more sense to rename "Bash.exe" to "wsl.exe" - but then they wouldn't have been able to ride on Bash's branding...
It's kind of Ironic when the one person being downvoted to oblivion for several days turns out to be the only one correct. But at least you won over one person. I'll never refer to it as anything other than WSL - and correct people who think they are running Bash (the GNU shell) when they type "Bash.exe."
Fair enough. Hope you can un-downvote the ones you downvoted. While comparing binaries by size can help, I recommend comparing binaries by hashing them (e.g: sha1sum). Usually better in terms of security.
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.
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.
You need to reread this thread because I am literally the only person who entertained your poorly written arguments and spoke to you like you weren't a troll. Instead of insulting me and demanding compensation you really should be thanking me for being the only person who gave your opinion the time of day.
I wasn't the one who downvoted your comments. In fact quite the opposite as I actually upvoted your OP (I felt a little sorry for you) but now I wish I hadn't bothered.
And for what it's worth, your original argument was not that Bash.exe shouldn't include the WSL. You've just subtly inched your way to that conclusion after all the other complaints you made were directly debunked. I even threw you a lifeline a few comments earlier (as referenced in my previous post) and you argued that wasn't your point, yet now -somehow- it is? Jeez....
>So while the trolling remarks of the OP are clearly unconstructive, i can at least emphasise with why he feels the need to speak out against MS. He just did so in a pretty lousy way.
Just stay on topic and avoid personal attacks.
I have been consistently referring to GNU bash, Linux and Linux software interchangeably.
Creating confusion around those terms because is not in the best interest of the community of users of GNU/Linux.
Even if Microsoft, Windows and WSL never existed, GNU bash would continue to be what it is, which is: A Unix shell. Not a technical requirement to run Linux software.
typo: I have been consistently against referring to GNU bash, Linux and Linux software interchangeably.
Also against referring to GNU bash and bash.exe interchangeably. Or people trying to redefine what GNU bash is because of how it is distributed under Windows.
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.
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.