3 ms·

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 sys

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.
      - laumars 10y ago
        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....
        10y ago
ghshephard 10y ago
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). I guess we just have different priorities.
- partycoder 10y ago
  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.
  - ghshephard 10y ago
    Here is an interesting link for you: https://thenewstack.io/future-wsl-distro-independent-flexibl.. https://thenewstack.io/future-wsl-distro-independent-flexibl.... 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.
    - partycoder 10y ago

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.
    - laumars 10y ago
      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....
      - 10y ago

ghshephard 10y ago

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). I guess we just have different priorities.

partycoder 10y ago
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.
- ghshephard 10y ago
  Here is an interesting link for you: https://thenewstack.io/future-wsl-distro-independent-flexibl.. https://thenewstack.io/future-wsl-distro-independent-flexibl.... 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.
  - partycoder 10y ago