31–40 of 117 posts
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 tried using oh-my-zsh, but all of a sudden bringing up a new terminal (on OS X) went from taking ~1 second to ~5 seconds. Totally killed my interest in zsh. 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.
Earlier quoted context omitted.
How much software can you write in three seconds?
How many computers do you use? Having to switch between zsh and bash mentally when you from your dev box to a server can be jarring. For some people it's worth it, for others it isn't.
do people have the same attitude to screen/tmux or vim/emacs (vs nano)?
Here's another perspective: http://sstephenson.us/posts/on-configuration
http://www.apreche.net/dont-change-the-computer-change-yours...
Here's another perspective: http://sstephenson.us/posts/on-configuration
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.
Earlier quoted context omitted.
Syntax. I much prefer the fish syntax, even though the fact that it's different from bash can occasionally cause headaches. When I'm mucking with my shell, I'd rather not be remembering [[ -z ]], because I don't do it often. Basically most shells are designed around power, which is fine. Fish is designed around ease-of-use, which I consider to be a better idea since there's already a ton of power in the UNIX tools th…
Ah, so a lot of it is that you like the config language better! That would not have occurred to me. Thank you for your reply.
This article really feels like bikeshedding to me. I'm always going to use whatever shell comes default with the OS I'm on (which almost always means Bash), simply because changing the shell is an unnecessary block of time that could instead be used writing software. I need a really good reason to switch, something the equivalent of pipes, and if the #1 reason you can give is "Powerful context based tab completion",…
* 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...
This article really feels like bikeshedding to me. I'm always going to use whatever shell comes default with the OS I'm on (which almost always means Bash), simply because changing the shell is an unnecessary block of time that could instead be used writing software. I need a really good reason to switch, something the equivalent of pipes, and if the #1 reason you can give is "Powerful context based tab completion",…
zsh's tab completion is definitely not cosmetic. It can do very useful things like completing scp destination paths over remote hosts.
This article really feels like bikeshedding to me. I'm always going to use whatever shell comes default with the OS I'm on (which almost always means Bash), simply because changing the shell is an unnecessary block of time that could instead be used writing software. I need a really good reason to switch, something the equivalent of pipes, and if the #1 reason you can give is "Powerful context based tab completion",…
zsh's tab completion is definitely not cosmetic. It can do very useful things like completing scp destination paths over remote hosts.