Using the shell (Terminal) in Mac OS X

To change your login shell, open Terminal and type the following command, pressing Return after each line:

After running chsh, you’ll be prompted for your account password. When it asks whether you want to log out to complete the change, you can simply close the Terminal window and reopen it, or log out from the Apple menu and log back in. When you open a new Terminal window, the prompt should now read macbook:~ username% and the shell type will be bash. You can confirm this by typing:

This will print /bin/bash if everything went correctly. If you still see /bin/tcsh, you may need to tweak the environment manually. Create a .bash_profile in your home directory with the following content to force the shell variable:

Next, create a .bashrc file to set your PATH, define aliases, and override the shell again:

With these files in place, each new Terminal session will load your custom PATH and aliases automatically. The PATH adjustment ensures that executables you install locally (for example, via Homebrew or manually in $HOME/bin) are found before the system defaults. The aliases are convenient shortcuts that make the command line feel more like the Finder for newcomers.

At this point you have a fully functional Bash environment. If you prefer to experiment with other shells, macOS ships with ksh and zsh as well. However, Bash remains the safest bet for scripting, because the majority of community resources and open‑source tools target it. The rest of this guide focuses on getting the most out of Bash, while still respecting macOS’s unique characteristics.

Managing User Shell Settings Through System Tools

Beyond the command line, macOS provides a few graphical tools that let you tweak the default shell and other user attributes. These tools are especially useful for administrators or for users who prefer a GUI over typing commands. The most common is NetInfo Manager, which manages user accounts, group memberships, and login settings across the entire system.

Launch NetInfo Manager from Applications → Utilities. If the domain “/” is not already displayed in the sidebar, click “Open” and select it. You’ll see a tree of system information, including Users, Groups, and Services. Click the little lock icon in the lower left corner; you’ll be prompted to enter your admin password. Once authenticated, the tree becomes editable.

Navigate to Users → your username. Double‑click the “Shell” field and change it from /bin/tcsh to /bin/bash. Press Return to confirm. If you have other users you manage, repeat this step for each account that needs Bash. After you’re finished, close NetInfo Manager. The change takes effect the next time you log in; for an immediate effect, simply log out from the Apple menu and log back in.

It’s worth noting that macOS does not rely on the traditional /etc/passwd file for login authentication. Instead, it uses NetInfo or, in newer macOS versions, Directory Services. That’s why changes made through NetInfo Manager do not update /etc/passwd even though the file still exists. You can verify that /etc/passwd still lists your user, but the active login shell is now Bash.

Another quirk of macOS is that the default Terminal session remains open when you log out of the GUI. The window simply closes, but the shell process continues running in the background until you close the Terminal explicitly. If you prefer the shell to exit automatically, go to Terminal → Preferences → Window and check the option “When the shell exits: Close the window.” This setting helps keep the desktop tidy, especially when you’re working on multiple projects in separate Terminal windows.

Case sensitivity in macOS file names can be confusing, especially for users coming from other Unix systems. By default, macOS file systems are case‑insensitive but case‑preserving. That means you can create a file named ReadMe.txt and later create readme.txt without conflict, but the system will treat the names as identical for most operations. For example, mkdir appl followed by cd Appl will succeed, but the shell might warn you that appl already exists when you try to run mkdir Appl. Wildcard patterns, however, remain case‑sensitive unless you explicitly use the shopt -s nocaseglob option in Bash. This behavior can cause subtle bugs when porting scripts from strictly case‑sensitive systems, so keep an eye on file names that differ only by capitalization.

When you need to perform administrative tasks from the command line, you have a few options. The sudo command is the most common: prefix any command you want to run as root with sudo, and you’ll be prompted for your user password. For more privileged actions, you can enable the hidden root account via NetInfo Manager (Security → Enable Root User). Once enabled, you can log in as root using the console login at the boot prompt or by selecting “Other” in the login window and typing root as the username. This root session opens a new Terminal window that is already running as the superuser, giving you direct access to system files.

Another powerful, albeit more advanced, option is to boot into single‑user mode. Hold Command + S during startup to drop into a minimal Unix shell that runs as root. This mode bypasses the graphical login, gives you full control over the file system, and is often used for system repair or emergency maintenance. The single‑user shell is essentially a stripped‑down Bash environment, so the commands you use there are the same as on a regular Terminal session.

Finally, macOS schedules maintenance tasks in three scripts: /etc/daily, /etc/weekly, and /etc/monthly. These scripts handle tasks such as rotating logs, updating system caches, and cleaning temporary files. They run automatically at odd hours to avoid interfering with normal user activity. If you want to force them to run immediately - for example, after installing a new package - you can execute them with sudo /etc/daily, sudo /etc/weekly, or sudo /etc/monthly. Running these scripts manually is rarely necessary, but it can be helpful for troubleshooting or ensuring that background maintenance has completed before you perform a critical operation.

Working with Mac File Formats and Unix Utilities

macOS blends a classic Unix core with a rich graphical interface, and that hybrid nature shows up in how files are stored and handled. One of the most visible differences is how line endings are represented in text files. The Finder and many macOS applications use carriage returns (CR, \r) to terminate lines. Standard Unix tools, however, expect a line feed (LF, ) as the only line separator. If you open a file saved with CR endings in a Bash script or when you transfer it to a Linux machine, you’ll see odd control characters or the entire file appear as a single line.

Fortunately, converting between CR and LF is straightforward. If you prefer to work in a terminal editor, vi or its successor vim can perform the conversion in place. Open the file:

Once inside, type : to enter command mode, then enter the following substitution command:

Press Return to execute the command; all carriage returns are removed from the file. Finally, type :wq to write the changes and quit. If you prefer to use a simple one‑liner, tr does the job as well:

Copy the converted file back if you wish, or rename it. Most text editors on macOS now handle Unix line endings automatically, so new scripts created with Xcode, Sublime Text, or Atom will be fine out of the box.

Another macOS idiosyncrasy involves the old Mac OS concept of data and resource forks. Traditional macOS applications store metadata such as icons and menu definitions in a separate resource fork, which standard Unix file operations ignore. When you use the simple cp command, only the data fork gets copied. For files that rely on the resource fork, macOS supplies the cp mac (or cpmac) and mv mac (or mvmac) commands. These utilities preserve both forks, ensuring that the copied file behaves identically to the original. In most modern workflows, however, the resource fork is rarely used, and plain cp suffices.

When you run scripts on macOS, keep in mind that most of the community’s scripting resources target /bin/sh, /bin/bash, or /bin/ksh. The syntax differences are minimal, so you can port scripts from Linux with little adjustment. A common pattern is to start the script with a shebang that points to Bash:

This line tells the system to execute the script with Bash, regardless of the user’s default shell. If you need to support older shells, you can write portable scripts that use only POSIX features and avoid Bash extensions.

Finally, consider installing a package manager such as Homebrew (brew install) or MacPorts (port install) to bring additional Unix tools to macOS. These managers place binaries in /usr/local/bin (or /opt/local/bin for MacPorts), which your earlier PATH adjustment already includes. With Homebrew, you can quickly install GNU utilities that differ from the BSD variants shipped with macOS, such as findutils, gnu-sed, or gnu-awk. This flexibility lets you use the exact tool versions you’re comfortable with, making the transition between macOS and other Unix systems smoother.

By mastering Terminal, choosing the right shell, configuring environment files, and understanding macOS file quirks, you unlock a powerful and flexible side of your Mac. Whether you’re writing scripts, automating tasks, or troubleshooting, the command line becomes an indispensable part of your workflow.