Use zsh as the default shell on your Mac
support.apple.com
support.apple.com
On macOS, you can run anything out of the box (depending on security/gatekeeper settings) and you can replace or modify system executables (such as /bin/bash) if you turn off SIP (which is slightly tricky to do but can be done from recovery mode.)
Running your own customized /usr/local/bin/bash is easy of course, and package managers like MacPorts or Brew make it simple to install various shells including the latest bash.
On iOS, however, there might be an issue, as you have to sign executables with XCode, but unfortunately Apple reduced free developer provisioning profiles from one year down to two weeks in order to block third-party app stores and malware, and to get more people to sign up for the paid developer program. Moreover, there is also no Apple-sanctioned way to modify system executables that I am aware of.
I wouldn't even classify turning off SIP as "slightly tricky". You boot into recovery mode, open the terminal, type in two words, and press enter.
Besides, this is separate from the GPLv3 question. You can absolutely recompile bash and replace macOS's version with your own, so I don't understand why this is a problem for Apple.
If Bash were also being used on iOS that would be different, but I'm quite confident that will never happen.
But preventing ALL Macs from turning off Gatekeeper and SIP? I think that would be unpopular.
I know it sounds crazy, but they have for years now been taking steps - like this - which nobody seems to find a rational cause for, but which step by step seem to remove obstacles of technically, legal, or user expectations in line with making OS X an app store only platform, and if possible completely replace OS X with iOS.
1) Gatekeeper makes it harder to run malware; unsigned executables don't run by default, and signed malware can have its developer keys revoked by Apple.
2) SIP makes it harder for malware to modify system files.
The obvious "rational" business benefit to Apple is that:
3) Gatekeeper makes it harder to sell Mac apps without Apple getting a 30% cut
It's certainly possible that Apple has intentions other than to make the platform better and a discussion can be had on if the tradeoffs are worth it, but it's ridiculous to claim that there are zero benefits to anyone but Apple.
We're talking about what Apple could be planning that would violate the GPLv3. As long as the signing can be disabled by the user, there shouldn't be a GPLv3 violation.
I also expect zillions of helpful nieces/nephews would flip that checkbox for their uncles/aunts, and, accidentally or on purpose, leave it that way.
Even if that isn’t true, making it harder for malware to flip that flag already is a rational reason to implement it this way.
I do worry very much about SIP becoming impossible to disable some day. Don't ban knives because people might cut themselves.
I believe that they are suggesting that Apple would be required to let you sign your own software if you do choose and give owners the right to opt to have their os trust software they OR Apple signed.
There is something that was addressed in the gpl community called tivoization.
Tivos dvrs were Linux boxes wherein they shared their source technically complying with the letter of the gpl but in fact locking them down so users couldn't modify the devices violating to many peoples mind the spirit and clearly expressed intent of the license.
This is if I understand correctly dealt with in gpl 3 which is what I think the poster is talking about.
Apple ios devices are non free in the same fashion as Tivos which is incompatible with gpl3
You can't tell me that Microsoft is able to ship entire distribution's userlands (Debian, Ubuntu, SUSE, and more) through the Windows Store, including all their GPL3 components, and Apple can't figure out how to ship an updated version of base64.
If I'm grumbling, it's just because making devops/CI scripts work on Windows and Linux is easier than MacOS and Linux these days because my colleagues run into issues like "base64" or "uuidgen" having different arguments in the extremely dated MacOS userland, and they then have to brew install a bunch of isolated components.
Look at a bunch of Apple manpages. Many of them say FreeBSD.
Sorry but have you heard of Visual Studio?
Whenever I have to use other offerings like Eclipse, Netbeans or Android Studio for other languages I am never very satisfied with them. Android Studio in particular breaks gradle and projects between updates, although Flutter seems to work.
I'm confident most of the .NET community is very happy with Visual Studio.
In my opinion, Visual Studio massively outclasses Eclipse, VSCode and Netbeans. It even makes IntelliJ (which is pretty great too) look a bit inadequate.
(I use Emacs these days though.)
>I'm confident most of the .NET community is very happy with Visual Studio
.NET is not the only ecosystem people develop for. There are embedded C/Forth, web frontend/backend, written in Java, Scala, Ruby, Python, other stuff. VS sucks for nearly everything safe C#/C++ for windows.
Besides, even for C# people use an additional plugin, resharper, so VS is not enough even for its target ecosystem.
Those that have CPU cycles and memory to spare do.
I have a laptop with 64GB of memory just because I need to run VS + ReSharper in a VM. Seriously.
I am now working on Linux with Sublime Text, Makefiles and the command line. I am most comfortable with that setup but there are many features that I miss from VS: the debugger, online help, code navigation, ...
Not that these features don't exist in other editors and IDEs, but with VS, they worked reliably and out of the box.
Note: VSCode is completely different. It is a multi-platform text editor, one of the best in town. A bit lacking in the performance department though, that's why I am still using Sublime Text.
A sluggish clumsy bloated IDE? What's good about it? I've used it for a couple of years when I wrote directshow filters, and it was a complete shit back in a days (2015-2017).
* terrible clumsy project system, where changing a flag is a quest. As abominable as autotools.
* using non-vcproj projects is a pain, especially when you have a bunch of make files
* It's slow as hell.
* Language support is lacking. No OCaml, no Lisp, hell, even C11 is a quest.
After they've added a package manager and clang support, it became less painful, but fur from great experience.
Linux is a lot less stable, as a laptop OS, than Windows or OSX. Suspend and resume in presence and absence of multiple monitors is like rolling dice; locks up about 15% of the time.
And Windows still requires random reboots for updates, of course usually at the worst possible time (fortunately I only use windows in VMs for testing). God how I hate Windows, it's unbearable really, after 5 minutes at the third nagging stupid popup (update Java! update Acrobat! update antivirus! don't turn off the computer, installing update 2 on 10532!) I want to throw the thing out of the window :)
A mix of dock and undock with multiple monitors is dodgy; like rolling a die. Plugging in the display port cable after a resume from a prior docked suspend, for a presentation, is flipping a coin.
Can't remember any major problems with Linux on laptops for latest 5 years. All works like charm.
If you use a cheap/noname/non-popular hardware - it happens, yes, but in Windows world too.
It's the multi-monitor / dock interaction. It's just not solid.
I've had issues with USB-C docks. I've had zero issues over four different Thinkpads (FC28 and FC29) with the Lenovo Thunderbolt dock.
Old thinkpads with 7-row keyboards had proper ergonomics, to my mind anyway.
The reason I switched to Mac in 2006 was that I ended up using a friend's Mac for a month while abroad so I could get some work done. When I got back to a place where I could get a new Viao at a reasonable price it occurred to me that I hadn't been fighting with the Mac a single time. Wifi always worked, everything I plugged into it just worked as well, the software I ended up installing just worked too, Apache and SVN ran fine, there was a good Terminal app out of the box, etc. This was in stark contrast with the decades long experience I had had with PCs until then. On any given week I had been invariably spending between a half-hour and a day fighting with Windows in some way or another. Which could mean trying to figure out why Wifi or some random printer didn't work, looking for drivers, reinstalling or reconfiguring some piece of software, and so forth. Has this improved materially since the past decade?
Bundled apps to me are a wash. Preview >> Edge for PDFs and Terminal.app >> Cmd.exe, but explorer.exe >> Finder and Task Manager >> Activity Monitor.
Another big plus for windows is everything to do with graphics drivers and GPU support if you're into this. I also find WSL overall now better than Mac's Darwin since you get up to date Linux packages which beats homebrew in my books. Performance of WSL is also pretty good, much better than running a VM. This is really what turned Windows around for me, making it a very viable alternative.
Having to deal with three variants is relatively simple.
Now having to deal with DG/UX, Aix, Tru64, SGI, HP-UX, Solaris, BSD and the new incumbent Linux, that was fun.
And we can tell our kids we had this thing called endianness which showed up in structure packing, system calls, network byte ordering, and hopefully portable binary file formats. Thankfully we had RPC and IDL to save us from that mess... not.
Oh and don't forget the windowing system war on top of the Unix war, all with different desktop and library concepts: CDE, Motif, Openwin, NeWS, DM, X11 and X10 at least.
One compatibility honorable mention goes to Apollo for at least making an attempt at flavor normalization: you could have an env var that would resolve a symlink at every file access near the top of the filesystem, where there would be a collection of different BSD/SystemV/Aegis(?) all running at once. [2]
1. https://maultech.com/chrislott/resources/cstyle/ifdefs.pdf
To this date, this is the only network protocol I have ever seen that not only allowed you to choose the endianness you will use in the header, but also the floating point format.
Don't forget AIX/ESA (a weird beast), NextSTEP (which is still with us, in disguise), the HPC crowd (UNICOS, OSF/1 AD...), SINIX (my first contact with the internet, thanks to Siemens/Nixdorf)...
Which is to say, "let users run their own software". There's value in formal authentication of third party software as a default configuration, but let's not pretend that's what lockdown is about.
The discussion is literally about replacing the default shell...
(Of course, one could disable SIP altogether.)
I suspect they also recognize that applying the GPL would force them to release things they otherwise consider private.
If you haven't tried it, I cannot recommend zsh + plugins enough. Only install that you actually use, otherwise it can slow start time a bunch.
Here is a list of the plugins that are available: https://github.com/robbyrussell/oh-my-zsh/wiki/Plugins
I especially appreciate git+git-extras, web-search (`google my query`), docker, npm, and dirhistory.
It's never been about 'understanding' zsh or not, it's always been about making it comfortable to use, quickly, on any given system I might use.
Sometimes a nice set of defaults is more productive than a custom solution.
But i do think the misunderstanding i mentioned is very common, as illustrated by the fact that the GP seems to think that OMZ itself provides zsh's completion functionality. It's also a frequent point of confusion with people seeking assistance on zsh's IRC channel.
Don't get me wrong, I'm a happy fish user myself. But breaking backwards compatibility with shells from the past 40 years and then saying "you're doing it wrong" is not how to make easy-to-use software.
fish: Unsupported use of '='. To run 'yarn' with a modified environment, please use 'env PORT=5000 yarn…'
Infuriatingly, fish knows what I meant, as the error tells me what to do instead. But it won’t do it for me and prefers to lecture me instead.
This doesn't make me want to use it.
Slightly disappointed, but guess they had to go somewhere and zsh is going to be well supported going forward
# change default shell to newer brew'ed bash
brew install bash && sudo dscl . change /users/$USER UserShell /bin/bash /usr/local/bin/bash
# change default shell to newer brew'ed zsh
brew install zsh && sudo dscl . change /users/$USER UserShell /bin/bash /usr/local/bin/zshThat's homebrew, not Apple.
Since ZSH is under an MIT-like license, they’ll probably ship updates to it.
Apple absolutely ships updated packages. They rarely ship super recent version, but Bash still stands out as the last version they ship is 3.2 from 2006 (4.0 was released in 2009).
By comparison, I believe Mojave ships zsh 5.3. Still outdated, but only by a few years (it was released in December 2016).
The parent's point is that Apple had to do something with updating their bash userland, as they don't want to use the later GPLv3 versions.
Apple does ship updated packages (it has routinely updated Python, Ruby, and tons of other UNIX userland).
It just doesn't update old GPLv3 packages, so it was left with an old bash.
Your suggestion "if you want updates" refers to the parent, who already knows all you wrote. His point is that Apple wanted to update the default shell (but couldn't as long as it was bash), not them. Given that, the context, the homebrew suggestion is irrelevant.
> To test script compatibility with Bourne-compatible shells in macOS Catalina, you can change /var/select/sh to /bin/bash, /bin/dash, or /bin/zsh. If you change /var/select/sh to a shell other than bash, be aware that scripts that make use of bashisms may not work properly.
> Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. In future versions of macOS, scripting language runtimes won’t be available by default, and may require you to install an additional package.
https://developer.apple.com/documentation/xcode_release_note...
and
> LLDB’s Python scripting is now based on Python 3. If you are using Python extensions that aren’t compatible with Python 3, they will break. To help with the transition, you can run in Python 2 mode by setting a default
So looks like python 3 will become available and default
$ pyenv versions
system
* 3.7.3 (set by /Users/wyclif/.pyenv/version)
...it's dead simple. Now, if I wanted to I could manage any number of previous versions with pyenv and pipenv.
Will this break all those or are bash scripts and zsh scripts basically interchangeable?
Maybe I'll write a bash script to prep my poorly written bash scripts :D
But if you did want to run them with zsh, most simple scripts that just set environment variables, string together commands, or redirect to files should work without any changes. The most obvious difference for basic scripts like that is that zsh doesn't split parameter-expansions on white space by default (so if you did something like `opts='-a -b -c'; mycmd $opts` it wouldn't work without additional, minor, modifications)
I'd been using ZSH for a year as if it was Bash with better history and much better completions. The difference mentioned above was the only one I knew about. I kept writing my scripts in Bash and was quite happy with the UX.
Cool! I do use shebangs, but my concern is that moving forward bash may not be ported to macOS. (Or will I probably be able to, worst case, compile it myself?)
Of course it goes without saying that you shouldn't use #!/bin/sh then use bash...
In Terminal, enter $ chsh -s path, where path is one of the shell paths listed in /etc/shells, such as /bin/zsh, /bin/bash, /bin/csh, /bin/dash, /bin/ksh, /bin/sh, or /bin/tcsh.
I personally never stopped using tcsh after the bash switchover since it's what I knew and what my dotfiles were already written in, and I'll most likely just keep using it in Catalina too.
EDIT: apparently zsh doesn't have persistent or global variables, my bad.
If that's an argument in favor of ZSH, I think I've missed the point.
Barely—it doesn't address any fundamental issues with bash, it's basically a coat of paint.
It does make sense that tech companies are only into disruption if they can profit from it.
Plenty of developers are using oh-my-zsh either for just the plugin support or for the very popular iterm+powerlevel9k+agnoster theming.
Being practical about it: if you install fish you can also install bash, and then running a bash script is as simple as `bash script.sh`, so you can have your cake and eat it too.
Although, in this particular instance, if Apple is going to cease shipping bash at all, I can see why this would be annoying out of the box.
And, a omf plugin if you want: https://github.com/oh-my-fish/plugin-bang-bang
Heck, the new Mac Pro is even priced like a SGI/AIdX box.
Short-sighted move considering Microsoft is actively looking to ship a Linux kernel in Windows.
The only GPL stuff left on recent Android is the Linux kernel, and well, Fuchsia is improving.
Edit: I was misremembering things. tcsh until 10.3.
Source: I was tasked with the performance comparison and (despite my objections) the conversion to bash. On the bright side, I learned a lot about zsh in the process and have used it as my shell rather than bash ever since.
$ /bin/sh --version
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin19)
Copyright (C) 2007 Free Software Foundation, Inc. complete -W "$(systemctl list-unit-files|cut -f1 -d' '|tail -n+2|head -n-2)" systemctl
I can think of essentially zero areas in which zsh is slower than bash in which it is slow enough to create the need for a hardware upgrade, or even contribute to such a need on an already-overloaded system. I mean, sure, file performance bugs if you want.
But your shell is not going to be the "oh christ, this is slow" program; it doesn't run Electron for chrissakes.
Btw, Bash is the same. So you just said that someone that implemented your Bash theme did better than in your Zsh theme.
Your point probably stands that it's more to do with the completion scripts rather than the shells themselves though.
Though I will say I’m surprised. I’ve opened a radar suggesting this change and it was closed with (paraphrasing) “won’t do it as the user can easily change the shell, I myself do it”.
Nowadays that's the only thing I run on top of zsh, which makes the shell significantly faster than with oh-my-zsh (and its kitchen sink).