Slashdot Mirror
There's Bugs In The Windows 10 Implementation of Bash (altervista.org)
First-time submitter Big O Notation shares "an honest review about the new Ubuntu Bash" that shipped with the Windows 10 Anniversary Update. While it's still officially beta, most of the commands work as expected, and it includes popular programs like the Pico text editor. Here's some of the review's highlights:
Pros: You can also manage and manipulate other files inside your entire Hard Disk, even those outside of your Linux home directory.
Cons: Even if you chmod something properly, when you use ls -l the Bash would not show the correct permissions. [And] if you try to create a Folder in your Linux Home Directory by using the Windows GUI, it would be impossible to read and manage it. Don't try this at home.
Microsoft says they've included the Windows Subsystem for Linux primarily as "a tool for developers -- especially web developers and those who work on or with open source projects." One Scandinavian developer has even tried running X on Bash on Ubuntu on Windows, reporting success running simpler programs like xcalc and xclock, as well as Gnome Control Center and xeditor and SciTE. "Things start to fall apart if you try to get more ambitious, though."
Cons: Even if you chmod something properly, when you use ls -l the Bash would not show the correct permissions. [And] if you try to create a Folder in your Linux Home Directory by using the Windows GUI, it would be impossible to read and manage it. Don't try this at home.
Microsoft says they've included the Windows Subsystem for Linux primarily as "a tool for developers -- especially web developers and those who work on or with open source projects." One Scandinavian developer has even tried running X on Bash on Ubuntu on Windows, reporting success running simpler programs like xcalc and xclock, as well as Gnome Control Center and xeditor and SciTE. "Things start to fall apart if you try to get more ambitious, though."
That "review" is tiny and doesn't really tell you much. It doesn't even say what happens if you do mess with the Linux subsystem directories from Windows apart from "it would be impossible to read and manage it". Grats for random guy getting a ton of ad hits on a crappy 5 minute blog post. Woo.
So basically MS's Linux subsystem can't even do the job Cygwin does quite nicely? I think MS ought to go and read the code, learn some lessons and carry it back. It's not like you can't translate Unix permissions to Windows' permissions system and vice-versa, the code's even right there to read.
I've been using the UnxUtils since the Windows 2000 days, with utilities like grep, cut, sort, sed, etc running right inside the command prompt and useful on the entire system. Can't believe it's taken Microsoft this long to jump on board.
There is at least one post online floating around how to update to ubuntu 16. I dont know how much info there is about fixes in function, or consequences thereof.
Permissions will only work correctly within the linux filesystem. When you're accessing folders on the Windows side through bash, it does a necessarily-lossy mapping.
For now, it's still better to use Cygwin.
"First they came for the slanderers and i said nothing."
Version 701 of LTP on Windows 10 that contain 1904 tests:
701 tests skipped because of the configuration (features not supported).
374 tests return unexpected result.
Try it yourself.
That's a dumb heading: There's Bugs In The Windows 10 Implementation of Bash. where do you not find bugs?
That are plural. And a bug which is singular. A bug in bash is singular, indeed.
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
MS has stated that this is very new and very buggy but that they are working on it. It is not yet for public consumption. MS has been embracing Open source minus the extinguish part for some time now. Linux (okay so not the kernel but still) on Windows outside of a virtual machine is everything a lot of people have wanted but never thought would happen. Go watch some of the MS demo videos. As a Linux user since 1996, I can attest that there is absolutely nothing that will make the broader Linux crowd happy. Hence, most of the Linux crowd are not actual techies.
Brought to you by Carl's Junior.
I have no doubt that the integration between Windows and the Ubuntu environment is bad, particularly with regards to the permissions. The POSIX vs. Windows permissions models are most likely to interact badly. There isn't a lossless mapping between the two, so something is bound to be lost. That being said, this article is absolutely horrendous.
Example:
2. “sudo su” VS Windows
This useful commands doesn’t work in the Shell and if you try it you will, at first receive a command line error, and second you have to restart your terminal because the command “cd” starts to work in a random way causing path problem.
Well, no kidding. First off, anyone who uses ‘sudo su’ instead of ‘sudo -i’ or ‘sudo bash’ should cease writing technical articles. Then there is no justification for the expectation that both sudo and su will somehow work as expected. That's the very thing I'm not expecting to operate the way I'm used to, since it is not running on a Unix-like system.
But the absolutely best part is that the text of the whole article is completely devoid of any useful information. The quote above has the details and the grammar of the guy who calls your technical support guy and tells “my server don't work,” and refuses to give you any more details until you accidentally discover they don't have an account at your company, they don't have a server but a Facebook page, and their internet connection is presently not working.
As I would never used Ubuntu Bash for Windows, I would have been curious to see what permissions would ‘ls -l’ see after a chmod. That detail is somehow missing from the “article”, which is a series of complaints and vain praises like “grep works correctly”. Yay.
It doesn't seem like much of a surprise that starting a fight between POSIX and NT ACLs is going to end badly; but this 'review' fails pretty dramatically at answering the question of how much of a problem this is.
If you can't, in practice, let the Linux side touch the Windows side, or vice versa, lest ugly and inscrutable things happen, then you might as well just run a VM. If you can actually do a variety of interesting things across systems, so long as you avoid a few edge cases, that is potentially more useful.
Oh yes, it is so. That's what happens when GNU goes on a date with sleaze like Windows. It gets bugs.
I can't figure out any way to select, copy and paste text in a bash window. Quite a limitation for a shell.
ReactOS, OS2, Xenix, anybody?
I would definitely appreciate a Linux subsystem if I were forced to use Windows. But I'm not. So I'll just stick with Linux and run Windows apps in my "Windows subsystem" (Wine) in the rare occurrence where I would need or want to run such apps.
All in all, this is a good move and attempt by MS to regain some relevance. Unfortunately for them, it's been way too long since I've needed them.
GNU just penetrated the Microsoft womb?
I smell a dirty virgin hippy living in parents basement but trolling under bridge with open Google 5bucks wifi.
There's Bugs In The Windows 10
There are bugs in a beta? What a shock!
You're right, I wouldn't steal a car. But if it were possible, I sure as hell would download one!
The summary even states that Microsoft still officially consider it beta software. This is not even a v1.0 release.
What we are seeing here however is that even a large ship such as Microsoft can turn very slowly. This would have been unthinkable even 5 years ago - just think what it will be like in another 5 years...
Specialist Mac support for creative pros, Melbourne
I can't even get Emacs to suspend and then return to the foreground in WSL Bash/whatever. The terminal program inevitably seems to get confused, and things get borked.
The convenience of apt-get is outweighed by general unpredictability that is even worse than Cygwin.
Honestly, Windows 10 + WSL very nearly got me to buy a Windows laptop as my primary computer, but it just isn't there yet.
It runs Docker natively.
'nuff said.
That we are referring to bash as the problem when its actually tools not bash that is he is complaining about?
"There are"
"There's bugs" is something an illiterate baboon might write. /. editors should at least be able to handle proofing their god damned headlines.
I've just shit myself with surprise.
"Oh my God. This is terrible. This is the end of my Presidency. I'm fucked."; ~ Donald J. Trump
... so of course ls -l won't give an accurate answer. It's like asking "Siri, how can I get to the South Pole without crossing water?" It's not a question that even has an accurate answer.
We've known this since the days of PuTTY.
I must say that I'm completely underwhelmed by the reviewer's knowledge of his subject because ignoring bash itself, only two of the commands listed (cd and the two redirection commands, > and >> ) are built into bash. The rest of them are separate programs that are called by bash. And, calling a package of Linux utilities by the name of the included shell program doesn't exactly increase his credibility.
Good, inexpensive web hosting
Unless Bugs Bunny is hidden in there, there _are_ bugs in the Windows 10 Bash.
the biggest complaint I have with the WSL is the lack of full network capability ... you know, the one thing that would make it useful to a sys admin, power user, or developer. fix that and get back with me
For what it's worth, "Ubuntu Bash on Windows" is a bit of a misnomer - It's a Linux subsystem with all of the advantages and pitfalls. In particular /dev isn't very elaborate which causes problems with things such as above poster's emacs bg/fg experience, screen and similar things.
You can, however, install (from source, or apt-get) GCC/build-essential and then compile useful things such as FFmpeg, X.264, X.265 and all (most) dependencies. You can build Apache from source with your SSL library of choice and use it.
You have perl, python, awk, sed, m4 and other useful things by default, and you can package install most other things from the repositories (I installed yasm and nasm to build FFmpeg, X.264, X.265, GPAC and OpenSSL).
It is a useful tool even in beta.
While so many seem to see another chance to put the boot into Microsoft, others of us, who work in interoperability every day, are really quite excited by this tool. I was pleasantly surprised when Garming Sam, my colleague at Catalyst and fellow member of the Samba Team, wrote this article on how to run Samba under bash on Windows:
https://www.samba.org/~garming...
The fact that Microsoft is implementing the POSIX API, and even more, the Linux ABI, seriously is really cool, and shows that something seems to have changed in Redmond. I could never have imagined this when I started in Samba 15 years ago!
Apparently Microsoft released it to the public.
Time will tell.
This tends to confirm the view that the GNU/Linux misnaming as "Linux" is really about denying credit where credit is due (particularly noteworthy amongst people who are sticklers for technical accuracy and in need of a clearer distinction for what one has). This project includes some parts of a system but without the Linux kernel and yet you're still giving that project credit. What Microsoft has released might be a GNU/kWindows (akin in naming to Debian GNU/kFreeBSD, meaning GNU running atop the kernel of some other system—Microsoft Windows or FreeBSD, respectively) but whatever it is, it is certainly not "Linux" and it contains no Linux kernel code. Also, Cygwin has delivered some variant of comparable functionality for years.
Digital Citizen
The Cygwin layer has a long track record of success in providing a POSIX layer with some notable exceptions. There no native software management layer (forcing reliance upon the downloaded installer for software management). Further, while it is possible to build and install software locally from source, the process to do so is at best far from bulletproof - I personally was never able to get ClusterSSH running correctly under Cywin under multiple versions of Windows. However, it does provide a fairly robust software selection "out of the box" and does receive regular patches and updates. Being implemented as a set of API calls and libraries it tends to live within and get along more-or-less well with the underlying MS-Windows system.
They Bash on Ubuntu on Windows stack provides a binary-ready environment pre-loaded with a somewhat modified version of Ubuntu (GNU, but not technically Linux IMHO). Software management is performed using APT, and with very few exceptions software runs identically to the Linux counterpart. The entire environment appears to be created as an abstraction layer in memory on demand, although once running the subsystem does not spawn separate processes as more shells are created. Note that the environment is destroyed when the last user shell is logged out. This is permissible because there is no (significant) boot time associated with the environment - it is created and destroyed instantly without user intervention of any kind. This arrangement neatly precludes the likelihood that system services will be run in an environment which the MS-Windows system cannot control, but does lead to some coexistence issues in regards to filesystem metadata - specifically security-related metadata. The two systems (MS-Windows and Linux) are fundamentally incompatible by design at that level and so implementation/execution of GNU Linux binaries will turn up some quirks caused by this basic incompatibility. Incidentally, I've only been using the Ubuntu subsystem for a month now, and while I've installed and tested Xming and I've been able to install ClusterSSH with one command, I can't get the thing to work correctly in this environment yet either.
I can't bring myself to read the article because in the summary this guy is confusing 'ls' with 'bash'. Can we get someone who actually knows what they're talking about to write about it?
When you can simply install actual proper Linux in a free VM like VMware Player or Virtualbox, there's really no reason to mess around with this stuff unless you're actually using it specifically for what Microsoft suggests you should use it for. Cygwin is better for just providing a Unixlike environment on Windows if that's what you want, and a VM is still better for compatibility if that's what you need.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Seriously. The author seems to have no idea what the Windows Subsystem for Linux is nor how it works. There are separate file systems for a reason. The things the author tries are exactly the things Microsoft make it very clear will be very problematic at best.
The POSIX model and the Windows model of permissions are completely different. Instead of trying to map between the two (something Cygwin does variably well, sometimes really badly), they provide a file system with the semantics needed. Finally, there is no Microsoft version of Bash. It's Bash, compiled for the Linux kernel (like most packages) that is being run as is by the subsystem. The subsystem has bugs, this is known, this is beta software and it is software that even Microsoft is smart enough to know that they need as many people trying it to find bugs as needed.
And it does fill a very specific need and more importantly, it's further building out the newer subsystem parts of NT, which might come in handy for other things down the road.
'The Windows 10 implementation of bash' is just bash. It's the same binary as on Linux. The bugs are in the Windows Linux subsystem, not bash.
Quite frankly, everyone I know wants to move AWAY from Windows 10 and TOWARDS Linux, with their only problem being that certain Windows programs don't run nicely on Linux, and that certain hardware only has Windows support.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
One Scandinavian developer has even tried running X on Bash on Ubuntu on Windows,
There is no such thing as a Scandinavian developer. He is either Swedish, Norwegian or Danish (in this case Norwegian). You can refer to Scandinavian developers in plural, such as in "Scandinavian developers are lazier than Mediterranean developers", but no single developer is Scandinavian.
-- Make America hate again!
I started using WSL/Bash a couple of months back as a means to get around using a VM. Why not use a VM? I couldn't get cut-paste to work between the virtual and physical machine, and I didn't like all of the overhead in running a VM for pretty straightforward tasks (I spend a fair time on the laptop battery).
After activating the shell I quickly ran into the disk-permissions issue that this 'article' describes. You can move files in and out of the Bash environment using Windows Explorer, but if you modify/move a file via the Windows Desktop route (open it in Notepad++, edit it, save it, or simply copy it into ~/ via Windows Explorer) then that file is unreadable, even invisible in some cases, from within the Bash environment. Copying a file in/out via the Bash CLI is just fine, however. If you want to modify/use a file inside the Bash environment, you have to copy/edit it from inside that environnment. If you look in Process Explorer, you'll see that the bash process is not a peer process to the desktop, thus I'm pretty sure this is a Windows permissions issue.
I have some use cases that make this shell indispensable in my current workflow:
- I need SSH to hop around the corporate network, and we use RSA keys for access.
- We have a CLI-driven database, and the native Windows copy-paste makes it a lot easier to grab what I need.
- Our GIT system has as Python-based front end designed for Linux developers; it installs seamlessly in WSL/Bash and works natively there.
- With a Windows X-server, I can direct to localhost:0 and display a variety of X-based tools such as gitk and meld.
Could I do all of this with Cygwin? Could I have ported some of this to a Powershell environment? Could I have made the VM work better for me? Perhaps, but I just liked having the Bash shell handy, unobtrusive, and running natively, and all of the things I need to do to get my job done work really well. I still have a couple of limitations, but they're edgy enough for me to stick with WSL/Bash.
As a beta product, I'm very happy with what it does for me so far, and I look forward to further improvements.
There ARE bugs...
A clear lack of understanding. The X in Question is Xming, something that has existed for years before Ubuntu on Windows was a thing. It's a native Windows executable (using the Cygwin library, but could just as well use VcXsrv, X-Win32 or Exceed), just like if you were to use Putty with X forwarding to remotely access Linux GUI applications.
Heck, I was using X-Win32 to remotely access the GUI of an Ultrix machine back in 1996.
"Pros: You can also manage and manipulate other files inside your entire Hard Disk, even those outside of your Linux home directory."
I see a whole new round of Windows/Linux cross-exploits coming...
I blogged about this feature some half a year ago. Since then, Microsoft (or Canonical, or both) made some improvements. One fundamental issue is still there though - and causing all sorts of trouble, from broken 'screen' to not working 'ping'. The issue is too familiar to those who ever tried to support NFS and CIFS simultaneously in the same file system. Long story short, Microsoft has never figured out the meaning of mode bits in POSIX inode, POSIX systems have not done a good enough job of figuring out Windows permissions model. There were attempts to marry the two - from Samba to Likewise (RIP) to some proprietary implementations by Sun Microsystems, EMC, Nexenta and others. It would be nice if Microsoft and Canonical finally set this straight, but the chances are slim.
Pro:
-run off the shelf Ubuntu cloud image, not a custom made OS, with real Linux binaries and can be updated with apt-get
-several advantages over a VM:
-no need for a separate partition/file
-no need to allocate RAM (and require less RAM in general)
-no messing with network configuration (although this limits some functionality)
-no boot time
Cons: /dev (no hard drive, no serial port)
-file access seems slow
-fakeroot doesn't work (fakeroot-tcp does and can be used as an alternative)
-you need to launch it with administrative privileges in order to ping anything
-very limited
-no loopback filesystem mount possible, no Linux filesystems support
-during a large compilation, I got some failures with "write errors" which do not happen under my VM. My SVN local db was also corrupted.
-you can edit a file from Windows but the Linux simulator won't get notified the file changed. You can still read the good content but the modification date is wrong.
-no GUI application, no servers (as there is no init scripts)
So I write command line software. If a user messes up the command line, I display a Usage message. This uses argv[0], which is basically 'the executable name'.
When I run Windows bash, the pwd command shows '/c/test'. When I run test.exe I'd expect argv[0] to be '/c/test/test.exe'. It isn't, it is the Windows native 'C:\TEST\TEST.EXE'.
To Terminate, or not to Terminate, that's the question - SCSIROB
Well... if you would have made a break for the bathroom instead of making a post on the Internet... I am thinking that things might have worked out better for you.
My eyes reflect the stars and a smile lights up my face.
Who would have expected Microsoft to be one to finally achieve Linux on the Desktop?
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
A bug in MS software? Yeah, this is news.
In other news, boobs are fun.
...so in short its not trustable.
This whole "putting Linux under Windows and making sure it sucks" thing seems like Microsoft's actual purpose was to come up with a clever way to make inexperienced people think Linux must be significantly worse than Windows,
Does it really come with Pico, or is it plain old GNU Nano ?