However, it seems like all of the bash-to-zsh posts boil down to better autocompletion and oh-my-zsh. I haven't really seen anything fresh in quite some time. This is something that I do not understand. Does the author think he is saying something that hasn't been said, or is the hope that if we keep saying the same thing over and over that we can get more people to try zsh? I really can't say.
Also, I recommend not using oh-my-zsh if you are a beginner. Rather, I recommend that you start with a blank slate and read the documentation. This is the only way to get the exact configuration you want. If you don't really care about your shell that much, then why are you switching in the first place? Alternatively, you might try using the "recommended" config offered on first run (I can confirm that the default config on Debian is a good start and will work for most people). Then go through that config while reading the Zsh User Guide[1] and tweak it to your liking. It is my opinion that oh-my-zsh ultimately stops people from reading documentation and offers an incentive (ease of use) for using code that may not be understood (when it probably should be). However, a lot of people seem to like it. Perhaps I am missing something.
My intent is not to discourage this author specifically, but rather to call into question the underlying motivation and behind and utility of all posts of this type.
More or less, you never need the 'find' tool when using zsh. For example, if I want to find all the Makefiles in this or child directories that have the string 'abc' and have been modified less than 1 hour ago, I can do
$ grep -l abc **/Makefile(mh-1)
$ less *(om[1])
$ cd dir(:A)
*
*.h
'*~*.h'
DSC<95-107>.jpg.
This feature alone is enough to make a switch worthwhile. It did take me an hour to set up my .zshrc to work like bash, but this has easily paid for itself.
No need to cry -- Bash does it this way:
DSC{95..107}.jpg.$ echo {000..10}
000 001 002 003 004 005 006 007 008 009 010
Having written it, though, I thought I might share it. For most people, like me, the timing has to be right to try something new. You have to have the time and the motivation and everything else. By sharing it, I hope to hit some people with the right timing (and based on some comments, upvotes, etc, I know I did).
I must have seen 20 Haskell advocacy posts before I actually tried writing something in it. Same with you for some new technologies?
>It is my opinion that oh-my-zsh ultimately stops people from reading documentation and offers an incentive (ease of use) for using code that may not be understood (when it probably should be)
I'm diametrically opposed to this philosophy. Every time I start out trying to do something perfect or the "right way", I lose interest or time to continue. On the other hand, now that I used oh-my-zsh and it gave me all these awesome features in 10 minutes, I'll be motivated to continue learning about zsh over time.
Not to say that you're wrong and I'm right, just offering a counterpoint.
Never heard of oh-my-zsh before. Loved the post.
If you don't understand what zsh can do, how do you expect to take advantage of a highly specialized pre-configuration?
Bash has context dependent auto completion as well. So what's the advantage of zsh here?
they both have it - zsh's is better
http://www.apreche.net/dont-change-the-computer-change-yours...
I recently bought a new video card (nvidia), plugged it and then booted linux. It just worked out of the box. Then I proceeded to boot windows, it started on a low resolution video mode because the current driver failed. So had to download and install latest drivers manually. The whole procedure took like 3 or 4 restarts.
In the past they'd go through a procedure where they would learn how you write.
But later on, they decided it was most effective for you to learn to write in a way that the handwriting recognition software would understand.
I'll mess with colors to help my brain visually sort tasks, but I've abandoned so many configurations over the years it's less brain drag to just use what's there.
(For me, the thing that finally drove me to zsh was bash's unruly handling of prompt wrapping)
Re what comes with the OS: I haven't logged into a Unix/Linux box in a decade that hasn't had zsh on it.
f.lux for iOS is tempting me to re-visit this, as it's crucial to me getting a few more Z's at night.
I'm sure there's a way to make it all work nicely, but bash has been doing just fine for me, I don't feel the need to figure out an entirely new configuration system for a tool that ultimately has little new utility in my workflow.
I feel the same way about Vim, but for some reason more people in the Vim community seem to agree with me.
Which files should I copy over, or compare and update once I install prezto ?
Now my prompt is nothing but a green ">> " on a black background. I'm not deluding myself when I say that the reduced clutter improves my productivity.
This is not true, you can do that in Bash too (via .inputrc) http://blog.theliuy.com/2011/inputrc-keyboard-mapping-config...
Edit: Maybe I misunderstood though, does pressing Up really let you search all command lines that contain what you have written, not just those that begins with it? It doesn't seem to do that on my zsh.
Over time I've temporarily switched to others just to make sure I wasn't being stuck in a rut, but I always have come back to zsh. It's a joy to use as a day to day command line interface.
For writing shell scripts, i.e. actual software implemented in shell, I actually prefer bash. In large part because it's more portable, in the sense that any given machine is likely to have bash already installed.
However, if a person really wants to run your scripts, he can probably install the interpreter for which they were written.
So choosing bash as some sort of middle-ground isn't really justifiable.
* It knows which commands git takes? Yes. * which hosts are in my hosts file for ssh? Yes. * which users my system have when I write chmod? Yes. * available packages to apt-get? Yes.
Plus everything in /etc/bash_completion, plus the hundreds of additional commands in /etc/bash_completion.d, plus many, many online resources for creating your own...
It's a matter of preference which completion strategy is the best, yes. :) But for me I've found that zsh's way to do it saves me many more keystrokes than bash's way.
http://stackoverflow.com/questions/7179642/how-can-i-make-ba...
Yay Unix. Input collection is a pluggabls component.
Thing is, it's note that hard to get the mentioned features in bash. Good tab completion, good git enabled color prompt, ssh completion, host completion, command completion and (my favorite) "start typing, press up, cycle through command history with the given input" aka reverse search. I really really liked fish. But incompatibility with bash was just too annoying after a while.
Also, it's annoying to constantly switch between zsh and bash when you are working on other servers over 50% of your time.
if [[ -s "$HOME/.rvm/scripts/rvm" ]] ; then source "$HOME/.rvm/scripts/rvm" ; fisomeone please post a rebuttal showing how to do all this in bash with appropriate .bashrc/functions and utility programs like fasd.
It's designed to be lean, DRY, simple and modular. You can use it as is, overwriting you own dotfiles with setup.sh, or you can pick-source each file/feature you want individually (some need a couple vars set, grep for DOTFILES_).
It leverages available software but tries not to break when it's not available. It works under both Linux and OSX.
It includes an implementation of something like vcs_info for bash, leading to a much more configurable PS1 than git's provided bash prompt support.
Its prompt tries to use colors semantically, and keeps things logical and non-cluttered.
If this reads like this is the best thing since slice bread, that's because it is! ... for me. But I'm sure you could find a useful thing or two in there.
[0] https://github.com/lloeki/dotfiles
[1] I went all the way to hack support of right prompting and reverse-% cleanup on non-newlined output in bash. It works well... most of the time, but when it breaks it's ugly so I just disabled it.
All posts on the subject show that theirs authors have been using a shell they don't know and have replaced it by another shell plus configuration files made up by someone more clever. All posts are also bullet lists of features bash can actually be configured to do.
Someone wake up.
edit: should be two asterix characters with no whitespace in between, but if I do this they're not displayed. Any advice on how to get that working?
I'm in the process of trimming down prezto to exactly what I need, since it also has too much fluff. It's a great resource, I'd recommend it to anyone wanting a slimmer and easier to grok zsh configuration.
Couldn't be happier!
Don't get me wrong, I use zsh. I also use bash. I end up using more bash than zsh though. The reason are the same as 12 years ago. If zsh was the most popular shell right now the same people would be praising bash.
- they're equally fast for what we need them to do
- they've similar features
- bash is everywhere
- bash is the standard for all scripts
- zsh has extra complexity
Oh yeah and stop using pg-up in bash, use ctrl-r. And if different is cool, I don't know, use fish.
It's like with Plan9 and Linux or new systems languages which try to make a better C. The technology _is_ better than the existing one, but not that much better that it's that relevant.
I think one of the main problems of current shells is that they try to be a CLI and an interpreter for a programming language (e.g. Bash script) at the same time, but the user uses mostly just one of these features for certain periods of time. At one point he wants to control the computer in a very efficient matter (system usage), so short keystroke sequences are convenient. At other times one wants to do more complex stuff which involves programming (development).
However current Shells are at any point in time prepared for both and that's the reason why both tasks are sometimes cumbersome.
Then I worked with a couple of junior developers and noticed them doing some cool looking things on the terminal.
Suffice to say I've now switched to Zsh and can't see myself going back to bash any time soon. Thanks junior devs :)
And I have to invest time to learn all the codes.
In the times it takes to learn zsh, I could write the same functionality into small sh scripts which I can run on any machine. Put them in a folder, add it to my PATH and I'm in business.
I can tar up this folder and upload it to some internet-connected machine so I can download it to any other machine with an internet connection.
zsh is wonderful. It is the ultimate "interactive" shell. But it's not portable.
Moreover, the less "interactive" I need to be on the command line the better. If I have short, portable scripts to do certain things, and I can run them on any machine with /bin/sh (no need to install anything; sh is the universal interpreter), that's a nice thing to have. zsh won't give me that.
Now, I would recommend against using /oh-my-zsh/ and the like wholesale; just add useful things to your zsh setup step-by-step, where you actually understand each step.
Otherwise you're just importing a blob of magic that can interact with other things in weird ways. /oh-my-zsh/ contains a lot of gems, but take them one by one.