Heads up for admins, zsh in now default shell for macOS Catalina

garybidwell
Contributor III

Just a heads up as it wasn't in the main presentation yesterday, but bash is no longer the default shell for macOS

https://support.apple.com/en-us/HT208050

49 REPLIES 49

coachdnadel
Release Candidate Programs Tester

I've been reading about and practicing my bash-fu for the past year. How big of a compatibility issue are we talking about? This seems like a really big deal, but I don't want to over react.

ryan_ball
Valued Contributor

It's not that big of a deal, it can be changed.
http://osxdaily.com/2012/03/21/change-shell-mac-os-x/

CSCC-JS
Contributor III

There also giving the warning sign of bash being depreciated latter, similar to 32bit.

ryan_ball
Valued Contributor

Well that is a bigger deal.

cwaldrip
Valued Contributor

@ryan.ball An even bigger deal is (per Krypted.com) scripting languages such as Python, Ruby, and Perl are all being deprecated. Not gone in 10.15, but deprecated... so the writing is on the wall.

Repeat after me... security is your friend, citizen. freedom is slavery. we have always been at war with... Eh. I never spent much time with those and it almost makes sense in the name of security. But it's going to suck to go through all my scripts and find my bits and pieces of perl and python.

Hugonaut
Valued Contributor II

this is beginning to get crazy -_-

________________
Looking for a Jamf Managed Service Provider? Look no further than Rocketman
________________


Virtual MacAdmins Monthly Meetup - First Friday, Every Month

allanp81
Valued Contributor

In theory, for the time being, as long as your scripts have the appropriate shebang it shouldn't be a problem.

CorpIT_eB
Contributor II

So what does this mean that every script written in Bash,Shell is going to break and no longer work?

I guess i see JAMF NATION working in overtime in the near future.

allanp81
Valued Contributor

@CorpIT_eB In theory your scripts will be fine as long as your shebang is set right (and that Apple haven't removed that shell!).

mschroder
Valued Contributor

@cwaldrip This is a VERY bad sign. For us OS X became very useful due to the unique mix of the underlying BSD including all the possibilities to do scripting, the nice GUI including office apps and the development environment. If Apple really prohibits shell scripts and all widely used scripting languages the Macs will become much less useful. We don't need iPad+'ses, we need real computers. No scripting = no point to buy a Mac.

allanp81
Valued Contributor

Nothing to stop you from installing Python and Ruby etc. during provisioning. I would imagine the change is due to the versions bundled and their licensing terms are no longer compatible so Apple are just dropping them instead of having to agree to different licensing terms.

cwaldrip
Valued Contributor

@allanp81 that's my guess too. Apple can't try and test and keep the various scripting languages up to date. And too many people just use what's installed. I'm surprised Apache is as current as it is for example. Apple doesn't bundle Java anymore, but you're free to install it and use it.

As for existing scripts, as long as the scripting language is installed then your scripts will work. Converting bash to zsh doesn't seem too hard, just annoying. But relying on those others will mean you'll have to add them to the machine at imaging time. And that's going to be a PITA.

tlarkin
Honored Contributor

the version of zsh that Apple ships is modern, and bash 3.2 will never be updated nor patched because it is GPLv3. Honestly, zsh is pretty good and I have been tinkering with it and using it for a few years now. This isn't even a surprise to me. The efforts to migrate code from bash to zsh should be pretty minimal. Also, I doubt they will kill bash anytime soon because internals rely on it. However, I would definitely look at adopting zsh moving forward.

My 2 cents

-Tom

CSCC-JS
Contributor III

I've switched my default shell to zsh, and now testing any new scripts as #!/bin/zsh to see if they work as intended. (edit) As well working with any normal command line I use in zsh to see the effect.

Will start testing older scripts, and picking up this book "From Bash to Z Shell: Conquering the Command Line by Kiddle, Oliver" Any suggesting for other good books on zsh?

tnielsen
Valued Contributor

Thanks

CorpIT_eB
Contributor II

What sucks is that we use the code and technique that @haircut wrote about here: Automatically Renaming Computers from a Google Sheet with Jamf Pro that works flawlessly except we use an internal iis server instead of Google drive.

We love it having to come up with another solution for computer naming breaks my heart.

TimArnold
New Contributor II

If python is removed for good, the Mac Admin community will need a new recommended way of finding the currently logged in user.

Most everyone I know runs MacMule's command to gather the user.

koalatee
Contributor II

This method works fine in zsh

tlarkin
Honored Contributor

You should look at shipping your own Python, Perl, and Ruby as well if you want to use those languages. Apple is likely to stop shipping those.

tlarkin
Honored Contributor
Posted: Today at 3:58 PM by koalatee This method works fine in zsh

Those should work, as that isn't a part of bash, but that is a part of the scutil binary. All binary I/O will work fine in zsh it is only the built ins and possibly very minor syntax changes that you may run into.

gachowski
Valued Contributor II

I'm not too clear on Apple's NDA rules....so I am chicken to post details. However, from my 1st test Catalina enrollment .. I think there are more pressing and bigger impacting issues. I would hope that everyone here is testing and filling bugs. That said with Apple making changes whenever they feel like it, it's not to hard to see that some of the issues will change over the next few months.

C

mschroder
Valued Contributor

@allanp I don't really see shipping own versions of python, perl ruby etc as a solution. We are a BYOD environment, almost everything on our site is done via the Self-Service. If there is no more perl, python ruby etc shipped by Apple I can not assume anything about the presence or the version of these. It will be a mess.

And there is another issue that worries me a lot. Apple is closing off more and more areas of the OS. Good for security, very bad for people that use plenty of scripts and home grown software. Before OS X came along it was VERY difficult to script/program the Mac, and Mac usage here dropped significantly. OS X (now called macOS) opened up the Mac and made it a much more useful tool. Now Apple is restricting it more and more, and the usefulness of the Macs will decrease again.

allanp81
Valued Contributor

@mschroder To be honest if it meant we had to drop the macs then it would be a good thing anyway, can't stand them!

ryan_ball
Valued Contributor

There are lots of things that are and have been depreciated in macOS/OSX for quite a while, but are still baked into the OS.

tnielsen
Valued Contributor

@mschroder I talked to an Apple engineer recently, 2 weeks ago roughly, and he told me that Apple is advising customers to "move away from scripting".

That shocked me. I immediately knew what they would move to, though. They want admins like us to be nothing more than 3rd party tool users, like JAMF or... dare I say it... Apple's new management tool. I believe apple is going to start offering companies direct access to MDM and configuration profile controls just like JAMF gives us. Apple will give the keys to options they decide we can change; the implementation will be left to Apple. We simply flip the switches.

Their goal with this is, less support and more control for Apple. Sad times imo. Sad times.

tlarkin
Honored Contributor
I talked to an Apple engineer recently, 2 weeks ago roughly, and he told me that Apple is advising customers to "move away from scripting".

This is just laughable, and 100% inaccurate. I would say, there is little stock in what the Sales Org at Apple can say to a customer, let alone what they really know roadmap wise. It would break internal macOS things losing the ability to execute code.

@mschroder

I don't really see shipping own versions of python, perl ruby etc as a solution. We are a BYOD environment, almost everything on our site is done via the Self-Service. If there is no more perl, python ruby etc shipped by Apple I can not assume anything about the presence or the version of these. It will be a mess.

There are still plenty of ways to tackle this issue. You have to enroll your BYOD device to even get self service. There are tons of options.

In the end none of these changes should shock you. The last time I inquired about Python 3 (which was about 3 years ago) Apple sent me a link stating you should ship your own third party languages. The writing on the wall has been there for some time. I found a neat tool that makes shipping Python super easy.

Bash 3.2 is old and janky compared to all new and modern shells. Bash 4 is GPLv3 and every corporation out there hates that license, so they refuse to use it. Over the past 3 years Apple has consistently shipped a very new and modern version of zsh . I guessed this even before I officially knew.

These are good changes, it forces us to use best practices and modern tech. Relying on system libs is not always the best practice and the only thing it gets you, is not shipping your own.

CorpIT_eB
Contributor II

@tlarkin

I found a neat tool that makes shipping Python super easy.

Can you post which tool you found and have you personally tested it?

What where your results?

sdagley
Esteemed Contributor II

Having been on the wrong end of more than one Qualys scan flagging a Mac server for an old version of tool X because Apple had stopped updating that generation of Mac OS (some G5 Xserve systems had a looooong life) I definitely see an upside of decoupling these things from macOS itself. Nothing in Apple's announcement makes me think they're planning on eliminating our ability to utilize different scripting languages. They're just not going to be responsible for making them available. Kind of like how they stopped being responsible for Java on the Mac (and I've been doing this long enough to remember when they created Macintosh Runtime for Java so there was a decent Mac JVM)

scottb
Honored Contributor

Apologies if these exist here already. Some cool stuff in zsh, but all this new stuff flying in from Apple is hard to keep up with:

bash vs zsh

Apple-HT208050

Some good bits to start...

garybidwell
Contributor III

I’ve hardly had time yet to go through any of the WWDC sessions yet but Robert Hammen has posted a good summary of Catalina changes for admins to be aware of, including links to all the post Charles Edge & Rich Trouton have made (some links require Dev access)

https://medium.com/@hammen/significant-changes-in-macos-10-15-catalina-of-interest-to-mac-admins-fbc3865c055e

gabester
Contributor III

@tnielsen That's a "DO NOT LIKE / BUT I AGREE" - Apple's become very much about not enabling independence but monetizing dependence, so this is the direction I fear things are headed.

@tlarkin Your input is always appreciated - I hope your level head and cooler attitude prevail. I could see "removing scripting capabilities" as Apple's answer to Windows 10S to improve security at the expense of usibility.

We're already internally updating what built in scripting components we can; I had to add a step to update ruby in our builds a few months ago, @sdagley thanks to a Qualys scan.

sdagley
Esteemed Contributor II

@Sterritt That's kind of my point - if you're getting dinged on the version of the components you have deployed being out of date it's better it's under your control to update them rather than a bandaid to address the issue while hoping Apple will eventually release an official fix.

Judah_V
New Contributor II

Very important line at the bottom of this support article that will probably will keep most your old scripts functioning properly. Admittedly I have not tested it.

zsh can be made to emulate sh by executing the command zsh --emulate sh

ryan_ball
Valued Contributor

Everything from grep to rsync is already way out of date on a Mac.

tlarkin
Honored Contributor

@CorpIT_eB yup here ya go

relocatable-python

I already shipped out a test run to a bunch of Macs after testing it locally. So far no issues, and I even shipped requests with it.

@Sterritt ya I get the ideas that people are coming up with. The fact that macOS relies on a lot of scripts to function tells me we are a ways off from that. Plus, it would kill the Mac as a viable development computer and that would only hurt Apple. You can ship embedded languages in apps, so you need a computer that can run it. They most definitely might make it harder, but I think Apple just wants to get out of the biz of shipping third party libs and languages and leaves it up to us. Also, if you haven't seen, Windows 10 can install Python 3 natively now from their app store. So, even Windows is on that now.

tlarkin
Honored Contributor

@sdagley yeah you gotta watch those vuln scanners though. Point in case, I had one for a 10.12 version of open SSH not too long ago. The CVE was enumeration and the only thing it got you was the username, which isn't even really a risk if you use keys, and MFA. Anyone trying to attack your company specifically can go to LinkedIN, find the IT or dev or whatever, and figure out that their user name is a combination of the standard naming conventions.

A lot of times security won't vet that stuff, they will just tell you to patch because some vuln scanner said there is a CVE. In reality, if a vuln isn't going to bankrupt your company it isn't critical, but still should be patched.

Apple did not patch this at all in 10.12, but they did in 10.13+. I used it as an excuse to get rid of 10.12 boxes in my fleet.

tlarkin
Honored Contributor

everyone should watch this

macOS security enhancements

scottb
Honored Contributor

Interesting that the date for Notarization is June 1, 2019 and not the previous date (April 7th?)...
Thanks for the link, @tlarkin

tlarkin
Honored Contributor

the take away from that keynote is that "all code must be signed in a future release of macOS"