
D'Oh My Zsh – How I unexpectedly built a monster of an open source project - werrett
https://medium.com/@robbyrussell/d-oh-my-zsh-af99ca54212c#.ovixesd5v
======
smitherfield
A personal pet peeve is when people refer to _having lots of features_ as
"bloat." It's generally very nice to have lots of features all in one place
without having to do things manually, or find somebody's potentially-sketchy
plugin/app.

My test for "bloat" –

1\. Has the project grown so large that it's starting to run into real-world
performance issues? (I can't imagine this could be the case with even the
largest of shell configurations except on very low-end embedded devices).

2\. Has the project grown so large that bugs are popping up faster than the
developers can do maintenance? Is there no or only one person who can read and
understand the entire codebase? (AFAIK, no and no).

3\. Are there many undocumented/poorly-documented features? Are there features
that are both undocumented/poorly-documented and dangerous? Are there many
deprecated or outdated features that have yet to be removed? (AFAIK, no, no,
no).

4\. Are there many features that both duplicate and do not improve on
functionality found elsewhere? (Debatable and mostly subjective).

~~~
mbell
> Has the project grown so large that it's starting to run into real-world
> performance issues?

oh-my-zsh is noticeably slower than prezto on multiple 'high end' machines I
have with the same 'capabilities', i.e. plugins that provide the same feature
set on both.

~~~
smitherfield
Noticeably slower at doing what? I haven't noticed any issue, but I'm maybe a
bit naive; I rarely use the shell for anything that isn't near-instantaneous
and isn't just waiting for some other process to complete (e.g. curl,
compilers). For more complicated stuff I usually write something in a
scripting language.

~~~
mbell
Opening a new shell can take ~5s with oh-my-zsh, it's <1s with prezto. Tab
completion is also noticeably slower with oh-my-zsh.

~~~
Freaky
> Opening a new shell can take ~5s with oh-my-zsh

Heh. I remember when zsh first got its fancy completion system, compinit would
add so long to zsh startup on the dinky little machines of the day that people
literally started adding progress bars and the like to their zshrc.

I stuck with the old-style completion for a long time.

~~~
phaedrix
Have you cleared out your ~/.zsh_history recently? I periodically need to
reset mine to increase init time.

~~~
Freaky
Nope. I increased the limit from 5000 to 10000 a while back and not seen any
noticeable difference in performance.

------
kbd
Could someone please explain to me the attraction in using Oh My Zsh (and
similar)? It seems strange to me to use others' configs.

Over time I've customized my bash config and have all the information I want
in my prompt. If I ever switched to zsh I'd just learn how to translate what I
have in bash. Why would I want to start with someone's big framework for
configuration?

~~~
davis
You answered your own question when you said "over time I've customized". The
appeal of oh-my-zsh and others is that it removes the "over time" part of the
equation.

It's meant to give you a lot of sensible (think like vim-sensible) defaults as
well as the settings that make it feel more like bash yet show the awesome
features of zsh.

A lot of people don't like to configure shells. omz gives them a head start
and a source of inspiration into features they might not know.

~~~
enjo
To piggy-back onto this:

I've never been much of a tools guy. I generally use what the default
configuration is for whatever tool I use. It's just never been particularly
important to me (and I don't feel like it's made even a small difference in my
productivity as a programmer).

Projects like oh-my-zsh are nice because they provide a much richer default
that lazy folks like me can use without ever having to know or care about how
to actually configure a shell because the alternative is that I just won't do
it. I'm not going to take the time to learn about the universe of
configuration options. When I'm exposed to a feature it has to be __really
__useful before I 'm going to bother to learn about how to configure it. So
plugins and the like are huge, they allow me to tailor my environment to the
actual work I do with rich functionality that I otherwise wouldn't have.

So for me projects like this are awesome.

~~~
ams6110
I'm with you. I use the default shell (bash for linux) and don't change it
much. I might tweak the prompt a little and add a few aliases and environment
variables but that's about the limit of it.

The main reason is that I tend to work on a lot of servers, and sticking with
default settings gives me a consistent unsurprising environment on all of
them.

~~~
opk
It is possible to adapt fairly easily between different setups. I've got a
fairly advanced zsh setup but do a lot of admin on a mix of Linux, Solaris and
BSD where I have to put up with whatever the defaults are. I resisted vim for
a long time for similar reasons: when doing admin, I often only had vi. When I
finally took the plunge and learnt how to make effective use of vim-specific
features I regretted not having done it long before. And I can still manage
fine on a bare install of Solaris with vi.

------
shpx
If you like oh-my-zsh you'll love
[https://fishshell.com/](https://fishshell.com/). The main difference I use is
better command completion as you're typing, and you can complete by word with
alt-f. And ruby like syntax.

for example (| is the cursor and everything after it is grey text)

>echo hello world

hello world

>echo |hello world # alt-f

>echo hello| world

Fish and oh-my-zsh both take about 5 seconds to init though. If you don't like
that you should be using prezto (which is the fork he mentions in the article)

~~~
forgotpwtomain
> Fish and oh-my-zsh both take about 5 seconds to init though. If you don't
> like that you should be using prezto (which is the fork he mentions in the
> article)

You must have a lot of expensive stuff crammed into your config.fish file, for
me fish takes < 1 second to init.

~~~
shpx
A config.fish consisting of the line 'alias a=echo' repeated 200 times takes 3
seconds to start. No config file starts out in 50 ms. So my 200 aliases seem
to be the culprit here. And to be fair my init time is actually a bit over 2
seconds.

~~~
romanr
Can you remember 200 aliases?

------
cies
"I like Prezto[1] nowadays" \-- an `Oh my zsh` refugee

1: [https://github.com/sorin-ionescu/prezto](https://github.com/sorin-
ionescu/prezto)

~~~
michaelsbradley
There's also bash-it, for those who want a similar framework but don't want to
move away from bash for whatever reason/s:

[https://github.com/Bash-it/bash-it](https://github.com/Bash-it/bash-it)

~~~
elliotec
I used bash-it for a long time early on. I was intimidated by switching to the
unfamiliar territory of zsh, but it's a no-brainer now and I'd struggle to
live without its features that I have since taken for granted.

------
sdegutis
I heard of zsh back around 2012, lots of colleagues who I respected very
highly were using it. But I just never could get behind the idea of using
someone else's defaults. Even when I switched to Emacs, I hand-picked every
line in my configs from looking at a bunch of people's configs and with a lot
of random googling to solve things. Even though it took like 2 weeks of
constant tweaking to get just right, I haven't touched it much in like the
past 3 years or so, and I've been super productive ever since. So meh, seems
to have worked out for me. But YMMV. Also, I use eshell (with some tweaks)
almost exclusively now, as opposed to a "real" terminal with bash or fish or
zsh (etc.)

~~~
Twirrim
I've tried it a few times given it weeks or month long trials, and never
really found a strong enough benefit over bash, especially when I'm always
going to find bash on servers I deal with.

I actually find it valuable to nuke my bashrc customisations every few years
and reevaluate. Assumptions and practices entrenched in those customisations
can be anti-patterns or counterproductive.

~~~
cyphar
There's a lot of shortcomings in bash. I wrote my zshrc by hand, and I didn't
like the fact that most people use oh-my-zsh. For me, writing my own zshrc
from scratch taught me the differences between bash and zsh (I ended up
writing my own .git and .hg parsers because running the commands is too slow).

------
scosman
"I’d become dependent on these shortcuts."

The intro to this article is as much a caution of becoming dependant on non-
standard tools, as it is a pitch for omzsh. If you can't sit down at a normal
bash window and get shit done, your shortcuts are hurting you.

~~~
copperx
> becoming dependant on non-standard tools

There's no shame in customizing shortcuts. Isn't that the entire point of
emacs?

~~~
scosman
The problem is if you can't work without them. Not every terminal you sit down
at or connect to will have them.

Customize all you want, but don't become dependant on your customizations.

------
wsha
I like learning from other people sharing their config files, but my attitude
towards oh-my-zsh is similar to that of the author's co-workers in that I
don't want to install a bunch of customizations that I don't understand. I
couldn't find a summary of what all oh-my-zsh is supposed to do and the source
has grown too large for me to read it quickly. I guess I trust code I haven't
read most the time I am using a computer but it feels wrong to me to allow my
shell to auto-update customizations that I don't understand.

------
ignoramous
Reminds me of Nathan Marz's great piece about lessons learnt from creating,
and maintaining Storm as OSS: [http://nathanmarz.com/blog/history-of-apache-
storm-and-lesso...](http://nathanmarz.com/blog/history-of-apache-storm-and-
lessons-learned.html)

------
sethrin
910 contributors, 191 issues, 516 pull requests, and his response is that
"reviewing and approving pull requests is a nice-to-happen versus a need-to-
happen." While I'm glad I am not in the position of maintaining that (or
anything else important), that doesn't really speak well to the long-term
prospects for the project. Clearly this is something that I and many others
find very useful; It would be a shame to let it stagnate. The glib part of me
would suggest either 'stepping up, or stepping down', but I can't really
credibly offer solutions, I just am trying to point out a problem.

~~~
zenlikethat
So you criticize the maintainer for their large pile of (unpaid) work in the
queue, but aren't willing to help out?

If you're worried about the project stagnating, why don't you offer to donate
some cash? Why not offer to help in whatever way you can, even if it's just
triaging tickets?

~~~
sethrin
Firstly, this isn't about me. I'm not the one who started this project, I
don't have any stake in maintaining it, and I'm definitely not the only one to
notice that the tickets are piling up. Frankly I thought it was widely
known.[0][1]

As it happens, I am probably in the running for worst/poorest developer on HN,
and that's using the term "developer" broadly. To the degree that I have any
resources that aren't being put towards subsistence, I'm not sure I could help
anyone with anything. It doesn't feel particularly good to have to explain
that, especially since everyone on here seems to be in a vastly different
social situation, but either way, I'd appreciate fewer personal reflections.

[0][http://joshldavis.com/2014/07/26/oh-my-zsh-is-a-disease-
anti...](http://joshldavis.com/2014/07/26/oh-my-zsh-is-a-disease-antigen-is-
the-vaccine/) [1][https://www.bountysource.com/issues/102375-move-plugins-
to-s...](https://www.bountysource.com/issues/102375-move-plugins-to-separate-
repositories-and-use-antigen-package-manager)

------
julie1
Humm ... I looked for the fun if no one spotted in any comment that there was
a creepy feature the author likes.

Periodic automated arbitrary code execution from a remote source.

Here is a list of the stupid ideas that old coders warned from

    
    
       - abritrary remote code execution [X]   this, curl|bash
       - too much dependencies           [X]   npm
       - lack of specifications, staging [X]   Agile
       - non deterministic HW            [X]   Intel
       - non deterministic software      [X]   llvm/gcc/AI
       - Single point of failure         [X]   github/CA
       - attack by majority on P2P       [X]   blockchain, bitcoin
       - bigger sloc is more bugs        [X]   heavy frameworks
       - using immature technologies     [X]   haskell
       - bloatwares                      [X]   angular
       - private corp standardizing      [X]   QUIC & al, browser wars
       - beware of information entropy   [X]   big data
       - moving parts                    [X]   the Cloud
       - higher surface of vulnerability [X]   IoT
       - monopolies                      [X]   google
       - using private cie for infra     [X]   github is the new sourceforge
       - putting half backed std in prod [X]   IPv6
       - lack of consistency             [X]   most nosql tech
       - legal risk due to IP law        [X]   coding by copy/pasting
    

If I was an old coder still coding I would say we are very close to a
singularity : the total lack of trust that could result in all this is simply
customers reverting to fax, teletypes, snail mail... or going to court to ask
for financial compensations.

If you need an expert to help you on this, I can help.

------
voltagex_
I've tried a number of times to switch to zsh, ostensibly for oh-my-zsh. My
main issue is that bash is the default almost everywhere so it's more work to
change it than it is to just be "happy enough" with Bash.

I used to work on a fairly underpowered ARM5 and I could feel the impact of
most prompt customisations on the speed of the system, especially on initial
login. That feeling is still there - mainly because I haven't found the right
SD card for my Raspberry Pi.

To avoid this becoming a complete ramble - are there any advantages to
switching to zsh as someone who's reasonably comfortable with bash? Hell, even
OS X switched (and boy, t/csh was a shock when using FreeBSD).

~~~
lake99
This is a difficult question to answer. I switched a long time ago, when bash
did not provide the kind of completions that zsh does. Nowadays bash is
catching up.

Try these things in bash (with completions installed):

1\. cd to a git repository and type "git [TAB]". Do you see a list of git-
specific completions?

2\. cd to a directory that has a makefile and type "make [TAB]" do you see a
bunch of make targets?

3\. cd to a directory that has some PDF files and some other files. Type
"okular [TAB]" (or whatever you use to view PDF's. Do you see just the PDF
files as completions?

4\. Same as 3, but try other programs like python, perl, etc. How well do bash
completions keep up with zsh completions?

I'd be very surprised if bash supports completions for programs that zsh has
missed.

In general, switching from bash is very easy. Your muscle-memory from bash
transfers very well to zsh. You may want to change the prompt to look similar
to your bash prompt, so you'll feel at home. Translating my bashrc and
bashprofile took just a few minutes.

I tried oh-my-zsh and it did not feel right for me. If this is the reason
you're switching, all I can say is that zsh offers benefits even without it.

------
spystath
A light but featureful alternative to omz is also the grml zsh configuration
[0]. I've been using it since 2011 or so and I've probably touched my .zshrc
once or twice. If you fancy some colors you can also add some syntax
highlighting [1]. Or just use fish which is great for interactive use!

[0]: [https://github.com/grml/grml-etc-
core/tree/master/etc/zsh](https://github.com/grml/grml-etc-
core/tree/master/etc/zsh)

[1]: [https://github.com/zsh-users/zsh-syntax-
highlighting](https://github.com/zsh-users/zsh-syntax-highlighting)

------
vidoc
Reminds me how lame those geek t-shirts are, and how vulgar it is to put
stickers on laptops!

------
draw_down
I understand the author's viewpoint but I would probably get rid of it the
first time it asked to auto update.

Customization is nice but I guess I mostly prefer to spend as little time
thinking about shells as possible.

------
beefsack
I absolutely love bash + powerline. You might know powerline if you're a Vim
user.

[http://i.imgur.com/3FKaEIy.png](http://i.imgur.com/3FKaEIy.png)

It's incredibly easy to set up, I have a script to do it[1] but doing it by
hand is trivial.

[1]: [https://github.com/beefsack/bash-powerline-
installer/blob/ma...](https://github.com/beefsack/bash-powerline-
installer/blob/master/install.sh)

------
onetimePete
The irony is that after all those years, we still dont find a optimal way to
find out - when it is a good time to annoy a user about update decisions. Do
it during the system start up phase? Do it before they go into a break? Do it
upon return to the system, when work was already interrupted? Do it shortly
before shutdown?

No, annoyia be praised. It must be when the user has focused for longer then 5
Mins on something.

~~~
marssaxman
My answer would be more like "fucking never, my god!" I thought this was one
of the reasons to use free software: none of this paternalistic phone-home
bullshit.

------
gjvc
"oh my zsh" is too slow to be life-enhancing

~~~
agumonkey
It did teach me how to understand a terminal / prompt. A few bits of
information here and there and you suddenly feel happier because that part of
the system also work for you.

------
fvargas
> _It’s March 22, 2016 and the top trending repository on Github is ?_

Not oh-my-zsh. It was top trending for the Shell category, not for all of
GitHub.

------
jarjoura
I adore Oh My Zsh, way better than bash and the completion plugins are
extremely helpful!

------
OJFord

        > This wouldn’t my first foray into open source software;
        > nor my last.
    

I know that I'm annoyed perhaps too easily by poor grammar - but the _opening
sentence_ , really?!

~~~
ant6n
sounds more like a typo

~~~
OJFord
I'm sure it is. (That doesn't make it not a grammatical error.)

It just seems like every time I follow a link to Medium, the article's
littered with them; surely even the most cursory of proof-reads catches an
issue with the opening sentence.

