4 ms·

Out of curiosity, what use case do you have that makes a POSIX shell a big deal? I’ve never had issues as a somewhat heavy user.

by davemp 9y ago

alphaalpha101 9y ago
It's nice to be able to simply copy-paste commands from the internet sometimes. (obligatory: yes you have to be careful when you do.)
burke 9y ago
There's nothing major. I maintain a set of POSIX and fish scripts as part of my job and, given that I have to know both relatively well, I find I end up preferring the on-average-slightly-more-terse POSIX syntax. One thing that can be particularly annoying is that it seems to be impossible in fish to evaluate a command in a subshell and embed its output into a string without assigning it to a variable first. ARGV handling is a little weird too. I understand the impulse to get rid of $1, $2, $3, $*, $@, $#, etc., but it ends up just requiring different gymnastics, like writing `set -e argv[1]` instead of `shift.
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.

Out of curiosity, what use case do you have that makes a POSIX shell a big deal? I’ve never had issues as a somewhat heavy user.

by davemp 9y ago

Out of curiosity, what use case do you have that makes a POSIX shell a big deal? I’ve never had issues as a somewhat heavy user.

alphaalpha101 9y ago

It's nice to be able to simply copy-paste commands from the internet sometimes. (obligatory: yes you have to be careful when you do.)

burke 9y ago

There's nothing major. I maintain a set of POSIX and fish scripts as part of my job and, given that I have to know both relatively well, I find I end up preferring the on-average-slightly-more-terse POSIX syntax. One thing that can be particularly annoying is that it seems to be impossible in fish to evaluate a command in a subshell and embed its output into a string without assigning it to a variable first. ARGV handling is a little weird too. I understand the impulse to get rid of $1, $2, $3, $*, $@, $#, etc., but it ends up just requiring different gymnastics, like writing `set -e argv[1]` instead of `shift.

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.