What’s New in Bash/WSL and Windows Console
blogs.msdn.microsoft.com
blogs.msdn.microsoft.com
Current Windows terminal options:
- ConEmu: mainly excellent but a little dated - eg, the active tab color is hard to distinguish but it can't be changed, apparently due to maintainer's insistence it works on Windows XP.
- Hyper: excellent but Ctrl C, Ctrl R etc broken in powershell.
Adding tabs to the Windows console makes more sense than have a third party create an entire console just to support tabs.
- Something called 'git-for-windows' which isn't actually git for Windows https://git-scm.com/download/win but unremarkable things like shell additions which give you git status in the prompt, and a not-particularly-good GUI.
- Clink (which is for cmd.exe).
I.e., this doesn't in any way address the limitations mentioned in the post you're replying to.
> It lets you create tabs, Ctrl+c - Ctrl+v, and works for Cmd, PowerShell, and Bash
Not sure why you think that's addressing this.
It's so promising though, I paid for it.
I pretty much use it mostly for ssh and have never noticed any lag. There are one or two oddities, but I can live with them. It's miles better than plain old PuTTY.
If I'm doing RDP I use RoyalTS, another thing I paid for because it does RDP management so well:
I personally don't want a terminal with built-in tabs or windows since I use tmux for that. On my Mac I use iTerm2 where tabs/windowing is integrated with tmux. Try it and see if you like it! :)
A fast, inbuilt, 2017-era terminal is.
- ConEmu has a UI that's a shotgun blast of shit.
- Hyper still fails at basic shortcuts.
- ConEmu plus other software still has a UI that's a shotgun blast of shit.
- Some person's half maintained fork of putty is some person's half maintained fork of putty and we already have Windows openssh for SSH purposes.
- A proprietary app you need to pay for is a proprietary app you need to pay for.
- tmux is not a tabbed terminal.
- Something that uses cygwin is something using cygwin.
The post is requesting a clean tabbed terminal, included in Windows, and maintained full time by Microsoft employees (whether Open Source or proprietary).
Edit: removed 'fully featured' as someone below thinks that means I want all the bullshit the other terminals add, rather than tabs, working escape sequences, and other terminal features.
- Minimal contrast in active tabs - can't be fixed due to Windows XP support.
- Flashes it's hidden console proxy on screen continually
- Settings menu with around 5000 options and no sense of heirarchy - something that's rare is just as prominent as something that's common
- Giant colorful icons and wasted space in the title bar. I can't throw my mouse to the top and pick a tab when it's maximised.
- Freaks out when your console is too large
- Does a bunch of things better done elsewhere: my profile bash/powershell profile sets environment variables, I don't need my terminal to do this.
2. I've seen it, happens probably once a month for < 50 ms when resizing or something. I can deal with it.
3. This is awesome, you go through it once and have every detail exactly they way you want it just because everything was shown (contrast to being forced to read the entire manual just to know what you can do). Great for discoverability. Take 15 minutes, quickly test out different settings and looks, reap the benefits for years to come.
4. I've removed the titlebar altogether. No borders at all either - Just a tiny (half row) discrete status bar at the bottom.
5. No idea what you mean here, can't recall to have seen it freak out ever.
2. That's great for you. My experience differs.
3. See 1, but for heirarchy.
4. Are sure you sure you can get the tabs all the way to the top?
5. See 2. I suspect I maximise the terminal more often or use a larger screen than you do.
3. Yes, a perfect hierarchy of the settings would be nice, in theory. Because never mind that what is important depends on the user and context - making the whole concept extremely tricky to get right. It is a tradeoff. And I haven't seen any terminal and few other applications that I've enjoyed setting up as much as ConEmu, most settings are logically where they should be. There are, understandably considering the amount of options, a few places where it can be difficult - but to help with that there is a great search function.
4. I don't even have a tab bar anymore, takes up way too much space and I always switch between tabs using the keyboard (since I only interact with the terminal from the keyboard anyway). But I tested it now, there is about 2px of space above the tab bar but if you try to press that area you still hit the tab you intended. So if you have maximized the window there is no possible way to click above the tab bar.
ConEmu is one of the most well polished applications I use on a daily basis, it doesn't get in the way. I miss it to death every time I'm using a non-windows machine.
> I wouldn't mind it being configurable but I understand the reluctance to do it if it breaks XP support.
Users running a current OS needing to find their current terminal should take precedence over a small number of people running an unpatched 15 year old OS.
3. Re heirarchy:
> never mind that what is important depends on the user and context
Ultimately more users want to change the font than integrate with 'FAR', or change the method of anti-aliasing used.
4. Interesting (this really should be a default). How do I do it?
> There are, understandably considering the amount of options
The Settings app has more options than ConEmu. It controls an entire OS and it's still easier.
> to help with that there is a great search function.
I've only just found that now, because it's in a different place to every other search box on Windows.
I'm not arguing the non-UX bits of ConEmu aren't great. I'm stating that ConEmu doesn't care about UX and it's really obvious.
It is not uncommon at all to have a search-bar directly associated with a tree-view. I get the feeling that you primarily use other operating systems.
The settings app is an absolute nightmare. And that's understandable, because the target group are people with no interest or knowledge about computers or windows at all. So it is beginner friendly, but not user friendly by any stretch. Do not confuse the two. Contrast to ConEmu, not beginner friendly at all but quite user friendly.
I do not know how you've set it up but I'm guessing you need to: Main -> Appearance -> Title bar section, Check "Hide caption always". It is non-standard so that's why I think it is sensible that it isn't enabled by default.
I'm arguing that the UX is top notch for it's intended audience. If all you want is cmd.exe with tabs, then yes, I fully understand why ConEmu isn't for you.
But this is derailing, I probably won't be continuing this thread.
- There shouldn't be a 'main' section. 'Main' isn't a category. 'Appearance' would be more logical. Neither should we show that many controls on screen: use a 1/2 heirarchy rather than frames.
- "not uncommon at all to have a search-bar directly associated with a tree-view" Yep, I'd ditch the tree view, and move search to top right to be consistent with other apps.
- "The settings app is an absolute nightmare." How? Settings is aimed at people who want to configure an entire OS - it's doing a more complicated job than conemu is. You could measure the time taken by users of different skill levels and they'd all have a faster time finding something in Settings. Again, let's get or look at data rather than caring about our personal experiences.
> changing the anti-aliasing is about as important as the font
It's not important at all. If you measured it, how many users want custom anti-aliasing options for a single app? Does iterm do it? Does gnome? are their forums filled with people who really need different anti-aliasing settings for a single app?
- Re tabs in title bar: I've never heard window chrome be referred to as "caption".
> It is non-standard so that's why I think it is sensible that it isn't enabled by default.
Word, Edge and Explorer all put useful stuff in the title bar. Seems pretty standard to me.
> I'm arguing that the UX is top notch for it's intended audience.
I understand. I'm arguing it makes decisions that UX research either already has or would prove to be objectively poor for all users.
Thanks re: putting tabs in the title bar!
ConEmu likes to do this cute thing where it stops accepting key presses. And with the all the options it has, "starting a new terminal in the directory of the previous" is nowhere to be found.
But still, it's probably the best on Windows if you want tabs.
We're working to fix that, but we have to clean things up a little first. Bear with us.
You'd either get a Microsoft Word equivalent of a console window in that case, since everyone has a different set of features they consider essential, or the Notepad equivalent (more likely). A tool's value doesn't necessarily increase with more features and features are never cheap (in Windows, at least, where there are documentation, translation, configuration, group policy, and other concerns).
Tabbed console windows exist as 3rd-party applications already, seemingly with minor problems for one user or another, but I'd argue those problems are easier to rectify than for MS to develop yet another alternative that people grumble about even more because it doesn't contain their own personal pet feature.
What I mean when I write 'clean and fully featured' is: a console, tabs, a nice scroll buffer, working escape sequences, suppressing the bell. That's about it.
This is 1000x less features than ConEmu - I don't care about a new exciting way to set terminal variables, or integration with a file manager nobody uses, or support for a bitmap font format, or per-app antialiasing settings. Or various silly extras the other terminals add - I don't want a new way to do Unix on Windows, I don't want a new SSH client this isn't as good as openssh, I don't want a new windowing system.
I'm suggesting EXACTLY something like notepad.
Do 1000x less things, and do the remainder well.
> I'd argue those problems are easier to rectify than for MS to develop yet another alternative
Just add tabs to the console app as suggested. Or use whatever Edge uses for window chrome and shove the console app in there rather than html.
I wonder if an MS port/fork/patch-set contribution to putty might not be the best way to a great windows console host. At least until there's a native port of libvt.
Putty gets a lot of the console handling right - while win64/32 openssh is pretty outdated and lagging as a ssh client - I find it's preferable to run a recent full openssh under wsl to using openssh on Windows over putty.
As for console for Windows - I'm currently using conemu - considering moving to putty, but haven't quite figured out if it makes sense as a local powershell (and ipython) host...
It has the added benefit of you being able to pick the terminal to spin up, and whether you want Administrator mode or not, on every new tab, so you can be working in a bash tab and pop a new Admin cmd tab to update packages using your Windows manager.
We're working hard on that architecture stuff now, because we want tabs just as bad as the community.
If this is more than could be enumerated in an HN comment, I'd love to have a blog post about it. This stuff is fascinating.
And, no, simply rewriting the Console is not an option: Entire businesses' core systems depend on the Console, its specific behaviors, and even its bugs.
If we break existing behaviors we get to hear about who we've broken very, VERY quickly ;)
YES ... one day ;)
We're keen to figure out a decent tab story for the console, and the feature ask is on our backlog, but we're currently fully booked completing some important internal re-factoring, after which we'll be able to return to working on important asks like this.
FWIW, we're currently giving the Windows Console its biggest overhaul in > 30 years!! We're re-factoring and modernizing many of the Console's core internals.
We'll be writing-up the why's and wherefores of what we're up to in a couple of months.
Stay tuned on our blog (https://blogs.msdn.microsoft.com/commandline) and follow me on Twitter (https://twitter.com/richturn_ms) for news, udpates, and info.
I'm yet to try it out, but I wonder if the problems with editing files in the linux filesystem[0] is going to be an issue with this?
[0]: https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-n...
That was the main tripping point for me last time I tried out the WSL workflow. Mainly just because a bunch of files in our repo were apparently named in an ntfs unfriendly manner, so when I tried to merge etc. the repo would get corrupted.
Don't assume that just because the post hasn't been updated in a couple of months that it's somehow been magically "fixed" - it hasn't. In fact, its actually a really tricky problem to solve, and it'll take some time, a great deal of care, and some very well thought-out engineering before we arrive at a fix!
If/when we do fix the underlying issues we'll update this post and publish a new post announcing that the coast is clear ... until then, DO NOT CREATE/MODIFY THE LINUX FILESYSTEM USING WINDOWS TOOLS.
Thanks.
I remember the NT POSIX subsystem, which was a bit of a joke. It was badly limited and just seemed to be a box ticking exercise to get past some government requirements (disclaimer: I don't actually know if that's true). Whatever the reason, we ended up having to port our POSIX software to NT because customers insisted it was POSIX complient. I did resent MS for the mess we got into.
I do believe MS has changed. They don't seem to be the conniving organisation they once were, but what does WSL bring to Windows?
Perhaps, they are just accepting that there is something inevitable about all that Linux software that is available out there, and Linux developers could now be supporting Windows with no actual effort. After all Apple have saved themselves a load of effort by using Netbsd. However, something makes me wary. Could we be looking at an attempt to replace the Linux kernal on the servers of the world?
Windows 10 is the last version of Windows that Microsoft is making. It will be continuously updated instead of new versions being released.
http://www.theverge.com/2015/5/7/8568473/windows-10-last-ver...
Although I don't see a reason why NT should be inferior to Linux from Microsoft's perspective.
MS/PC-DOS, and DR-DOS, were not just "a bunch of code" and had a definite structure when it came to operating system design. They comprised the basic disc operating system, the basic input/output system (incorporating built-in and loadable device drivers), the command processor, and the housekeeping utilities.
* https://superuser.com/a/329479
The kernel of (386 Enhanced Mode) DOS+Windows analogous to the Windows NT kernel being discussed here is the VMM and the VxDs, with krnl386.exe as a distinguished Extended DOS program running in the distinguished system VM.
MS already has a Windows subsystem for Linux (they are using it in the MSSQL Linux port).
One reason why it was so easy for Linux developers to switch to OSX was that they had a mostly-compatible shell environment.
That's far too optimistic.
And since devs tend to overlook how "civilians" experience computing, (when's the last time you turned off your ad blocker?) if devs receive a non-creepy version of Windows, that'll be that many fewer influential people trying to hold MS's feet to the fire wrt privacy.
Apple has been losing their darling reputation among developers, and I think MS sees an opportunity to bring a lot of people back over who might otherwise try to make a go of Linux. If they can offer a plausible story for developing and deploying applications from windows I think it would drive more business in the cloud and enterprise areas; at the same time having more developers around on the platform will continue to ensure that they have the software to keep consumers from migrating to iOS/Android/ChromeOS type devices.
What I don't understand is why Canonical thought that shrinking their user base would be good for their business.
As developers, we're all enthusiasts of the WSL and how we don't need to dual boot, run VMs etc. any more. But in the process, we may end up giving less love to our once beloved DEs. This in turn creates a negative feedback for Linux desktop adoption. Also, less bare-metal installs means less bugs discovered and ironed out in the kernel too, less incentives for developers to release drivers, etc. so in the long run it's going to hurt Linux much more.
The only user base that shrinks is the Linux Kernel user base; Ubuntu and Linux are two separate concepts, and WSL demonstrates that they are in fact fully separable.
I don't think this business model will last much longer, though ;-)
I think this ex-Microsoft employee might disagree with you. https://www.youtube.com/watch?v=wPFbAqICUJo
1. In the Terms & Conditions, Microsoft claims they get your IMEI number from mobile connect devices as part of their telemetry and then go on to say it's not PII (Personally Identifiable). Jerry explains how this is not true and explains how Microsoft through corporate partnerships can eventually link your IMEI data back to logs previously collected.
2. Jerry explains that there are two levels in the new Windows Creator program: A basic level and another, I forget what he called it, more verbose level. Jerry explains that 90% of the telementry data you might think is in the more verbose level is collected at the basic level. Kind of a moot point.
3. If you have turned off telemetry collecting features such as cortana and edge, by upgrading to Windows10 creator, these features are re-enabled and Microsoft says this is a bug but Jerry claims it's intentional.
These were the salient points I recall from the video. If you get a chance to view, I suggest giving it a watch. It's interesting.
I know this because until I returned to Microsoft last year ... to help modernize the Windows Console, and deliver Bash on Windows ... I too was an ex-Microsoftie having left the company in 2010 after 10 years as an MSFT employee.
This company has changed and improved A LOT during my 6 year absence and, while yes, we have a lot yet to improve, I can attest that our intentions are genuine, credible and increasingly transparent, to the point that we recently published details on the telemetry that Windows collects and aggregates (https://arstechnica.com/information-technology/2017/04/micro...) and we even provide a site where you can go and manage/clear your privacy data (https://account.microsoft.com/privacy/)!
As a general rule, businesses will play nice when they have to (because of competition, public opinion, or government regulation), and they'll be ruthless where they can get away with it (due to monopoly status, high barriers of entry, poor regulation, etc.).
If you believe anything about a company, believe that. No company is fundamentally good or evil.
Now... corporations do have internal cultural that biases their ethical decision-making (positively or negatively) and various factors (inertia, founder effect) which slow down the rate at which they adapt their ethics to a new set of market/regulatory conditions. So perhaps you can trust/predict a particular company for the short-term.
They're trying to prevent Windows from becoming the COBOL of operating systems.
I've been using WSL for the last year now on my Surface Pro 4, and it has been nothing short of fantastic. This bridges a HUGE gap that made the MacBook attractive.
Windows didn't have a terminal emulator until recently anyway, as Windows console applications use the console APIs to change cursor position, color, etc. instead of having that API as part of the text stream that's output by applications.
Well, actually....Hyperterminal :)
/gets coat.
Windows has always been such a pain in the ass with regard to symlinks (my revision control workflow for big projects spread across multiple repos always includes symlinks). So, this is cool.
I have been mostly a Linux user for quite some time - at least on my own computer, clients always have Windows. But this year I bought a Surface Pro as a secondary device.
I first evaluated WSL and really liked it, but I switched to Hyper+Git Bash because networking in node.js was not working properly, and because I could not start Windows programs from the command line.
Now, if both problems are really fixed now, I guess I will switch back to WSL, and maybe uninstall Hyper+Git Bash later (given that I do not find any other show stoppers)...
The not searching the current directory is well known in the Unix and Linux world; and to be fair so too is the idea that if the filename of one's executable Perl script ends in .pl, or the filename of one's executable shell script ends in .sh, then the .pl and the .sh have to be explicit in the command name that one types. The idea that one can run notepad.exe with just notepad comes very much from the DOS and Windows world, here.
The Windows NT POSIX Subsystem actually provided a whole bunch of shims so that one could run various Win32 housekeeping utilities from a POSIX shell without explicitly adding ".exe", and a Korn shell adjustment to allow case-insensitive searches for Win32 commands.
And since USB ports aren't mapped into WSL, I have to use a Windows program to talk to them.
Besides this hiccup, everything else seems to work great.
Wondering why such a disclaimer? Ubuntu apt upgrades are reliable. Or is it related to WSL? Anyway good job WSL team.
The 14.04 version which is supported until 2019 still has the bug that it won't clear out old kernels after upgrading them. So if you don't look into your /boot partition now and then it fills up and breaks your installation.
* https://news.ycombinator.com/item?id=14002821
Of course, this is an Ubuntu upgrade problem relating to Linux. It is specifically about kernel image files. So it has very little application to the Windows NT Linux Subsystem, which as we know uses the Windows NT kernel.
Yeah, I see your point.
That has never ever worked for me until the 7 -> 10 upgrade: 95 -> 98, 98 -> 2k, 2k -> XP and XP -> 7 all failed miserably and required installing from scratch.
And even 7 -> 10 failed without any helpful information= the first few times I tried it (unlike OSX where I've been upgrading and migrating the same system for more than 10 years across multiple machines and versions).
Are there any plans to support GNU Readline shortcuts such as history searching with Ctrl-R directly in the Windows Console?
I'm mostly using WSL to run the PostgreSQL CLI with the standard keyboard behavior. It would be nice to be able to do that without having to install WSL.
One can of course write command interpreters that have their own editing systems, rather than use the one provided by the console. JP Software has done this for many years.
* https://jpsoft.com/help/index.htm?cmdhist.htm
But tofflos is asking about improving the one that is in the console.
rtt min/avg/max/mdev = 0.098/0.109/0.131/0.012 ms
As an emacs user, this single issue has been the show-stopper that prevented me from investing in bash on windows, even though I would like to.
[1] https://superuser.com/questions/1088250/windows-10-linux-bas...
Can anyone verify if this means you can run the Docker for Windows client (the docker and docker-compose executables, not the engine) from within WSL, including from shell scripts?
If so, I can't wait to try it out, since that's about the last thing preventing me from using my usual Linux/MacOS dev workflow in Windows!
Unfortunately I'm running an Enterprise version of Windows, and the upgrade tool doesn't support Enterprise yet, so I'll probably have to wait for it to come through Windows Update.
It allows you to run a command in the Windows prompt to 'link' a Linux command to a Windows one, allowing you to run the Windows command to run the Linux command (if that makes sense; the GIF in the Readme is probably better at explaining).
It's written in Bash and Batch so doesn't require external dependencies.
C:\> doskey ls=bash.exe -c "ls $*"
C:\> ls /
bin cache dev home lib media opt root sbin srv tmp var
boot data etc init lib64 mnt proc run snap sys usrNow that there is 24-bit color, is there actually a reasonable way to change the colorscheme, or are you still stuck with the same UI?
As far as I can tell, this is the first major overhaul of CMD. Full stop. We've been waiting.
Bash on Windows has existed for decades now, through Cygwin. https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Fba...
Trying to reduce the entire GNU/Linux ecosystem to "Bash" is insulting to the community you are trying to appeal to:
Linux is an immensely large and complex project, which has millions of lines of code. The GNU part of GNU/Linux has a couple of more millions of lines of code as well. Bash is small in comparison.
Take WSL for example, I'm sure their motives are just to encourage people away from Linux and OSX for sysadmin and dev workstations. I can see that strategy working for many people too. But at least with WSL, if they do decide to cripple it once they have the customer base then it's pretty trivial for users to switch away again (which was less doable with many of the other tech they've dominated the market place with).
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.
I'm also not convinced they've changed at all when I see what they've done to things like skype, where they have somewhat of a monopoly (thanks to office).
Now that they're embracing the typical Linux userland, I can't help but ponder if they'll try shifting to the extend+extinguish part later on. I guess old habits die hard, especially when you got burnt multiple times already, although I'm not cynical enough to think this would be all planned beforehand but more like at some point some exec would notice this as a strategic opportunity to seize.
That said they're certainly winning some Linux users back, and if anything, this may even help in getting some Windows people used to Unix and Bash, reducing the gap for them to try their hand at some Linux distro. All in all, cross-pollination is good both ways.
https://en.wikipedia.org/wiki/Standardization_of_Office_Open...
I also think their current strategy could be the one you describe. We're at the Embrace phase. It's not sure that Extend will follow but I wonder what it could look like. Maybe it will be something convenient you can do in Linux only if you're running it inside WSL. Given how Linux is used it should be something server side, Internet facing (no Active Directory, Exchange, SQL Server, those are Windows markets anyway). A bonus would be some compatibility tool to do that on native Linux too. If enough software is written to run for Linux+WSL and it gets deployed in production, then the Estinguish phase will be ready to kick in: deprecate the compatibility tool and hijack all the Linux market to Windows. The timescale for playing out these strategies is at least 10 years, so let's talk about it when approaching 2030.
If Microsoft is really thinking along those lines, a way it could fail is if Linux expands to other markets. That would make it hard to Extend to most of the use cases.
However what WSL is doing it to make those MacOS users that deploy to Linux consider moving back to Windows because there is a Linux subsystem there too. Actually, a real Linux instead of a look alike.
By the way: why did they named it Windows Subsystem for Linux instead of Linux Subsystem for Windows? It's Linux running inside Windows, not the other way around.
Microsoft's revenue from patents collected from companies such as Samsung and HTC is like $1 billion.
I see things they could do with a WSL+Azure integration but I don't want to give them the idea :-) Anyway, they are collectively smarter than me (and more focused on their businesses) so they'll already thought about that for sure. That's why I'm somewhat worried.
Naming it the other way around ie Linux for Windows would imply that the Linux kernel is involved which is actually not the case at all.
If I say Firefox for Windows, I'm thinking the Windows kernel is involved, and that the application(Firefox) will be running on Windows.
So calling something $x for Linux, when it's actually running on Windows makes no sense.
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.
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.
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.
C:\Windows\System32\bash.exe
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.
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/
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.
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.
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.
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.
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.
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.
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.
I guess we just have different priorities.
So no. I disagree that bash was a major final milestone.
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.
bash is GNU bash, on every operating system. A Unix shell. It has been the same since 1989.
The authority on what GNU bash is and what it is not is GNU, not Microsoft.
Then GNU bash is not required to run stuff under Linux. There are system calls to run programs. e.g: http://man7.org/linux/man-pages/man2/execve.2.html
Many distros do not even ship with GNU bash.
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 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.
Fair enough?
> 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.
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
root@Skully:~# fish
Welcome to fish, the friendly interactive shell
Type help for instructions on how to use fish
The following link makes the distinction clear:
https://msdn.microsoft.com/en-us/commandline/wsl/faq
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."
Thanks.
Whilst I really appreciate some of the things Microsoft is open sourcing I also find their current telemetry and privacy stance troubling.
For several years it was the best browser available. Invented a lot of things, including DOM and XMLHttpRequest.
> ActiveX / Silverlight and other MS web lockins
Everybody did that. Have you forgot internet with A/V streaming locked to RealNetworks, and vector graphics and animation locked to Macromedia?
Yes, they made it just good enough to kill the competition, and then let it stagnate.
Real Player and Flash were cross platform (albeit Flash outside of Windows was and still is garbage). ActiveX was Internet Explorer on Windows desktop only and Silverlight was only partially cross platform (parts of Silverlight was ported to OSX and only OSX so it's a bit of a stretch to even compliment Silverlight for being "partially" cross platform).
Really the awkwardness of the naming is more of a testament to the power of scripting on Unix-like OSs (eg how scripting is a first class citizen and how most of the ecosystem is modelled around CLI, and thus scripting, support) more than it is an insult.
As for cygwin, that was simply terrible. MinGW was better but WSL is already better than both and it's still a long way from feature parity.
Of course some MS haters will always find a way to fault this, and i can sympathise with that point too because I've been burnt my MS too and thus, as much as i found WSL to be a much needed addition to Windows, I'm still going to stick with Linux as my primary OS. However personal biases of Windows aside, even i have to admit that WSL is a pretty good feature.
I think Cygwin was less convenient than an ABI such as WSL, but by no means "terrible". Cygwin was initially released around 1995, it served a valuable purpose before the first VM products came along.
Bash is the default shell. It's also the generic command you run to launch the WSL environment.
While the multiple names for the same subsystem are a little nebulous, Bash is far from being as confusing or misleading as you're attempting to portray.
Also, editing your original snide grammar dismissal due to the downvotes it received isn't appreciated. That's deceptive at best. Either own your bad behavior or apologize for it, but don't edit it and pretend like you were being rational.
https://github.com/Microsoft/BashOnWindows/issues/846
Then, we both edited our replies. He corrected his typo, I removed my remark about the typo. At no moment there was any insult given, and the replier did not take offense.
No need for insulting.
Cygwin enabled me to stick with Windows since 2003 or so, and have the same environment on Windows, Linux and OS X. The command line is where I spend most of my time, and apart from Firefox every daily app I use on Windows is a cygwin app, from tmux through to Emacs.
Just run the setup.exe, click through the 5-10 pages and that's about it.
To update package, just run the setup.exe, click through the 5-10 pages and that's about it :)
Or use this: https://github.com/transcode-open/apt-cyg (I haven't needed so far, but I've read good reviews about it)
Regarding "crash prone", it used to be a bit unstable in the early days of XP, but almost all of them were due to failed updates. And that's where you needed to know a bit of magic, the "rebaseall" thing mentioned by barrkel. I haven't had to do that in a long time.
It's a lot more solid that people think it is. I wouldn't run production servers with it (even though I know folks that do...), but for desktop use it's quite robust.
apt-cyg is pretty good though. However that didn't always work. But in fairness to apt-cyg this was about 18 months ago and I believe it was still marked as experimental at that time.
As for crashing, the issues I had last year were with the ssh-agent hanging. The only remedy was killing them from Windows then restarting Cygwin. Killing the process from within Cygwin (ie using `kill`) and then restarting the daemon weirdly left it hanging still. I've not used Cygwin since to see if that issue had been fixed.
Cygwin is one of those products that when it works, it works really well. But when it doesn't it can be hateful. Sadly I've run into a few edge cases that have left me with a sour taste after using it.
I will note, that Microsoft, when referring to their WSL component, never refers to it as Bash - and always "Bash/WSL" - though it's dubious as to whether that's even meaningful (unless they are trying to say once you start WSL you can run bash. But you can also run fish. Or any other shell.