7 ms·
Reminder that 2019 version of macOS ships with 2007 (last GPL2) version of Bash, and will never ship with any newer version. /bin/bash --version GNU ba
by pornel 8y ago
Reminder that 2019 version of macOS ships with 2007 (last GPL2) version of Bash, and will never ship with any newer version.
/bin/bash --version
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin18)
Copyright (C) 2007 Free Software Foundation, Inc.
macOS used to be an awesome developer machine with good tools out of the box. Now the built-in tools are just a bootstrap for their own replacement via Homebrew. Like IE for downloading Chrome.
- stock_toaster 8y agoIt's just GPLv3 software though. In contract, SSH is currently reporting OpenSSH_7.9p1, and that is fairly up to date. I do think that if Apple can't ship a current version (for whatever reason), they probably shouldn't have it pre-installed at all, much like the BSD's don't come with bash by default either. Maybe they could ship with ksh/pdksh/mksh or something instead.
- hestefisk 8y agoMacOS used to ship with tcsh as its default shell for years.
- pstuart 8y agoI still don't understand how a gnu binary could taint their OS. They can provide the source on opensource.apple.com. Case closed.
- Carpetsmoker 8y agoThe problem is that GPL3 has more restrictions than just "publish the code". That's why projects such as FreeBSD, OpenBSD, etc. also won't include GPL3 code, as including GPL3 code would restrict what you can and can't do with the entire system. I assume that Apple's reasoning is similar.
- ajross 8y agoCan you name them? It's not exactly snark. My experience is that almost everyone with strong GPLv3 opinions turns out not to actually object to the terms themselves when discussed in isolation. To head off: it's not the patent grant. Apache 2 has a very similar patent grant and everyone is fine with it.
- deleted 8y ago[deleted]
- Matt3o12_ 8y agoApple doesn’t support it because GPLv3 requires that you are actually able to run the modified source code (not just see, change and distribute). While they probably could do that on macOS, macos and iOS share the same kernel and many common source trees. So by providing macOS software with GPLv3 code, some of that code could potentially be shipped with iOS which would land them in hot water because you are not able to just execute code on iOS. Even with a developer license, you couldn’t just recompile the kernel (or even Library) and replace it with the default one. Edit: Here is more information about that: > Protecting Your Right to Tinker > Tivoization is a dangerous attempt to curtail users' freedom: the right to modify your software will become meaningless if none of your computers let you do it. GPLv3 stops tivoization by requiring the distributor to provide you with whatever information or data is necessary to install modified software on the device. This may be as simple as a set of instructions, or it may include special data such as cryptographic keys or information about how to bypass an integrity check in the hardware. It will depend on how the hardware was designed—but no matter what information you need, you must be able to get it. Source: https://www.gnu.org/licenses/quick-guide-gplv3.en.html https://www.gnu.org/licenses/quick-guide-gplv3.en.html That means if there was GPLv3 code in iOS, Apple would have to send you their private keys to sign any source code so you can run it on iOS.
- ajross 8y agoThe product in question is bash, though, which doesn't ship on iOS at all and which obviously could be (and should be) modifiable on OS X.
- _emacsomancer_ 8y agoI assume you can install newer versions of Bash on macOS though? (But it certainly suggests to me that macOS isn't actually the easiest out-of-the-box solution if your workflow includes anything more than web browsing.)
- a012 8y agoSure you can install newer version of bash via homebrew then update PATH in your shell profile.
- shpx 8y agoOn macOS almost everyone uses the homebrew package manager https://brew.sh https://brew.sh. Installing bash is harder because you have to add the filepath of the new bash binary to /etc/shells and then set that filepath as your default shell, but brew install bash echo /usr/local/bin/bash | sudo tee -a /etc/shells chsh -s /usr/local/bin/bash and if you're on macOS and still haven't heard of homebrew, you first need to install it with /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
- gnulinux 8y agoThat command makes my eyes twitch. This sort of "download random stuff from internet, then pipe them to ruby/perl/python" madness should end, like right now. I'm assuming you're a reasonable person who knows what that commands does. Can you really not see how people can misuse commands like this to execute arbitrary code on people's computers, even experienced engineers if they carelessly copy-paste code like this. As a rule of thumb, to whoever reading this, please don't trust random strangers online and run their code. You never know. Always download code from trusted sources and check sha hashes. Piping anything else to ruby/perl/python is playing with fire.
- nomel 8y agoAlternatively, follow the homebrew installation instructions: https://docs.brew.sh/Installation https://docs.brew.sh/Installation
- PopsiclePete 8y agoThank the GPL v3 for that one. Same reason GCC is frozen at 4.2.1 on mac. I switched to zsh, personally - the one Apple ship is pretty current. macOS is still a pretty solid developer machine.
- a012 8y agoSome application still requires bash, like wireguard
- zx2c4 8y agoWireGuard doesn't require bash. The main configuration utility, wg(8), is written in vanilla C. However, the tools ship with a little convenience script, called wg-quick(8), which is indeed written in bash. It started out as the thing I was using to configure my laptop on the go, but then others found it helpful. It's by no means essential or central to WireGuard, and lots of people use different things to wrap wg(8) and the various networking tools.
- pbhjpbhj 8y agoTotally aside: is there a tool that can parse a programs code, then consume a folder of (headers for?) versions of a dependency and say the versions that are [a priori] compatible?
- a012 8y agoBased on your documents[1] of Mac OS, it looks very like wireguard requires bash version 4 or newer because wireguard-tools will install bash as dependency. Maybe you should edit the docs or shouldn't deliver wireguard-tools? $ brew install wireguard-tools [1] - https://www.wireguard.com/install/ https://www.wireguard.com/install/
- zx2c4 8y agoSorry if I didn't make it clear before: wg-quick(8) is part of wireguard-tools, because people find it useful sometimes. But it's in no way essential and WireGuard functions entirely without it. That's what I mean when I say WireGuard doesn't require bash. That little helper script is just a small convenience thing some people like.
- Redoubts 8y agoJust use zsh.
- gigatexal 8y agoYeah just use homebrew and forget about it
- petre 8y agoIt also ships a recent version if zsh. But I agree, you're better off with Linux if you want a developer box and deploy on Linux.
- h1d 8y agoHow's that? The quality and amount of GUI tools are far more complete in macOS than Linux desktop and you can just run a Linux VM to mimic the deployment server.
- petre 8y agoI don't care about the GUI tools, I just need an editor, a terminal and a web browser. And maybe Sequel Pro once in a blue moon. The MacOS GUI is quite annoying when you want to do stuff fast like for instance move windows between virtual desktops or switch the desktop with the mouse wheel. The tooling is just not there (old Python, old Perl, old Ruby and of course different versions from your deployment environment), you have to resort to third party tools such as homebrew or macports, you have to install Xcode to get gcc, you need an Apple ID to do that, the system level API is incompatibile with Linux, the filesystem is or at least was case insensitive. New MacOS versions after El Capitan are also getting worse at compatiiblity with other Unix-like platfroms. It's a pain to set up a development environment really, especially if you use any dynlibs. Instead of a VM we have a staging server where we deploy and there are almost always surprises. In Linux the tooling is just there, a few seconds and one package manager command away. If your package is not there then there are PPAs or OBS repos. You can reproduce the platform you're deploying as closely as possible and there are less surprises.
- darkpuma 8y ago> It also ships a recent version if zsh. Recent compared to bash maybe. 10.14's zsh is two years old.