You can make a difference in the Apple Support Community!

When you sign up with your Apple Account, you can provide valuable feedback to other community members by upvoting helpful replies and User Tips.

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Why is this necessary or is it not required?

I recently received a notice asking for me to switch to "zsh" and to visit "https://support.apple.com/kb/HT208050". I did and now less than I did when I started. Can someone explain in plain language why this is necessary?

iMac 27″, macOS 10.13

Posted on May 29, 2020 2:43 PM

Reply
Question marked as Top-ranking reply

Posted on May 30, 2020 7:17 AM


Unless you live in the Terminal (or maybe spend a moderate amount of time there), it is not all that important an issue.


Way back when (we are talking the '60's and '70's), when a terminal was a physical device with a keyboard and either a paper roll (teletype), or a CRT screen and a serial port on the back that was hard wired to the computer or connected via a dial-up modem, and a computer with 64K (65,536) bytes of memory was a big computer.


Individual commands were separate programs. The 'shell' was a program that would give you a command line prompt, accept what you typed, look at the first word, search a set of directories (using the PATH environment variable) and see if it could find a program with that name. If the shell found a program with that name, it started a sub-process and runs the program in the sub-process, passing the rest of the arguments on the command line to the program.


The 'shell' was basically a thin layer between the user and the programs the user wanted to run. And with computers having less than 64K of memory, the shell could not be be very thick. And individual programs could not be very complex.


Another service the early shells provided was called a 'pipe' and on the command line it is a vertical bar |


The pipe service allowed the shell to start several commands in sub-processes and connect the standard output from the first command into the standard input of the second command. And if you added extra pipes to the command line, then the 2nd commands stdout into the 3rd commands stdin, etc...


This allowed simple programs to perform operations in stages. The classic example was a rude and crude spell checker.

  • command that reads a user's text file, and changes all white space, numbers, and special characters into newlines, so you had either blank lines or 1 word per line
  • the output from that was passed to a sort utility so all the lines were alphabetized.
  • the output from that was passed to a program that looked at adjacent lines, and removed duplicates
  • the output from that was passed to a program that would compare it to an alphabetized list of correctly spelled words. Since both lists were alphabetized, it could walk each list and when the list to be spell checked is compared to a correctly spelled word that was alphabetically higher than the to be checked word, the program knew the to be checked word was not in the list of correctly spelled words, and would spit it out as misspelled.

Each of these programs is very simple, and the shell glued them all together.


And because the shell was just a program, and nothing special, it can be changed. In the early days there were a lot of shells, but they settled down to 'sh' (the Bourne shell, written by Steve Bourne), and the 'csh' (the C-Shell because it tried to follow the C programming language, and because it had a better user interface).


Later ksh (the Korn shell written by David Korn) came along and it had improvements on the Bourne shell. And the csh got a younger more capable brother tcsh.


bash (Bourne Again Shell; because programmers like inside jokes), was an open source shell, and because it had a much larger contributor base got both user interface improvements that made it better than csh and tcsh, plus shell script programming improvements that made it better than 'sh' and 'ksh', such that for a while the world settled into 'bash' being the dominate shell.


But zsh and a few other shells were out there, growing in popularity, and because the internet makes it easy for others to contribute, zsh has some bells and whistles that bash does not. But bash is still dominate.


Then Richard Stallman decided he did not like commercial software companies using the FSF software unless they were willing to make all of their source code freely available, if they wanted to ship any of the FSF software (and there is a lot of good FSF software, bash being one of them).


Apple, and IBM, and Oracle, and Microsoft, and every other operating system vendor is NOT going to do that. We are talking about every bit of software shipped as part of macOS being open sourced. And some of that software has licenses from other companies. The legal nightmare that would cause would be huge.


So Apple decided that it would switch to zsh. zsh does not have the Richard Stallman GPLv3 license, and it does not impose the kinds of restrictions GPLv3 licensing does.

5 replies
Question marked as Top-ranking reply

May 30, 2020 7:17 AM in response to bbc_glc


Unless you live in the Terminal (or maybe spend a moderate amount of time there), it is not all that important an issue.


Way back when (we are talking the '60's and '70's), when a terminal was a physical device with a keyboard and either a paper roll (teletype), or a CRT screen and a serial port on the back that was hard wired to the computer or connected via a dial-up modem, and a computer with 64K (65,536) bytes of memory was a big computer.


Individual commands were separate programs. The 'shell' was a program that would give you a command line prompt, accept what you typed, look at the first word, search a set of directories (using the PATH environment variable) and see if it could find a program with that name. If the shell found a program with that name, it started a sub-process and runs the program in the sub-process, passing the rest of the arguments on the command line to the program.


The 'shell' was basically a thin layer between the user and the programs the user wanted to run. And with computers having less than 64K of memory, the shell could not be be very thick. And individual programs could not be very complex.


Another service the early shells provided was called a 'pipe' and on the command line it is a vertical bar |


The pipe service allowed the shell to start several commands in sub-processes and connect the standard output from the first command into the standard input of the second command. And if you added extra pipes to the command line, then the 2nd commands stdout into the 3rd commands stdin, etc...


This allowed simple programs to perform operations in stages. The classic example was a rude and crude spell checker.

  • command that reads a user's text file, and changes all white space, numbers, and special characters into newlines, so you had either blank lines or 1 word per line
  • the output from that was passed to a sort utility so all the lines were alphabetized.
  • the output from that was passed to a program that looked at adjacent lines, and removed duplicates
  • the output from that was passed to a program that would compare it to an alphabetized list of correctly spelled words. Since both lists were alphabetized, it could walk each list and when the list to be spell checked is compared to a correctly spelled word that was alphabetically higher than the to be checked word, the program knew the to be checked word was not in the list of correctly spelled words, and would spit it out as misspelled.

Each of these programs is very simple, and the shell glued them all together.


And because the shell was just a program, and nothing special, it can be changed. In the early days there were a lot of shells, but they settled down to 'sh' (the Bourne shell, written by Steve Bourne), and the 'csh' (the C-Shell because it tried to follow the C programming language, and because it had a better user interface).


Later ksh (the Korn shell written by David Korn) came along and it had improvements on the Bourne shell. And the csh got a younger more capable brother tcsh.


bash (Bourne Again Shell; because programmers like inside jokes), was an open source shell, and because it had a much larger contributor base got both user interface improvements that made it better than csh and tcsh, plus shell script programming improvements that made it better than 'sh' and 'ksh', such that for a while the world settled into 'bash' being the dominate shell.


But zsh and a few other shells were out there, growing in popularity, and because the internet makes it easy for others to contribute, zsh has some bells and whistles that bash does not. But bash is still dominate.


Then Richard Stallman decided he did not like commercial software companies using the FSF software unless they were willing to make all of their source code freely available, if they wanted to ship any of the FSF software (and there is a lot of good FSF software, bash being one of them).


Apple, and IBM, and Oracle, and Microsoft, and every other operating system vendor is NOT going to do that. We are talking about every bit of software shipped as part of macOS being open sourced. And some of that software has licenses from other companies. The legal nightmare that would cause would be huge.


So Apple decided that it would switch to zsh. zsh does not have the Richard Stallman GPLv3 license, and it does not impose the kinds of restrictions GPLv3 licensing does.

May 29, 2020 3:57 PM in response to bbc_glc

In the beginning Mac OS X 10.0 used tcsh as the default shell.


Mac OS X 10.3, they changed to the bash shell (Bourne Again Shell; in honor of the original Bourne shell author Steve Bourne). This switch was because the bash shell was a better shell than tcsh, and it was also POSIX compliant.


With Catalina, Apple is switching the default new account shell to zsh, and asked existing users to switch as well. This switch is more about the FSF (Free Software Foundation) and Richard Stallman's dislike for commercial software companies, especially companies that use FSF software. So the older friendly GPLv2 license was replaced with the poisonous GPLv3 license. This prevented Apple from shipping newer 'bash' versions, thus macOS was stuck with bash version 3.2.57 (still using GPLv2), and the rest of the world had access bash version 5 with bug fixes and feature improvements.


Apple needed a way to provide bug fixes and improved shell features, if for no other reason, than their own developer often use the Terminal environment.


The zsh shell DOES NOT have a GPL license, it is still being developed, it has most of the bash features, and some more of its own, and Apple is able to ship zsh versions without legal complications.


If you prefer 'bash', you can continue to use the 3.2.57 version, or you can use HomeBrew <https://brew.sh> and install a newer version, or even get and compile your own bash sources.


And you can add

export BASH_SILENCE_DEPRECATION_WARNING=1

to your .bash_profile (unless you are a .profile user), and that will keep macOS from complaining about zsh.

May 30, 2020 6:11 AM in response to BobHarris

What is a "shell" in regards to a computer? I've trusted MAC with all there upgrades and etc simply because I enjoy the simplistic use of the multiple operations, but now it is becoming more complex and difficult to understand. Maybe I really don't want to know and go along my blissful way not caring and only trusting Apple.

Why is this necessary or is it not required?

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.