3 ms·

> Out of curiosity, what use case do you have that makes a POSIX shell a big deal? Running on a POSIX system, there are decades' worth of shell snippets out th

by zeveb 9y ago

> Out of curiosity, what use case do you have that makes a POSIX shell a big deal? Running on a POSIX system, there are decades' worth of shell snippets out there which don't work with fish, but do with sh, ksh, bash & zsh. Fish is just gratuitously incompatible. Having fish-users on a team is a pain, because they'll write everything in fish and either not bother producing sh equivalents, or produce insufficiently-tested sh equivalents. It's just a lot of pain and bother, and what's the benefit? Zsh does everything fish does and more, so why not just use it? Edit: I just wish that the original fish developers had chosen to implement all their cool features and be sh-compatible, or at the very least had exercised some wisdom in where they chose to break compatibility. Instead, it very much feels like a 22-year-old's project: full of ideas, some good & some bad, and needlessly without respect for the past. I've no problem with rejecting the past when the past is broken (and sh is broken in places); my problem is with the equivalent of saying, 'hey, English spelling is terrible, soh Aiv dəseidid tū dəvelup mai ohn.'

geoelectric 9y ago
Back in the day I used to use csh and tcsh, both of which had famously landmine-laden scripting gotchas. So, I wrote my scripts in sh or bash. Now that I use zsh mostly, same thing, I don't actually write my scripts in zsh--especially for production, I write them in sh or bash. zsh for me is an interactive CLI-only tool. Honestly, I think the problem here sounds more about not standardizing on a common denominator for shared scripts. Where stuff like fish is a pain for me is with apps that for whatever reason need shell integration (virtualenv, for example). Non-POSIX shells end up being an afterthought there, so you end up with no or buggy support, and end up having to find some other custom variant (virtualfish, etc.) to get good behavior. Sticking with a more mainstream shell tends to be safer there, and zsh barely makes it over that line.

by zeveb 9y ago

geoelectric 9y ago

Back in the day I used to use csh and tcsh, both of which had famously landmine-laden scripting gotchas. So, I wrote my scripts in sh or bash. Now that I use zsh mostly, same thing, I don't actually write my scripts in zsh--especially for production, I write them in sh or bash. zsh for me is an interactive CLI-only tool. Honestly, I think the problem here sounds more about not standardizing on a common denominator for shared scripts. Where stuff like fish is a pain for me is with apps that for whatever reason need shell integration (virtualenv, for example). Non-POSIX shells end up being an afterthought there, so you end up with no or buggy support, and end up having to find some other custom variant (virtualfish, etc.) to get good behavior. Sticking with a more mainstream shell tends to be safer there, and zsh barely makes it over that line.