Use zsh as the default shell on your Mac(support.apple.com)
support.apple.com
Use zsh as the default shell on your Mac
https://support.apple.com/en-ca/HT208050
26 comments
For those wondering why Apple is allergic to GPLv3 code: there is a clause in the license requiring you provide a way to run modified version of the software which would require Apple to let users self sign executables.
So, Homebrew?
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.
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.
That is nothing compared to writing portable UNIX scripts during the UNIX wars.
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.
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.
Yup, and then down in the code, it was #ifdef's up to your eyeballs[1], even if you went all the way and used autoconf/configure and then... more #ifdefs.
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
2. https://en.wikipedia.org/wiki/Domain/OS
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
2. https://en.wikipedia.org/wiki/Domain/OS
Funny you should mention RPC because of course RPC was all the rage back in 1993, with the heap of garbage they called DCE/RPC.
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.
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.
The joys of CORBA and COM!
> Now having to deal with DG/UX, Aix, Tru64, SGI, HP-UX, Solaris, BSD and the new incumbent Linux, that was fun.
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)...
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)...
I've moved on to Windows since last year. Besides terminal emulators being shit (which they're fixing now), worse PDF support and shit OS config management, there's really not much anymore that goes in favor of Macs. Their laptops are worthless junk at 40% markup, the OS gets buggier and more locked down with every version while Windows is on a clear trajectory of improvement and PC hardware gives real choice and innovative solutions. I was a Mac user for 13 years, but no more. Since they gave all the keys to Jony it went down the drain real fast.
Out of curiosity, has Windows improved in any way from a low maintenance perspective?
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?
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?
It certainly has improved, but Mac still has the edge in that regard. This mainly comes down to one things: Superior config management (plist files vs Windows registry). This makes it much easier to maintain - you hardly ever have to reinstall a Mac, instead just clean up all the Library folders and you're fine. A Mac HD also boots on any supported Mac hardware, impossible with windows, which makes things like Migration assistant and full Time machine restore possible.
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.
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.
how about screen management ? I'm using several virtual screens (spaces) in my mac, that makes things a lot easier to me. How does that go in today's windows?
My biggest problem with Windows is that you can't scroll in a window or a pane without clicking on it first. Both Mac and Linux support that and it makes the OS feel so clunky.
That's actually one of the better new features in Windows 10 (that you can these days scroll an inactive window).
Oh, really? I might give it a try again one of these days, then.
I'm no Windows fan, but Windows 10 is the first where I don't actively hate the window manager. Well, I do hate how it keeps moving all my windows to the left side of the desktop. Not sure why that is happening. So I guess I hate something different about it now.
You mean it's snapping to the left half after some action? That would probably be when you press Windows+Left-Arrow, happens to me sometimes when I try to do Ctrl-left for example.
It's generally when I unlock the screen after waking up. I have no idea if I accidentally pressed Windows+Left, but it's doing this very consistently.
sounds a bit like a driver issue, like it changes the screen resolution during wake-up. you should figure out whether it's the exact size used for half-pane snapping (which sounds like userland issue), or whether it's some other size.
I don't think it's the size for 'half-pane snapping'. It seems a faulty screen resolution change on wake-up might indeed be my problem.
But in MacOS, typing doesn't follow the mouse by default. So you're scrolling away in a window you don't realize is inactive. Then go to close a tab or type and you've just closed a tab in a random application two monitors away. And it can be hit-or-miss whether you realize which application you just interacted with (or where you just inserted characters into your code).
Ugh this happens to me all the time, but on the other hand I'll sometimes be scrolling through a pdf with my trackpad, but typing in a pane on the left, so I do find it quite useful to have that split between kb/pointer focus.
Also: there was an app, sorry, a program we used with Windows98 that did this, Focus something or other it was called.
Yeah, Windows can actually do that now.
Those seem like pretty big downsides to me, and I don't believe the new terminal marketing gimmick. I will admit Windows has been very attractive lately for gaming reasons, but from a development standpoint, MacOS still seems way ahead of Windows. I seriously considered it, but there would be too much I'd miss if I switched. There's some minor reasons too, like why does IntelliJ look ugly in Windows? It looks great in both Mac and Linux.
Re: IntelliJ looking bad on Windows, I do know that JetBrains IDEs are still stuck on using GDI for drawing fonts rather than the new DirectWrite protocol. The poor quality of GDI (especially on high DPI displays) is very noticeable when you switch from Linux or macOS to a Windows app that uses it. I looked it up a while ago, and as I recall it was an issue with the Java runtime that JetBrains IDEs use.
Well did you try out Linux bash on windows. In less than 2 minutes you setup a Debian instance. You got shells and everything. All well known ide's are available on both Windows and Mac. In my opinion there is no real difference anymore.
I am a Mac user and windows user.
The only reason why I still use my Mac is because of the ergonomics.
In my experience Mac OS still has the edge in terms of stability. But certainly the gap is closing.
The only crashes I've had from NT kernel over the past 15 years or so are from graphics card drivers and bad RAM.
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.
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.
Not my experience. I used mostly Linux for 15 years, and I had zero problems with laptops, external screens and suspend in the past 8 years. I have a Linux laptop that's used for demo hooked up to a TV, settings are changed from dual screen to mirroring all the time, then it goes to sleep, is woken up with the TV off, etc, zero trouble, it hadn't rebooted in 2 months.
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 :)
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 :)
I've been using Linux since 1996; not wet behind the ears. Graphics drivers are substantially worse on Linux than Windows, and even on Windows they're still the main source of problems.
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.
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.
A lot of what you say describes a fairly common experience with Windows too. Perhaps not with a Thinkpad maybe but I’ve failed to revive a sleeping windows machine on a few occasions, and switching between output sources can be unpredictable too. Mac is the only platform which consistenly succeeds at these kinds of things because of the vertically integrates hardware. Its the drivers as you say ... I don’t think the actual o/s has much say in it beyond the drivers that are supported.
> Linux is a lot less stable, as a laptop OS, than Windows or OSX.
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.
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.
Lucky you! I do a reboot on my Windows 10 machine every night. I also suffered from intermittent complete and total lockups due to a bug in what I traced to spotify. Similar thing happened with MacOS and safari recently enough too so I stopped using Safari for a while ...
using a Lenovo P50 with windows 10 for 2 years now, I only reboot it maybe once a month, for the rest, I close the lid, it goes to sleep, next day in the office, I open the lid and continue where I stopped. so far I have had zero issues with it.
Genuinely curious - which ergonomics do you mean? Macbooks have objectively terrible keyboards these days, and the lack of dedicated buttons on the trackpad makes two handed trackpad use a royal pain. Yes, the mouse movement is precise, but the trackpad doesn't blow my mind.
Old thinkpads with 7-row keyboards had proper ergonomics, to my mind anyway.
Old thinkpads with 7-row keyboards had proper ergonomics, to my mind anyway.
[deleted]
"from a development standpoint, MacOS still seems way ahead of Windows"
Sorry but have you heard of Visual Studio?
Sorry but have you heard of Visual Studio?
>Sorry but have you heard of Visual Studio?
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.
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.
Everyone has heard of Visual Studio, and nobody that has to use it wants to. Just because you have Stockholm syndrome doesn't mean everyone else has to have it too ;-)
It has been a long time since I used Visual Studio but I remember it as the best IDE I have ever used for C++.
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.
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.
I'm really suprised at this comment.
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.
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.)
>from a development standpoint
>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.
>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.
> 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.
Those that have CPU cycles and memory to spare do.
ReSharper is a meme in the .NET world, similar to how Crysis in the gaming world is: https://i.imgur.com/LQkRlSN.png
I have a laptop with 64GB of memory just because I need to run VS + ReSharper in a VM. Seriously.
I have a laptop with 64GB of memory just because I need to run VS + ReSharper in a VM. Seriously.
It's why I put in: unless you have to use it, which means: if you target Windows. If you target anything else, you're probably not using it unless you already happen to have it. I agree that most IDEs are crap, it's pretty strange when you think about it, software developers developing software to develop software, but developing it badly so it now sucks for everyone.
Must be a different development sphere to me. I have to use xcode for dev on the Mac and it is feeble compared to VS. I can't think of a better IDE to be honest (C++, C# for me).
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.
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.
VS is pretty nice if you run it without plugins that slow it down (like ReSharper)
That’s probably more a BSD vs GNU issue, to be fair. Mac is based on FreeBSD. GNU/Linux, well... :)
To be exact, FreeBSD and macOS (based on NeXTStep) are both based on BSD, and contribute to each other. FreeBSD came out after NeXTStep was released though...
True that freebsd is more recent than NeXT, but they re-imported a lot of stuff from more recent freebsd over the years though.
Look at a bunch of Apple manpages. Many of them say FreeBSD.
Look at a bunch of Apple manpages. Many of them say FreeBSD.
Bash is GNU and so is much of the dated MacOS userland.
If I recall correctly, much of the MacOS userland is dated because it uses the last GPLv2 releases of various packages before a move to GPLv3.
That's what this thread is about :)
How's using homebrew any of this different than being able to run "base64" and "uuidgen" on Windows? It's not like either of those applications are part of a Windows installation anyway.
That's my point. Why can't Apple ship an updated userland built in, through the Store, or as a download triggered by a command line (like XCode is).
Because GPL v3 says you have to run modified binaries and that means Apple has to give its private keys.
No? You just resign the binary with your key.
I'm sorry, this is totally off-topic but I had to re-read your comment 5 times until it became apparent that you meant re-sign, not surrender. English is funny sometimes (especially when you're not a native speaker like me:) ).
It's a good point; I'll keep it in mind when using the word in the future :)
You can't if the binary is a SIP-protected binary, and you can't use all signing features unless you disable SIP (for certain entitlements AFAIK)
Why do they have to run modified binaries?
Because that's one of the rights users of GPLv3 software have.
I don't believe this to be true, and I don't know where this comes from. Their documented GPLv3 reluctance predated code signing on their platforms by many years. FWIW, GPLv3 was controversial even amongst GPLv2 advocates for all sorts of reasons, never mind amongst actual lawyers. No conspiracy theories required, even if you disagree with their position. The Linux kernel and many other non-GNU projects never updated to GPLv3 and it had nothing to do with enforcing anyone's walled gardens.
Agreed. I think the GPLv3 patent clauses were and are a much bigger problem with Apple legal
Indeed, and there is already a facility to replace code/binaries without signing: disable SIP.
I'd disagree (I agree with the original post). Apache 2 requires a patent grant and I've heard very few instances of this license being avoided (besides the OpenBSD folk). I really do think the fear of GPLv3 comes from the anti-Tivovization requirement -- which would essentially require that 3rd parties (e.g. me) be allowed to install modifications (e.g. modified libs/binaries) of a GPLv3 application onto the controlled iPhone.
[deleted]
This reason doesn't make sense, though: I can modify, replace, and overwrite the bash that comes with the system, and self sign it with a certificate of my choosing.
How do you make a certificate to self sign without going through Apple?
You only need Apple's help if you want to be able to run the binary on another machine without installing your cert on that machine.
Keychain Access should let you do this.
> let users self sign executables
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.
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.
Not at all. You've always been able to run your own software. At worst, it's toggling one option off in preferences that stays off forever thereafter.
Not anymore. Since 10.12 Sierra the GUI option to turn off Gatekeeper is gone, you have to use command line to turn it off. And now App Notarization is making it harder still to run your own software.
GateKeeper only applies to software you download from the internet, and only then in a couple of very specific cases.
How so? I can run anything I like via the command line, and right-click -> Open still launches unsigned executables. Sure there are warnings, but that's not hard to get past.
Only for local administrator user accounts I believe
Sorry, how is that a problem? Users can build and execute code on their own Mac with XCode.
Perhaps Apple's vision for the future is one where you can't do that (ex: App Notarization seems to have us heading in that direction.)
Plus, removing the scripting runtimes in future versions of Mac OS. https://developer.apple.com/documentation/macos_release_note... https://news.ycombinator.com/item?id=20089811
And then who would make software for Apple's platforms? At the end of the day there always has to be a platform that developers can use. You can rest easy; that will never change.
You can run your own code on iPad these days: I don't see this change happening anytime soon.
I don't really understand the licensing issues that well, but if what the poster above you said is true, I wouldn't really want to have to sign software that ships with my computer when it should just run out of the box.
I don't think the prior poster is suggesting that you would have to sign existing software.
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
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
This only seems to be an issue for iOS and its derivatives. You can replace /bin/bash on macOS if you turn SIP off.
I don't understand why GPLv3 would be a problem on macOS.
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.
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.
Did you notice how many qualifiers you had there? The trend on macOS is clear: harder and harder to run/do anything that isn't blessed by Apple.
SIP and Gatekeeper and one-time commands. I find disabling SIP to be much less painful than enabling unsigned drivers in Windows.
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.
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.
It's not a problem, yet. But I would argue that it's quite clear from Apple's actions the last ~5 years that they really want to make Mac OS behave as iOS as much as possible, including making it impossible for regular users to run arbitrary non app store software.
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.
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.
You can't think of a single rational cause for requiring code signing by default other than them wanting to lock down the system? It's a huge security gain for normal users, and helps application developers by encouraging normal users to trust third-party applications rather than being terrified they'll get malware if they install any non-apple software.
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.
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.
I can't think of a single (non-malicious) rational cause for requiring code signing by default and making the requirement impossible for the user to disable.
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.
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.
If there were a simple checkbox in the OS to disable SIP, I would expect zillions of ‘nice’ add-ons would ship with instructions on how to disable it.
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 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 have zero issues with how SIP is currently implemented. It's just hard enough to turn off to protect people, without being overly annoying.
I do worry very much about SIP becoming impossible to disable some day. Don't ban knives because people might cut themselves.
I do worry very much about SIP becoming impossible to disable some day. Don't ban knives because people might cut themselves.
The obvious "rational" security benefits to users are:
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
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
The "You must release changes"-clause and anti-tivoization clause might be not be enough individually to switch to MIT zsh but probably were together good enough reasons for Apple to switch.
Why? How does this affect them on macOS at all?
If Bash were also being used on iOS that would be different, but I'm quite confident that will never happen.
If Bash were also being used on iOS that would be different, but I'm quite confident that will never happen.
Again, perhaps it is because Apple is planning for a future where SIP and Gatekeeper cannot be turned off. A future where macOS is basically reduced/merged to iPadOS. Time will tell.
I expect Macs in enterprise/education are locked down so that Gatekeeper and SIP can't be turned off by normal users.
But preventing ALL Macs from turning off Gatekeeper and SIP? I think that would be unpopular.
But preventing ALL Macs from turning off Gatekeeper and SIP? I think that would be unpopular.
A company or school can already do this easily, by the way, by setting a boot-loader password and restricting admin access. Notably, this are normal macOS functions, you don't need a fancy mtm setup.
That would violate GPLv3, wouldn't it?
I've been building software with Homebrew for ages, where does signing come in?
The default bash on macOS is protected using SIP. Files covered by SIP can only be replaced by Apple-signed updates.
(Of course, one could disable SIP altogether.)
(Of course, one could disable SIP altogether.)
The bash4 from homebrew is installed to a different place to the system bash, and even when you switch to it as your login shell the system bash is still accessible. The homebrew design is never to overwrite system programs but to have same named alternatives higher in $path.
Somehow I don't think GPLv3 presumes that you'll replace system files. And I'm using Homebrew versions of system-bundled utils just fine without overwriting them.
Why is self signing a problem? Keychain Access (macOS's password utility) has allowed this capability for years. It's possible someone could self sign malicious things, but I'd consider that a separate - if related - problem.
I suspect they also recognize that applying the GPL would force them to release things they otherwise consider private.
I suspect they also recognize that applying the GPL would force them to release things they otherwise consider private.
zsh is the default shell on all of my machines because I make it so. I think the tab completions that ohmyzsh provides have saved me on the order of 40 hrs / year, and helped me learn new APIs much easier, since you can see all options without the --help.
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.
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.
Shout out to the fish shell which can do all the fancy syntax highlighting and show command options out the box with no plugins
zsh doesn't require any 'plugins' for its tab-completion, everything you need is distributed with the shell. A lot of people who use zsh just don't understand how it works and think that OMZ/Prezto/whatever are doing something special for them that they couldn't achieve themselves with one line in their .zshrc (or that may even be enabled by default in their OS's global zshrc, as is the case on Ubuntu for example)
Yeah, I went that route before settling into Oh-My-Zsh. The thing is, those single lines add up quick leading to increased mental overhead and time investment.
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.
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.
I agree that zsh's default configuration sucks (and the new-user wizard is overwhelming). I would like the project to provide a more opinionated set of defaults to OS vendors; i think we are probably just nervous about breaking 30 years' worth of expectations, and so far nobody has really pushed for it.
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.
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.
I used fish for a while, but the fact that it is a clear break from bash / sh syntax for things like chaining and redirecting made my reflexes all wrong. I'd type `dothis && dothat` and fish would just say, "umm, I think you mean `dothis and dothat`", or I'd have to use a bash subshell to run some command someone else wrote with some fiddly find syntax piping to xargs. So I just switched to zsh. Less cool name, but my reflexes are once again correct.
They caved and support that syntax now in fish.
While not caving on plenty of others. E.g. errors when a wildcard can’t be expanded (because it is not meant as a wildcard) and you have to explicitly quote. Or (subcommand) instead of $(subcommand). There are more cases I frequently encounter.
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.
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.
I used fish for a while. It was nice but way too many compatibility issues. Zsh is a nice compromise.
IMO compatibility issues are the result of conflating a CLI with a scripting language. If a script was written for bash, run it with bash, not fish or zsh. I can withstand having two shells installed.
You can, but if Fish's value proposition is ease-of-use, then people who can't withstand that need to be able to use fish easily still. Not being able to run `PORT=5000 yarn start` or `make && ./a.out` or whatever snippet you copy-paste from the web without understanding are going to be a big pain point for newcomers to fish.
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.
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 3.0 addresses the common `&&` and `||` operator incompatibility and if you pasted the first snippet it suggests that you should use `env`:
fish: Unsupported use of '='. To run 'yarn' with a modified environment, please use 'env PORT=5000 yarn…'
fish: Unsupported use of '='. To run 'yarn' with a modified environment, please use 'env PORT=5000 yarn…'
They fixed many of those recently. And just in case you have a script that doesn't run, you can install a plugin called `bass` that basically runs them in your native bash without leaving fish.
"Only install that you actually use, otherwise it can slow start time a bunch."
This doesn't make me want to use it.
This doesn't make me want to use it.
Guess they had to go somewhere as Apple's unwillingness to have GPLv3 code effectively killed off bash updates.
Slightly disappointed, but guess they had to go somewhere and zsh is going to be well supported going forward
Slightly disappointed, but guess they had to go somewhere and zsh is going to be well supported going forward
Said the same about zfs.
???
# 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/zshWhat's your ???
That's homebrew, not Apple.
That's homebrew, not Apple.
So? Apple doesn't ship updated packages. It never did. If you want updates, you use a package manager, not Apple's ancient crap. That's life.
> So? Apple doesn't ship updated packages.
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).
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).
Apple stopped shipping updated packages because bash went GPLv3...
Since ZSH is under an MIT-like license, they’ll probably ship updates to it.
Since ZSH is under an MIT-like license, they’ll probably ship updates to it.
The version of /bin/zsh on macOS 10.14.5 is a little over 2 years old. This means they have already been shipping updates to it. Now that it's the default shell they'll probably ship updates a little more frequently (I don't have Catalina installed but I'm guessing its version of zsh is newer than 5.3).
>So? Apple doesn't ship updated packages. It never did.
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.
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.
Apple ships supported, stable packages. Like Debian and CentOS, yes, that means that sometimes you don't get the latest shiny version to play with.
Yeah, like somebody mentioned their awk version is from 2006 and buggy as hell. In Debian the packages are updated at least once in two years. In Apple case it’s pretty obvious that they don’t update anything after they changed app license to GPLv3
Ooh, and they're throwing in dash too!
> 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.
> 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.
It's probably because the default bash is a very ancient version before FSF transitioned to GPLv3. That said, I've been using zsh for a long time and this is a great change.
While Apple is at modernizing their POSIX userland, they should also consider other ancient software they're using. For example, last I looked on Apple's Darwin Open Source site (about a year or two ago), they shipped a really old and buggy awk (nawk) version.
Can we get a modern python version while we're at it?
They're just going to remove it completely:
> 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...
> 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...
> Use of Python 2.7 isn’t recommended. 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 in Terminal. (51097165)
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
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
The open secret to using Python on macOS is to leave the system Python (2.7x) completely alone and install pyenv/pipenv to manage your environments. This will save you a world of pain. Since it's 2019 and I no longer need 2.7, when I run this...
$ 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.
$ 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.
tip: use pyenv instead
I assumed this is licensing decision, with the permissive zsh vs bash’s gpl3
I've never worked outside bash. I have a lot of simple bash scripts. (Usually just stringing together commands with the occasional pipe or output to file)
Will this break all those or are bash scripts and zsh scripts basically interchangeable?
Will this break all those or are bash scripts and zsh scripts basically interchangeable?
As the other person said, if your scripts are executables with an sh or bash 'shebang' at the top, they will continue to use the same shell they always did.
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)
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)
The minor modification would be from `$opts` to `$=opts`.
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.
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.
>As the other person said, if your scripts are executables with an sh or bash 'shebang' at the top, they will continue to use the same shell they always did.
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?)
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?)
If they start with a shebang like `#!/usr/bin/env bash` indicating which shell they are written in, it should be fine.
As all shell scripts should be.
Cool. I have a couple that I forgot to because they're extremely minor (basically just a 4 line set of commands into one) but I can append that easily.
Maybe I'll write a bash script to prep my poorly written bash scripts :D
Maybe I'll write a bash script to prep my poorly written bash scripts :D
I'd recommend to always use just POSIX shell syntax, or at least be aware when you're using bashisms. Bash additions don't buy you much, yet make your script unportable. And using bashisms will get you actually in trouble in practice, since Debian uses dash as default shell, and now Mac OS is using zsh. Considering that shell syntax development has practically ended in 1993, relying on bashisms just isn't worth it.
To be honest I feel like this is throwing the baby out with the bathwater somewhat. If you're writing a script for a system without bash you'll almost certainly know it, so you might as well just put bash in your shebang. I spent a couple of years using #!/bin/sh and avoiding bashisms, but it was literally never useful so I just went back to using #!/usr/bin/env bash.
Of course it goes without saying that you shouldn't use #!/bin/sh then use bash...
Of course it goes without saying that you shouldn't use #!/bin/sh then use bash...
I still fondly remember when tcsh was the default shell. Like a real BSD Unix.
Yes, tcsh was the default in 10.0 then in 10.3 they changed it to bash.
I still not-so-fondly remember when csh was the default shell, on a real BSD-from-Berkeley can't-call-it-UNIX. :-P
It's still in there. The linked article tells how to do it.
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.
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.
And you can use MacPorts or (presumably) Homebrew to install newer versions of tcsh or pretty much any other shell you might want.
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.
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.
Indeed. The point was it was the default shell, being true to its heritage.
[deleted]
I'm really surprised they went with zsh rather than fish. I guess they want to preserve the ability for existing `source` scripts to work.
I think it is mainly because `fish` is incompatible with everything. Most `bash` scripts runs fine in `zsh` (`zsh` has even a `bash` compatibility mode, not necessary generally because rarely `zsh` and `bash` diverges), no `bash` script runs fine in `fish`.
Many of my `bash` scripts run just fine in `fish`, especially since v3 released.
Why would they use fish? Fish is nice and all, but zsh is a much more mainstream shell.
fish was written by an Apple engineer.
fish is friendly.
And interactive.
Since when is mainstream better? Why did they choose zsh? They don't justify that either. It's just odd to pick one post-bash shell but not the other when they have very similar feature sets—autocomplete, persistent global variables, attention to end-user quality.
EDIT: apparently zsh doesn't have persistent or global variables, my bad.
EDIT: apparently zsh doesn't have persistent or global variables, my bad.
Most Terminal users might not even notice the shell changed from Bash to ZSH. Those same users would notice it, had they changed it to Fish.
> Most Terminal users might not even notice the shell changed from Bash to ZSH.
If that's an argument in favor of ZSH, I think I've missed the point.
If that's an argument in favor of ZSH, I think I've missed the point.
It’s an argument in favour of ZSH over Fish. It will cause less disruption, while providing better features than the current default.
> while providing better features than the current default.
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.
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.
The point is that apple don't want to update bash because they don't want to ship software that uses GPLv3 but they also don't want to keep shipping a decade old version of bash as the default shell, they aren't doing this because they want to improve on bash or anything like that.
There's already a lot of community support available for zsh.
Plenty of developers are using oh-my-zsh either for just the plugin support or for the very popular iterm+powerlevel9k+agnoster theming.
Plenty of developers are using oh-my-zsh either for just the plugin support or for the very popular iterm+powerlevel9k+agnoster theming.
Mainstream is often better in terms of unofficial support/learning resources, and by definition better in terms of familiarity/market share. For something like a shell, forcing a niche choice needs justification when it's not clearly better than the alternatives.
Fish is clearly better than the alternatives.
Well, fish is not compatible to bash. Users would suddenly face bash-one-liners that they find on StackOverflow to stop working.
It's really annoying to have to learn new language when zsh is so similar to bash.
It's really annoying to learn bash, so I don't see how that works in zsh's favor.
To be honest I'm hesitant to respond to you because of the level of spittle-flecking you're doing in this thread but I would guess that, by virtue of bash being the standard Mac shell and zsh being a close-enough-but-better replacement, the necessary learning has already happened and overwhelmingly more Mac terminal users will be at least functional with it immediately.
Not the OP, but I agree with both of you actually. It's easier in many ways to run a POSIX-compliant shell with a more "familiar" scripting language to bash users (especially when it comes to running existing scripts or one-liners you find online).... buuuut at the same time I think it's pretty clear that fish's scripting language is much more modern and "better" in many ways.
I don't write shell scripts for nontrivial things and it's rare that I see a good reason to, so I'm not sure that moves the needle much. It's 2019, we have other scripting tools, etc.
Hmm, I see your point, but on the other hand: is that really a good reason to continue the status quo of shell scripting if there are improvements to be made?
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.
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.
I really like fish and had a pretty good run using it, but I have found myself on zsh for quite a few years - it’s just less friction to go with the herd on this particular part of my toolbox
As MacOS is a certified Unix, like the workstations of days gone by, they should've gone all out enterprise and switched to ksh.
Heck, the new Mac Pro is even priced like a SGI/AIdX box.
Heck, the new Mac Pro is even priced like a SGI/AIdX box.
Exactly, compatibility. fish has a somewhat different syntax to bash.
[deleted]
as far as i know !! does not work on fish, which means it's dead in the water (had to) as far as i'm concerned.
Discussion on the topic: https://github.com/fish-shell/fish-shell/issues/288
And, a omf plugin if you want: https://github.com/oh-my-fish/plugin-bang-bang
And, a omf plugin if you want: https://github.com/oh-my-fish/plugin-bang-bang
zsh is better than bash in nearly all aspects, at least in my use cases, so this is a great news for me. Is there anything that can be done in bash but not in zsh?
I've been using zsh on Linux for years (4 at least). I was creating a function that I wanted to run in zsh and bash and I think I ran into some option that was available on a builtin command in bash that wasn't on the zsh version. I can't remember the details though, because it was a while ago. I imagine if someone deals with shell scripts more regularly than I do they would run in to those kind of problems more than me.
zsh isn't a perfect super-set of bash (there are some differences in syntax, provided built-ins, &c.), but it does have equivalents for most of bash's functionality. Off the top of my head i can't think of anything useful that it's missing. People may have subjective preferences for e.g. readarray over parameter expansion, but the functionality is all there. I suppose it doesn't (and probably never will) fully conform to POSIX, if that's important to you
The only thing I noticed in 10 years of zsh use is
that `printf "%b\n"` can be used in bash but not in zsh to unescape C-style strings: E.g. `printf "%b\n" '\"abc\"'` ==> "abc"
No, I think zsh is strictly more feature rich at the cost of a little more memory (like 1MB maybe). For macs this should be irrelevant.
From 2012 - Apple's great GPL purge: https://news.ycombinator.com/item?id=3559990
Short-sighted move considering Microsoft is actively looking to ship a Linux kernel in Windows.
Short-sighted move considering Microsoft is actively looking to ship a Linux kernel in Windows.
Maybe I’m imagining things, but wasn’t zsh also the default until MacOS 10.4 or so?
Edit: I was misremembering things. tcsh until 10.3.
Edit: I was misremembering things. tcsh until 10.3.
zsh was the default sh until OS X 10.2 or 10.3. However, the zsh version was quite out of date (3.x when 4.x was already mature/stable, IIRC). A horse race between the old zsh and the latest bash was jiggered to show bash as much faster, and therefore worth switching to, never mind that the then-current zsh demonstrated performance parity with bash.
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.
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.
Fantastic! Any time I get a new mac I install homebrew ZSH and edit /etc/shells to add it in.
macOS already ships with zsh, and has done so for years, it’s just not the default shell. Unless you want to always have the very latest version of zsh, you don’t need to install it with homebrew.
Had no idea they were shipping zsh in newer versions. Neat! Wonder why they don't do Bash 4.x.x+ versions by default. Or, do they?
For the uninitiated: why is zsh better than bash?
The uninitiated won’t notice much of a difference, and that is bound to be the point. Bash on macOS is stuck at version 3 due to licensing reasons (GPL3), while ZSH is not (MIT).
For even more historical context, macOS originally shipped with tcsh. We've already done the shell transition once, and basically nobody noticed.
That wouldn’t have broken as much, since everyone’s scripts would have a bash or sh shebang line on top. Changing what /bin/sh points to is a much riskier change.
Is that what they've done? The linked article doesn't say that.
$ /bin/sh --version
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin19)
Copyright (C) 2007 Free Software Foundation, Inc.You can change this by pointing /var/select/sh .
A couple of the things that make it much better for me are plugins: zsh-autosuggestions and zsh-syntax-highlighting. I think those are both fish-inspired, but getting those features in a bash/posix-compatible shell is the best of both worlds.
Tab autocompletion, especially for command-line flags, is great. Try it out with 'ls -<TAB>' and you'll see all the options and a description. The z command to cd to common directories without typing the full path seems useful, but I've never gotten it to work.
You can setup command-line flag completion in bash as well. For example, on my Linux systems I have this line in my .bashrc to autocomplete systemd unit file names for when I run systemctl:
complete -W "$(systemctl list-unit-files|cut -f1 -d' '|tail -n+2|head -n-2)" systemctl
It has a ton of great features, but my favorite is definitely the improved tab completion.
It runs slower, so it helps encourage you to buy more expensive hardware.
If your hardware cost is driven by the performance of your shell, I question what you're doing with your terminal emulator.
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.
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.
Git completion is unbearably slow for me in zsh, but fine in bash. It is a very large repo I work on, but we're talking 10s vs instant. I still use zsh though because it's nicer in other ways.
Check your Zsh theme. Zsh has no built-in support for git status, so themes that show git status are implementing this by themselves. One way to make this slow is to check git status synchronous, however there are ways to do this asynchronous that should be instantaneous (at the expense of showing git status later).
Btw, Bash is the same. So you just said that someone that implemented your Bash theme did better than in your Zsh theme.
Btw, Bash is the same. So you just said that someone that implemented your Bash theme did better than in your Zsh theme.
I'm taking about tab completion when entering commands, not a theme that is displaying my status anywhere. I didn't even know "themes" existed.
Your point probably stands that it's more to do with the completion scripts rather than the shells themselves though.
Your point probably stands that it's more to do with the completion scripts rather than the shells themselves though.
There are absolutely some things slower in zsh/bash. Are any of those slow because of a non-upgraded machine ("they would run fast on a $50k server" doesn't count)? Or, as others in this thread have pointed out, are they slower because of flawed implementations which, unless fixed, will always be slow on any hardware?
I use Fish. So not an exciting news for me.
I use Fish too :) And I haven't really connected with zsh. I've tried. However I think this is good news for Fish too. It's the beginning of a long-overdue un-Bashifying.
I switched to ZSH a few years ago because some of my coworkers were using it. I never found it useful enough to use it over Bash. So I switched back to Bash. I’d rather have the shell be identical to the one running on the servers I use.
As a happy zsh user, I'm glad that this will finally force every application and software package in the world to stop assuming that bash is the default (and only) shell.
Finally!
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”.
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”.
I had trouble updating iTunes once because my shell was set to zsh, and it took me quite a while to debug what went wrong. I recommend that when this switchover occurs, users should temporarily switch to bash if they encounter an installer that does not work.
I've noticed that sometimes there's oddities with zsh & homebrew or rvm that force me to drop into bash in order to run a command. With apple standardizing on zsh, that should finally resolve these bugs.
zsh users, good time to try out my favorite prompt, Pure: https://github.com/sindresorhus/pure
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).
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).
I’m only familiar with working in bash and bash scripts. What do I need to know about the differences with zsh?
oh crap. Yet another outdated package bolted into the OS.
Any beta testers here able to confirm whether Terminal.app supports True Color now?