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.
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.
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]
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.
> 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)...
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?
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.
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.
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.
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.
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.
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.
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.
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 :)
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 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.
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.
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'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'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.
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.
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...
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.
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:) ).
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.
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.
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.
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 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.
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.
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.
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 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.
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.
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.
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.
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.
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
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.
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.
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.
IANAL, but I really don't think so. On a company laptop, the company owns the laptop, and the company can lock it down as much or as little as they want.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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
> 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.
> 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.
> 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
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.
I don't need to run python 2, I'd rather just have the system manage a moderately recent version of python rather than rely on things like pipenv and brew.
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?
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)
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.
>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 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
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...
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.
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 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`.
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.
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.
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.
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.
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
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"
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.
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.
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).
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.
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:
Bash also allows you to cd to common directories, but again, you have to set it up. You set the CDPATH variable to one or more paths, and then you can cd to relative subdirectories without typing out the absolute path.
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.
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.
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 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.
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.
Can't answer that but on a related note, recent zsh fully supports true color. You could always use it in things like prompts with literal escape sequences but it'll also work for syntax highlighting etc and interpret colours in hex triplet form for you now.
