Apple makes zsh default shell on macOS | Hacker News Reader

Apple makes zsh default shell on macOS

support.apple.com

100 pointssheharyarn44 comments

Previous discussion: https://news.ycombinator.com/item?id=20090193

This isn't going to fix the fact that they are shipping a 12 years old version of bash. How many scripts with `#!/usr/bin/env bash` are there out there?

Bash is the least worst language for bootstrapping since the alternative is POSIX shell which is even more difficult to get right.

The biggest issue is that Bash 3.x arrays don't work well with `set -u`.

Bash went GPLv3. Apple will never ship GPLv3. Persuade bash to relicense and they might consider it. Otherwise, goodbye bash.

I don't fully understand why GPLv3 is not good for Apple. I did try to ask my favourite search engine but I did not find a clear, concise answer.

What is wrong with GPLv3 for Apple and why is it okay in Linux?

Apple is unwilling to publish the source code of proprietary non-Darwin applications and libraries in their OS. GPLv3 enforces copyleft upon anyone who links to a GPLv3 application. There is a risk that simply including or using bash4+ could infect the system with GPLv3 compliance requirements, forcing Apple to publish their proprietary source code. To Apple, this is likely seen as an unacceptable risk no matter the cost and therefore bash is replaced with zsh. I expect them to warn about removing bash in five or ten years or so.

EDIT: Linux is GPLv2 only and does not accept GPLv3 submissions. It is likely that your question can be restated as “Why are GPLv3 programs able to use syscalls in Linux without infecting the kernel with GPLv3 compliance requirements?”, and this is likely due to the clearly declared syscall exception as noted in their licensing docs:

https://github.com/torvalds/linux/blob/master/Documentation/...

And, Torvalds commented on never-GPLv3 in 2006:

https://www.cnet.com/news/torvalds-no-gpl-3-for-linux/

I think it's not only about their proprietary source code, but also about restricting code that can run on your computer. Newer Macs have trusted boot, where the T1 / T2 coprocessor makes sure that system software has not been tampered with before booting. And every release seems to go further into the direction of verifying the code you execute.

As far as I understand it, if the GPLv3 clauses would apply, Apple would have to allow anyone to run their own, modified version of macOS on their computer, meaning Apple would need to provide a way for people to circumvent / disable all the secure boot architecture.

Also, things like "Activation Lock", where Apple requires your Apple ID password to re-install the OS (a theft protection feature) doesn't sound like it would be easy to reconcile with GPLv3.

I think they already allow modifications? Apple lets you disable System Integrity Protection [0], after which point you can make any modifications to the system. Only the T2 supports Secure Boot and it can also be disabled [1].

"Activation Lock" is an iOS thing. On Macs you can set a firmware password [2], but I don't see how that would conflict with GPLv3.

[0] https://developer.apple.com/library/archive/documentation/Se...

[1] https://support.apple.com/en-us/HT208330

[2] https://support.apple.com/en-us/HT204455

If a judge and jury find that the T2 chip, macOS, and bash4 were all integrated components of the software package “macOS” for the purposes of GPLv3 copyleft provisions, then Apple would be forced to share the source code of all software running on the T2 chip as well as all software it bundles with macOS.

While we can armchair legal this in either direction on how likely that judgement would be, they appear instead to have decided to never permit that risk to occur at all. I approve, too: if you don’t want to share every bit of source code in your product, don’t use GPLv3 in your product. It’s explicitly meant to be annoying like that, and any plausible effort to have your cake and eat it too risks being overturned by a court of law.

Activation lock for Macs was announced in the WWDC keynote.

> There is a risk that simply including or using bash4+ could infect the system with GPLv3 compliance requirements, forcing Apple to publish their proprietary source code.

This seems dubious, since the FSF themselves make the statement that aggregates of differently licensed software are fine, as long as you comply with GPL for the GPL-licensed parts: https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation

> But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.

All of macOS, since 10.0, is built on ever-more-interlocking systems of ‘intimate’ communication. As upthread points out, there’s a hardware chip that uses IPC to interlock with SIP to protect system files. The depth of IPC used to deliver a Macintosh appears to qualify the entire shipping OS for the “larger program” clause.

Setting IPC aside, it’s still easy to construct a case against GPLv3: If bash is included in an operating system release that can be downloaded like any other program on the Mac App Store, then it’s absolutely plausible to a layperson that the inclusion of GPLv3 in that program would - like any other program - infect it in its entirety with GPLv3’s copyleft requirements. macOS isn’t an aggregate software repository to its users, and a judge could easily be convinced to agree.

I’m not Apple’s lawyer, but I hope this helps convey what I imagine is part of their reasoning against it.

That's really not different at all from any other operating system. The "laypeople" in court have previously been perfectly able to consider even highly integrated OS components as separate from the whole - such as Internet Explorer in the case of the big old Microsoft antitrust lawsuit.

I think that a more likely reason is that Apple have plans for macOS that wouldn't play well with GPLv3's anti-Tivoisation measures.

Aha. Thanks for that.

At least we get diversity in our shells. I quite like that, it reminds me of the UNIX days when every OS was slightly different at the shell level, with different command line options for simple commands in Solaris/IRIX/HP-UX and those myriad of different IBM systems.

Can't have it too easy, can we? Or else anyone would be able to do our programmer jobs!

> Why are GPLv3 programs able to use syscalls in Linux without infecting the kernel with GPLv3 compliance requirements

Shouldn't this be the other way around? The concern would be with non-GPL programs making syscalls and getting infected with a GPLed kernel. The kernel isn't at risk of being infected.

I’m much more paranoid about GPLv3 infecting other code over an API than I am about GPLv2 infecting other code over an API, especially now that Linux has a clearly-crafted “no copyleft shall pass” fence erected on its syscall API.

OK, but how could the kernel possibly get infected? When you publish an API your code doesn't get infected by the viral licenses of anyone who writes code against it. That doesn't make sense.

cool. there's the answer. is the bash on current systems using GPLv2?

Yes.

Nothing wrong with GPL3. I'd rather use an OS that's willing to ship essential software. The OS is there to serve the user, not make their lives more difficult because of petty licensing concerns.

> Nothing wrong with GPL3 > ... > petty licensing concerns

Apple's lawyers probably think different.

You can install all the GPLv3 software you want on your Mac (Macports and homebrew make it easy). But Apple made it clear that they are not going to ship anything GPLv3 licensed.

> Nothing wrong with GPL3.

Wrong

> I'd rather use an OS that's willing to ship essential software.

Ok, there's Linux in that case.

> The OS is there to serve the user, not make their lives more difficult because of petty licensing concerns.

"Petty licensing concerns" are an issue for big companies.

I thought everyone was using the fish shell on the Mac. :)

http://fishshell.com/

I have used fish for a few years and quite liked it, but ultimately I think using zsh with oh-my-zsh or similar bundle is better because of bash compatibility.

I think if one only ever uses their own computers fish is better, but having to switch contexts, having to have different configurations and so on is a pain and not very productive.

I recently moved from bash to fish. Re-training is was easier than I thought, especially not having to tap Ctrl+R every time I'm looking in the history (that one was hard wired). I wrote about my migration here:

https://anisse.astier.eu/bash-to-fish.html

One thing I haven't touched in my article: globbing behaves differently than the default, which means you have to quote your '*.ext' arguments when using find for example. This is fairly well documented: https://fishshell.com/docs/current/index.html#expand

I very rarely move back to bash, so I consider this migration a success :-) If you haven't yet, should try it !

I know I was... well up until my 2008 MacPro died last month and I switched to Linux (ain't nobody I know gonna afford that new MacPro on their own).

Now I use Fish Shell on Linux and it's fine for what I usually do.

I can recommend the GRML ZSH config to go with ZSH https://grml.org/zsh/

Works out-of-the-box for me on most machines (i.e. I don't maintain shell settings besides downloadding GRML zsh regularly) and it is not as big as oh-my-zsh.

From looking at it, this seems designed for Linux and not MacOS.

If you're looking to replace oh-my-zsh with something sane and fast, zprezto has been my go-to choice.

will have a look at zprezto, but I wonder how its "designed for Linux", or at least how that would matter. Been using this template for years on Mac and have not had the impression that I would be missing out on things.

Is there any news on if apple is keeping python 2 and/or adding 3 by default?

Scripting Language Runtimes Deprecations Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. Future versions of macOS won’t include scripting language runtimes by default, and might require you to install additional packages. If your software depends on scripting languages, it’s recommended that you bundle the runtime within the app. (49764202) Use of Python 2.7 isn’t recommended as this version is included in macOS for compatibility with legacy software. Future versions of macOS won’t include Python 2.7. Instead, it’s recommended that you run python3 from within Terminal. (51097165)

Source: https://developer.apple.com/documentation/macos_release_note...

good decision. macos shouldn't come with a python version installed.

If you like zsh, you should check out the "oh-my-zsh" addon, which features 200+ optional plugins (rails, git, OSX, hub, capistrano, brew, ant, php, python, etc), over 140 themes to spice up your morning, and an auto-update tool:

https://github.com/robbyrussell/oh-my-zsh

Or prezto if you just like a few sane extras without bloat.

I remember trying oh-my-zsh in the past and over time having its performance crawl to a halt. Been rocking zprezto for years

No surprise. This has been coming for a long time.

it doesn't say why. is it a BSD vs GNU thing?

GNU switched to GPL v3 a while ago, I imagine this is a license thing

It's a licensing thing yes. Current bash's are GPLv3, zsh is MIT.

A pity they didn't make a structured output shell rather than traditional regex scraping but their main concern is compatibility, and zsh fits nicely.

PowerShell is available for Linux & Mac now if you're looking for a structured, object-oriented shell on your Mac.

Doesn’t really fit into the posix compatibility bucket though. If that hadn’t had been a concern then I imagine fish is the most Mac-like shell out there.

I'm not sure how much POSIX matters anymore. Linux and MacOS determine 'standard' Unix behavior by their market share - I can understand disliking this though.

The issue I have with Powershell is it's full on objected oriented. Personally I'd like something in between. Structured data where the "methods" are the utilities themselves.

Most of the time (though not always) the methods are the utilities. From https://github.com/mikemaccana/powershell-profile/#how-does-...

    $results = @{} 
    ls -recurse -filter "eslint-scope" | foreach { 
        $file = "${PSItem}\package.json" 
        $version = cat $file | convertfrom-json | select -ExpandProperty version 
        $results.Add($file,$version) } 
    echo $results | format-list

You don't have to pipe to 'select', 'where' etc - if you send something to grep or select-string you'll be looking for regexs bash-style.

It should have been fish shell. :(

Reply on news.ycombinator.com