3 ms·
> Having said that, I've now switched to fish which I don't like but it doesn't need configuring. That's a plus, but I really don't like how unlike the standar
by zeveb 10y ago
> Having said that, I've now switched to fish which I don't like but it doesn't need configuring.
That's a plus, but I really don't like how unlike the standard shells fish is. That's not entirely a bad thing (c.f. eshell, which is an interesting experiment), but also not a good thing (c.f. eshell, which is AFAICT unusable).
Another issue I have with fish is its popularity. eshell isn't popular, and so eshellisms don't tend to creep into shared environments; fish is popular, and more and more fishisms are creeping into the world at large. This is not, I think, a good thing at all.
If you're putting shell examples out into the world, they should be POSIX-compatible, or at the very least an extension of POSIX; they shouldn't be some wonky other language (else why use shell at all; use a better language altogether, which fish isn't).
I'd really like to see a good reason to use fish over zsh or bash.
- hibbelig 10y agoIn my eyes, the "size of the delta" between, say, fish and bash, is similar to that between, say, Perl and PHP. Or C# and Java. So I feel it's justified to say that fish is a different language than POSIX shell.
- ufo 10y agoOne of the compatibility breaks that I love about fish is that you can use unquoted variable expansion without needing to worry about it being broken on whitespace set foo "Hello World" count $foo # gives 1
- coldtea 10y ago>If you're putting shell examples out into the world, they should be POSIX-compatible, or at the very least an extension of POSIX; If you want to be constrained by POSIX (as we will all be for the next 100 years or so), there are literally myriads of shells you can use.