Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Or fish, which is basically zsh with sane defaults.


And a completely incompatible non-POSIX syntax, which sounds great in theory but isn't nearly enough better to justify the departure IMHO.


Why does compatibility matter? If you have a script written for sh or bash it will just run using that interpreter.


There are http://www.commandlinefu.com and the like. I copy and paste stuff from the web into the shell occasionally, I'm sure everyone does. I do use fish, but it is annoying sometimes, it's missing the most basic stuff like backticks. So much so that I think I'm going to stop.


I'm sure you know this, but it's not missing that feature. It's just that the syntax is different.


For starters, any utilities based on sourcing won't work, such as nvm/rbenv/etc.

That's technically true for zsh in cases, but it's far easier to port or add compatibility for zsh than fish.


You can use bass which solves this problem without porting the script to fish: https://github.com/edc/bass


Or bash, since it will be installed everywhere, you don't have to get it, and most scripts you'll find online will work on it.


This is a non-issue. The `!#/bin/bash` at the top of scripts will tell the interpreter which shell to run. And any one liner I've found online for bash has also worked on zsh (for me), but even if it didn't: `bash -c ls`


Yes exactly.

Today I learned people actually write / use scripts without specifying the interpreter at the top of the script. This is like writing a Ruby script and expecting it to work when calling it with the Python interpreter.


Yeah, it's actually not installed everywhere (e.g. FreeBSD).


Anywhere that matters. Besides, still more places than fish or zsh.


Minus it being bash-compliant. Deal breaker for most.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: