Windows Console folk: any chance of tabs in the official terminal?
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.
Edit for folks having trouble understanding: the post you're replying to literally mentions two of the best tabbed terminals for Windows. That's not the problem.
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.
> a clean, fully featured tabbed terminal, included in Windows
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.
> A tool's value doesn't necessarily increase with more features and features are never cheap
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.
> 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.
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...
Out of curiosity, what tabbed terminals on other platforms would you consider to be significantly better than ConEmu/Hyper? (I've never actually used any GUI platform other than Windows for any length of time, so I would be interested in seeing what other people do use.)
Apple Terminal, iTerm, gnome-terminal, konsole. I can't really name one worse than ConEmu.
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.
To be fair to ConEmu, Cmder, Hyper, and all the other Windows terminals/consoles, we don't currently provide a way for them to truly become genuine consoles.
We're working to fix that, but we have to clean things up a little first. Bear with us.
1. I understand the developer, I don't see the issue (wouldn't mind it being configurable but if it is the only thing that breaks XP support I can understand it).
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.
1. Color contrast and it's ability to help users distinguish items from each other is a very well researched objective thing. Your personal experience doesn't overturn it as a concept, or make it easier for anyone else to find to find the active terminal.
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.
1. I'm not arguing that it is. There are more cues than color contrast before taking into account your mental state. As said, I wouldn't mind it being configurable but I understand the reluctance to do it if it breaks XP support.
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.
1. You mentioned that you personally didn't have a problem with low contrast. If it's not an argument I'm not sure why you'd mention it. I can't find the active tab easily, but that's irrelevant too: we have long established research on contrast helping people find stuff, and measurably low contrast in ConEmu.
> 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.
I didn't have a problem with it as a whole. I never understood the tight coupling with FAR either, but it hasn't distracted me either. It takes me literally no time at all to change the font so why optimize for that further? It's literally the first option in the main section. And arguably changing the anti-aliasing is about as important as the font and should most definitely be right beside it as they are related.
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.
Basically every release we look at if it's possible to get us to tabs in that release window. If it's not, then usually we'll do some architectural work to get us closer to that goal. Part of the problem is that most of the codebase is from 1993, so there's a LOT of architectural work between where we were when Windows 10 first launched, and proper tab support.
We're working hard on that architecture stuff now, because we want tabs just as bad as the community.
I'm curious: could you explain briefly why tabs are so difficult? I would think that every tab could have its own process space for its own shell, but obviously there's something big I'm missing here.
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.
Hi Zadjii I really appreciate you answering. If it's a 25 year old code base, wouldn't a rewrite be easier? What's the process of taking something like that and trying to modernize it?
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 ;)
What I do is start sshd in WSL then ssh to <username>@localhost from mobaxterm which is quite a nice (tabbed) terminal app. Works a treat, even with the free edition.
MobaXterm is awesome. Except the performance is just crap. It's noticeably laggy doing basic things like opening tabs and stuff. Anytime it has to redraw/relayout it's just slow. And if you use RDP, the CPU just burns even when idle.
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:
Can't say I've ever noticed any difference, even over the VPN to our stuff in the DC. Even serious vim editing sessions on a remote box with tmux feel just as instant as when I'm working on my local Fedora/KDE h/w PC in Konsole.
This is the biggest blocker, in my opinion. WSL is nice and all, but as long as cmd.exe/conhost.exe is the only official terminal, it'll never feel just right. If only they had an API so you could run Mintty without the wslbridge kludge.
Hi - PM for Windows Console & Bash on Windows here.
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.
Cmder is ConEmu, just with a bunch of other stuff added to the download, including:
- 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.
> > - 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.
> It lets you create tabs, Ctrl+c - Ctrl+v, and works for Cmd, PowerShell, and Bash
I really support ConsoleZ. The UI is sadly still a little bulky, but you can do a good bit of configuration for hotkeys. The tabbing is nice, and it also to my memory has panes, without ConEmu's weird hidden tab system for them.
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.
I second this. I use ConsoleZ daily as my main shell for cmd and for powershell. It does everything I need it to do, I can dial down the UI to the absolute bare minimum, it's fast and responsive, and it's highly customizable.
Mintty is what I'm using for it. You don't have to install the entirety of Cygwin and its unix-like tools to use it, there's smaller bundles specifically made for WSL like this one: https://github.com/mintty/wsltty
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! :)
The inotify implementation looks very promising! Editing source files in a Windows-native IDE and having changes picked up by, say, node.js is a great workflow.
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?
Wait so you CAN edit linux filesystem files with windows tools now?
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.
The impression I get is that whether or not it works depends on the particular Windows tool. The guidance and the blog post not to do it seems to be the best general advice. My understanding is that the unspoken assumption between the lines is that you may be able to find Windows tools that are well-behaved and will not corrupt things, but don't expect to find that many because alternate streams and complicated metadata are not things most Windows tool developers have had need to understand/deal with/round-trip to date.
So what is the end game with WSL? What is it that MS is actually trying to do?
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?
I suspect that this is a side effect of work they are doing trying to build up their capabilities with Azure. I think the long game is to try to support docker containers that are built against Linux natively on Windows. The other interpretation is still in line with the move toward containerized services: I think they want to make it easier to build a containerized app on windows and deploy it on k8s/docker swarm/etc.
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.
They want you not to install Linux, but keep using Windows. That way, apart from using their OS, you may end up using the rest of Microsoft software: Edge, Office, Outlook, OneDrive, etc. That wouldn't happen if you used Ubuntu.
What I don't understand is why Canonical thought that shrinking their user base would be good for their business.
In the long run, Canonical might have been the trojan horse Microsoft needed to demolish Linux from within.
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.
This can go the other way as well. If developers can target WSL and run on both Linux and Windows it increases their user base. This could end up making it easier for users to move away from Windows since one of the big hurdles is software compatibility.
If it is a Trojan horse, it does seem to be a partnered one that works both ways. WSL is the easiest "Hey Developers, Try Ubuntu" experience Canonical could hope for. No virtual machines to wrestle, no boot CDs to awkwardly try to boot on machines that no longer have CD-ROMs: push a couple buttons, install an app.
This increases their user base. Every time you install WSL & Bash on Ubuntu on Windows, you are getting a full Ubuntu distribution.
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.
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.
I see a free or nearly free "developer edition" of Windows 10 incoming. It won't have some of the enterprise-y features (bloat) of existing enterprise editions, but it will be capable, feature-rich, free (maybe you'll have to somehow demonstrate that you're a developer) - and most importantly it will be free of the creepy shit. And then they'll be well positioned to drink Apple's milkshake, as far as developer-mindshare.
Why? Developers are a small minority of MS's users, and MS gains way more in terms of adoption and opinion-shaping from being on the good side of devs than they gain from the (unusual, unrepresentative) data that comes from spying on them.
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.
sure. The guy in the video is a popular youtube personality; his name is Jerry Berg. He is an ex-Microsoft employee who worked on Windows and had access to Microsoft's internal SQL servers used to collect problem reports. He makes a few points in the video.
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.
Although he makes some good points, I would encourage some healthy skepticism over claims and statements made by ex-Microsoft employees about a company that has changed significantly in the 3 years since he was sadly laid-off.
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/)!
Has Microsoft made any inroads into the embedded space? Maybe embracing Linux is part of a long term strategy to becoming a player in the IoT/embedded space.
My theory is that the next version of Windows is going to use the Linux kernel. They can keep Windows 10 going for a few years yet (maybe up to 5?). That will give them time to work on cross-platform .NET, so new development will be an easy switch, and good quality Win32 emulation, which will be built someway on the work done on Wine.
What do they have to gain using the Linux kernel? As WSL shows running Linux userland applications on the Windows kernel is perfectly feasible, however, running Windows applications on a Linux kernel (aside from GPL nightmares) is a different story. The two architectures are quite different, but NT was built from the start to support different 'personalities' (cf. the OS/2 and POSIX subsystems).
There is an ancient story about an old ship with all its parts replaced and the question was when does it stop being the old ship and become a new ship? If Windows has a Linux kernel, is it still Windows? I guess Windows is whatever Microsoft calls Windows?
DOS had no kernel - it was just a bunch of code that ran on top of a bunch of PC-compatible hardware. There was no separation between kernel-space and user-space.
You are applying an overly restrictive definition to something that is just the nut analogy, which is a vague analogy that does not imply "spaces".
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.
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.
Hats off to Rich, Russ, and the entire WSL team at Microsoft. Another excellent release. Your work here bringing Ubuntu and the open source world to the Windows ecosystem makes us very, VERY proud!
I have switched to WSL pretty exactly a month ago after using solely Ubuntu for about 6 years.
So far it works like a charm. The only small problem i have had was the network interface problem with nodejs (which should be solved with the new WSL). But that can be circumvented by simply running node.exe instead.
The reason for the switch was: windows in great for everything UI, bash is great for everything development.
WOW. cmd can actually parse escape codes now AND run Linux scripts! What a time to be alive.
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.
cmd has nothing to do with it. Just as bash has nothing to do with parsing terminal escape sequences. It's a shell. On Unix-likes a terminal or ~ emulator will handle those escape sequences, on Windows it's the console (provided by conhost). What program you run in the console (or terminal) is completely irrelevant.
No, conhost.exe is (since Vista, prior to that it was a part of csrss). cmd.exe is simply the default command-line shell. To disprove your guess here, you can just observe the processes existing when running console applications. There's one conhost for each console window, but unless you run cmd, there'll be no cmd instances.
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.
Oh, fair point. I forgot about that. But it was never intended to be used with local console application ;-) (and ANSI.SYS goes back even further, I guess).
It's funny that it took so long to re-implement escape codes, while they already had support for escape codes in DOS sessions via ANSI.SYS since MS-DOS 2.0 :) https://en.wikipedia.org/wiki/ANSI.SYS
A more thoughtful critique is that it is sad that it took so long to make the console support the POSIX General Terminal Interface and terminal control codes, considering that the Windows NT Subsystem for Unix Applications (a.k.a. Interix) already had all of this working and Microsoft owned the code.
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.
Ok, this is awesome, if everything works as advertised.
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)...
What's interesting about the Windows approach, (and I realize you know this) is you don't cease being a Linux user - they are effectively running a instance of Ubuntu (previously 14.04, now 16.04) - so most of the linux fu you are used to, translates directly to WSL. The Anniversary update was intriguing, but there were little nits in things like networking, file/process access between windows/linux environments, that made it just as easy (for me) to simply run a VM instance. Creators Update looks like it's resolved pretty much 100% of the top issues on my nit list - it's going to be really interesting to see I switch my workflow from VMs to working with WSL.
Unfortunately, I found Windows command-line interop isn't as useful as I had hoped. You can start Windows executables, but you can't kill them: ctrl-c gets you your shell back, but the executable is still running in the background, headless. See: https://github.com/Microsoft/BashOnWindows/issues/1614
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.
I recently tried starting Windows CLI programs from within bash and it worked just fine, but you have to specify the entire filename, like "./notepad.exe".
Actually, given what Osiris appears to be getting at, it is because Unix shells in general have no notion of a PATHEXT system, and so do not go around tacking .COM, .CMD, .EXE, and the like onto the ends of command names.
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.
Just to note that this (to run scripts/executables you must specify the cwd in the cli invocation)is also the case for PowerShell. So, not unknown in the Windows world.
I've definitely had issues doing an upgrade on a real Ubuntu installation. Years ago I needed to update a more or less clean install of Ubuntu Desktop. It managed to completely break Gnome somehow (This was before Unity). I'm guessing things are better now and that the server distribution is better for this but I could see complications happening.
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.
Xe could hyperlink you to Dustin Kirkland's call for feedback here on Hacker News only a short while ago, where this subject came up several times. This is a well-known Ubuntu problem, and M. Kirkland xyrself said that taking purge-old-kernels out of the byobu package and putting it somewhere more obvious was a good idea.
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.
After a major change of desktop like a switch from gnome 2 to unity or gnome 3, it is not surprising that users may need to refresh their configuration files. I am doing dist-upgrade since 2009. They were all smooth except the upgrade to 16.04 (lost of network and a couple of small issues still not fixed).
After 15 years with Ubuntu, I've only ever seen problems when people switched default Ubuntu packages with their own (back in the day it was often beryl, compiz or drivers).
I have actual machines that I was able to flawlessly upgrade from 4.10 to 17.04. Can't say that about Windows. Though I did actually know what I shouldn't mess with if I want the upgrade to go through (or fix before).
I hit problems with the desktop environment on both 8->10 and 10->12, then gave up trying to upgrade Ubuntu in-place. Debian has been absolutely fine, though.
> Because you can upgrade from windows 3.11 all the way to 10
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.
If you run PowerShell, then PSReadline will give you a similar editing experience in PowerShell. I believe that PSReadline is built into the PowerShell that's part of Windows 10.
In the meantime, clink (https://github.com/mridgers/clink) works well. It stays out of your way, and isn't clunky like the full shell replacements. I had even forgotten that cmd.exe doesn't do ctrl-r out of the box.
I would say that's not very high on our backlog. That sounds like something that we'd need to implement directly in cmd.exe (the shell), not conhost.exe (the terminal) and changing cmd's behavior is VERY HARD to do without somehow breaking the world.
Actually, command line editing and history recall for such programs is in the console. That's where the actual mechanism of DOSKEY lives. That's where history recall lives, governed by SetConsoleHistoryInfo().
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.
Please disable file notified hooks for files in WSL. One of the big reasons why I prefer to work on linux in office like environments is because Symantec etc heavily hook file IO on windows making things like compilation / checkout very slow compared to linux. When WSL came out I was hoping it would sidestep the slow hooked IO problem in windows but some investigation revealed that file modified / created hooks are still triggered for files in WSL. Any change of this being removed?
The problem is the antivirus software, not the kernel features that the AV software is using. I can't imagine that MS would cripple their OS just so that someone who mostly uses WSL can bypass the AV software that their sadistic IT people force them to use. The only solution there is to just not take jobs where someone can force you to use such machines.
Try creating a lot of small files, even microsofts own antivirus (which seems to be the most light weight of the anti virus alternatives) adds significant overhead. I know its not a simple problem, but since most large repos contain a lot of small files this does create a negative "workstation os" image for windows in my mind.
For me Microsoft has realized that their profit on cloud (where Linux is dominant) can be significantly higher then licensing Windows, so they are pushing for a better Linux experience on the user desktop and we will see in a couple of years the Microsoft Linux Server (maybe they will buy Cannonical for that ?).
> In Windows 10 Creators Update, you can now launch Windows apps & tools from within Bash …
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.
I think it's fine as is just so you even know/remember where you're running that command from. What's not exactly ideal is completely blurring the lines between both kernel syscalls.
The windows terminal is utter garbage compared to linux ones, but to be fair the linux ones have had rather longer to hone their products. Hopefully the Microsoft guys will keep on improving!
Wasn't mouse support in the console for decades as well? At least it has worked in Far for ages. Or is just the integration with Linux console applications new?
The console only recently (<2 years I think) learned to speak ANSI/xterm-ish escapes, Linux mouse support requires quite a few of those and doubtlessly the model differs sufficiently from however the NT console API mouse worked to require effort to support
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.
Your entry point to WSL is bash and while you may be able to compile and install other shells, calling it "bash" isn't too far from the truth.
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.
Cygwin isn't terrible; it's much better than mingw for the simple reason that it provides an environment much closer to POSIX. Its biggest problem is forking speed. I don't think it has a second big problem; the next biggest is the crashes you get if you do partial updates and don't rebaseall.
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.
Opinions are bound to differ so I do appreciate your point. I personally found Cygwin a nightmare to install, a nightmare to maintain, and a crash prone on every system I used it on since XP. While you're right that MinGW is only a subset, it did address the issues I raised with Cygwin which made it a better default environment for me most of the time; falling back to Cygwin on those occasions MinGW couldn't fulfil. But frankly I generally try to avoid Windows where-ever possible so it's possible you have more experience with Cygwin than I.
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.
We can argue about whether "nightmare" is overstating the problem but let's be honest that it's easily more than just "a bit annoying". The installer took an hour on one system and the options in those 5-10 pages are far from user friendly. Sure it's stuff I can manage being a seasoned Linux sysadmin but frankly I've found installing ArchLinux (with it's deliberately anti-user approach) easier; never mind your more "mainstream" platforms like CentOS and Debian.
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.
For problematic processes, I use kill -W -- that uses the TerminateProcess Win32 API, rather than Cygwin's POSIX implementation. I also use it to kill things like the Windows Update full-screen overlay on Windows 10.
Whups. It's ps -W to find PIDs for Windows processes, and kill -f to use TerminateProcess. Got the two flags confused; you usually use one with the other.
The confusion is that the "Bash.exe" that you run to initiate the WSL subsystem is entirely unrelated to the bash, the shell that gets executed in that subsystem. In the cygwin scenario, when you ran bash.exe - you really are running the bash shell.
EDIT: Your choice of shell can be something different than bash... you opt to use zsh or fish or another shell. Therefore saying "Bash for Windows" can be objectively said to be unnecessarily confusing/inaccurate.
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.
>EDIT: Your choice of shell can be something different than >bash...
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.
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.
Microsoft adds this amazing set of features and the only response you have is "your name is insulting the people you're trying to appeal to"? "Trying"? As if they're failing? Do you know how much people love this project?
A lot of resistance some will have to WSL will be old battle scars from Microsofts past behaviour. Microsoft have done a lot over the years to troll the Linux community. While many of the younger HN members will be familiar with the "new open source Microsoft" some of us oldies have had to endure IE breaking the web plus ActiveX / Silverlight and other MS web lockins. Comments like "open source is communism" from top MS execs. Fragmentation of Java (which eventually spawned into .NET but there were years of pain before .NET became a thing of beauty). To be honest more sins than i have time to list. So many of us are now cynical by default with regards to MS.
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.
> 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
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.
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.
It's named like this because it is a subsytem of the NT kernel (hence the Windows subsystem part) that implements Linux system calls to run Linux applications (hence the for Linux part).
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.
Also, they previously had a Subsystem for Unix (SFU/SUA), so they're being consistent with their naming. That was the old POSIX layer that included, IIRC, a shell script to wrap cl.exe to take gcc-like arguments, and you can get third-party compiled binaries of things like bash.
I'm not saying that those money are peanuts but it doesn't compare to what they were doing (are?) with software licenses. Maybe they plan to cannibalize the desktop with subscription services and Azure.
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.
> A lot of resistance some will have to WSL will be old battle scars from Microsofts past behaviour.
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).
Or more recently, Microsoft's refusal to remove "curl" from Powershell, where "curl" was an alias to a totally different Windows function that barely resembled curl.
IE4 was better than Netscape communicator but not significantly. Before (IE3 and below) things were a lot more even. However by IE4 MS had already won the browser wars. It was a fair while after that point when AJAX became a thing (and Netscape and Opera did support a competing API to XMLHttpRequest btw). The problem with IE was that it wasn't standards compliment, only ran on Windows desktop and Mac (even Windows CE didn't really have a decent working version of IE) and even with their lack of regard for the standards offer very little innovation compared to the 10 years they had leading the market. Think about how much the web advanced once Firefox and Chrome gained traction and how far behind IE quickly got left, then tell me that what Microsoft did for web was a positive thing.
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).
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.
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.
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.
For anybody comes to this thread late - partycoder is 100% correct. The Bash.exe component of Bash/WSL is entirely unrelated to the bash shell (that gets executed inside the WSL subsystem) - should have been named wsl.exe. Microsoft is just trying to ride (mostly successfully) for free on all of Bash's goodwill.
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.
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.