<commit_before>Title: Two Shells and A Prompt
Date: 2016-09-24
Tags: bash, zsh, git
Slug: two-shells-one-prompt
Status: published
Summary: Lessons learned from ditching zsh, coming home to bash, and writing a bash prompt.

I recently made the switch back to [bash][bash] after a long spell with [zsh][zsh]. I'm a little conflicted, but there were three driving factors in my breakup with zsh:

1. Zsh can be pretty slow sometimes &mdash; especially when you add [oh-my-zsh][omz] to the mix.
2. Bash is everywhere.
3. Virtually all shell scripts are written in bash.

Lets start with the first point. [A lot][zsh-slow] of people [have written][zsh-slow2] about why they think zsh is slow. [Most of the time][zsh-slow3] it's a combination of oh-my-zsh and overweight startup files. I could use zsh without oh-my-zsh, but that seems unreasonable. If I disable oh-my-zsh, I am going to end up rebuilding a lot of its functionality &mdash; and it will probably be half-assed in comparison. [^zsh-alts] And it's not just the startup time, I often find myself *waiting* on the completions after triggering them. Is this worth the in-buffer command highlighting?

[^zsh-alts]: There are oh-my-zsh alternatives, namely [Prezto][prezto]. It was actually a fork of oh-my-zsh that was later rewritten to focus on performance. But if I am going to *really* buy-in on zsh, I should either hunker down and learn the configurations or stick with oh-my-zsh.

Point number two: bash is literally everywhere. Bash is already on both of the servers I pay for. When I am am forced to use a computer at my college &mdash; *first I find a Mac* &mdash; bash is already there when I launch the terminal. When I have to `ssh` into the universities Linux servers to turn in projects, I am greeted with a friendly `bash4.2$` prompt. Bash is the air we breathe, it's the dirt beneath our feet. It's practically a given that it will be on any UNIX system you can find *and* it will be the default shell. Even Windows [has bash now][windows]!

Bash is also the standard for writing shell scripts. If you reach a point where you or an application running needs to execute a series of commands, there is a 95% chance that it is a bash script. This doesn't necessarily mean I have to break-up with zsh, there is actually a lot of interoperability between the two [^fish]. The problem is that I often find myself needing to change some part or parts of these scripts. It usually goes something like this:

[^fish]: Anyone who has ever tried to use the [fish shell][fish] can attest to the importance of your daily shell playing-nice with bash. This *is* a deal breaker.

- Open the script in TextMate.
- Slowly search for the command that needs to be changed or updated.
- Cower in fear at the foreign syntax.
- Head for the hills, never looking back.

This is no good. So my decision is made for me &mdash; if I am worth my weight in salt as a programmer, I need to learn bash. I need to be *proficient* with bash.

## bash and macOS

When you launch the Terminal on <del>OS X</del> macOS, you are greeted with a bash prompt. The problem is, this software is roughly 10 years old. For reasons have to do with [licensing][license], Apple continues to ship version 3.2 with macOS. Meanwhile bash marches on &mdash; version 4.4 was released a week ago.

Luckily this is a solvable problem. [Homebrew][brew] exists, it's awesome, and it's easy:

```bash
# update all homebrew formulae
brew update

brew install bash<commit_msg>Fix grammar error<commit_after>Title: Two Shells and A Prompt
Date: 2016-09-24
Tags: bash, zsh, git
Slug: two-shells-one-prompt
Status: published
Summary: Lessons learned from ditching zsh, coming home to bash, and writing a bash prompt.

I recently made the switch back to [bash][bash] after a long spell with [zsh][zsh]. I'm a little conflicted, but there were three driving factors in my breakup with zsh:

1. Zsh can be pretty slow sometimes &mdash; especially when you add [oh-my-zsh][omz] to the mix.
2. Bash is everywhere.
3. Virtually all shell scripts are written in bash.

Lets start with the first point. [A lot][zsh-slow] of people [have written][zsh-slow2] about why they think zsh is slow. [Most of the time][zsh-slow3] it's a combination of oh-my-zsh and overweight startup files. I could use zsh without oh-my-zsh, but that seems unreasonable. If I disable oh-my-zsh, I am going to end up rebuilding a lot of its functionality &mdash; and it will probably be half-assed in comparison. [^zsh-alts] And it's not just the startup time, I often find myself *waiting* on the completions after triggering them. Is this worth the in-buffer command highlighting?

[^zsh-alts]: There are oh-my-zsh alternatives, namely [Prezto][prezto]. It was actually a fork of oh-my-zsh that was later rewritten to focus on performance. But if I am going to *really* buy-in on zsh, I should either hunker down and learn the configurations or stick with oh-my-zsh.

Point number two: bash is literally everywhere. Bash is already on both of the servers I pay for. When I am am forced to use a computer at my college &mdash; *first I find a Mac* &mdash; bash is already there when I launch the terminal. When I have to `ssh` into the universities Linux servers to turn in projects, I am greeted with a friendly `bash4.2$` prompt. Bash is the air we breathe, it's the dirt beneath our feet. It's practically a given that it will be on any UNIX system you can find *and* it will be the default shell. Even Windows [has bash now][windows]!

Bash is also the standard for writing shell scripts. If you reach a point where you or an application running needs to execute a series of commands, there is a 95% chance that it is a bash script. This doesn't necessarily mean I have to break-up with zsh, there is actually a lot of interoperability between the two [^fish]. The problem is that I often find myself needing to change some part or parts of these scripts. It usually goes something like this:

[^fish]: Anyone who has ever tried to use the [fish shell][fish] can attest to the importance of your daily shell playing-nice with bash. This *is* a deal breaker.

- Open the script in TextMate.
- Slowly search for the command that needs to be changed or updated.
- Cower in fear at the foreign syntax.
- Head for the hills, never looking back.

This is no good. So my decision is made for me &mdash; if I am worth my weight in salt as a programmer, I need to learn bash. I need to be *proficient* with bash.

## bash and macOS

When you launch the Terminal on <del>OS X</del> macOS, you are greeted with a bash prompt. The problem is, this software is roughly 10 years old. For reasons having to do with [licensing][license], Apple continues to ship version 3.2 with macOS. Meanwhile bash marches on &mdash; version 4.4 was released a week ago.

Luckily this is a solvable problem. [Homebrew][brew] exists, it's awesome, and it's easy:

```bash
# update all homebrew formulae
brew update

brew install bash
{'fraction_non_alphanumeric': 0.06300114547537228, 'fraction_numerical': 0.006586483390607102, 'mean_word_length': 4.072621641249092, 'pattern_counts': {'":': 0, '<': 7, '<?xml version=': 0, '>': 7, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5373474', 'n_tokens_mistral': 2034, 'n_tokens_neox': 1898, 'n_words': 1181}