17 ms·

I think this warning is actually harmful: Years ago, I read this argument about fish and it turned me completely off using it. Only more recently have I really

I think this warning is actually harmful: Years ago, I read this argument about fish and it turned me completely off using it. Only more recently have I really realised this never applied to 99% of my (most people's?) use-cases. The logical step many people miss is that shebangs make the compatibility of the user's shell largely irrelevant: the only real compatibility concerns are the bash version or `sh` aliasing on the user's system. e.g. making bash scripts compatible with current macOS systems (outdated bash version and bsd-ish non-gnu binaries) is a far bigger pain than any compat issues fish brings.

masukomi 5y ago
> Only more recently have I really realised this never applied to 99% of my (most people's?) use-cases. every time someone asks "how do i accomplish X task on the command line" (witness literally thousands of Stack Overflow posts like this) the answer is in bash. so, i say it applies to essentially every use case where you didn't already know how to do it. I love fish, but the fact that every answer to your questions is written in another language and has to be translated affects EVERYONE.
- BeetleB 5y ago
  > every time someone asks "how do i accomplish X task on the command line" (witness literally thousands of Stack Overflow posts like this) the answer is in bash. I don't get this argument: The solution is to search for: "how do i accomplish X task in fish" This is what I do with xonsh. Of course, the bigger point that is being missed is that when someone opts to use a shell like fish or xonsh, they're less likely to search how to do X! The reason they picked another shell is often because it is easier to use, etc. In the case of xonsh, it's mostly just Python. I do a lot more in it than I could do in bash, because I don't need to search the Internet for anything.
- jkubicek 5y ago
  I've been using Fish as my primary shell for years. The vast majority of the time those Stack Overflow answers written for Bash work as written in Fish with no changes. Occasionally you'll need to write the command substitution or command chaining in a different way, but once you get over the initial learning curve this is easy and pretty mechanical. Very rarely I find some command that just doesn't work in Fish, in those instances it's easy enough to open the bash shell or throw it into a script file.
- lucideer 5y ago
  > every time someone asks "how do i accomplish X task on the command line" (witness literally thousands of Stack Overflow posts like this) the answer is in bash. Those answers, imo, come in 3 forms: 1. Short simple bash commands that will work in fish 2. Overly clever "one-liners" that would be better as a script 3. Edge cases. (3) is rare enough that I don't see it as a big enough hurdle to avoid using fish.
voidfunc 5y ago
> The logical step many people miss is that shebangs make the compatibility of the user's shell largely irrelevant: the only real compatibility concerns are the bash version or `sh` aliasing on the user's system. It's a huge problem if you have stuff that is expected to be sourced into the shell rather than executed as a script., for example, because the sourced stuff provides a large API of functions.
- lucideer 5y ago
  In my experience, the only time I do this is with files that have been provided explicitly for my shell of choice. The only exception to this that I see regularly is shell installers auto-adding some directory to the PATH env by making automated changes to bash/zsh confs in $HOME. This may be a slight annoyance for some, but tbh I like it as having to manually paste in a PATH addition myself allows me to audit them (and it's still quick enough).

masukomi 5y ago

> Only more recently have I really realised this never applied to 99% of my (most people's?) use-cases. every time someone asks "how do i accomplish X task on the command line" (witness literally thousands of Stack Overflow posts like this) the answer is in bash. so, i say it applies to essentially every use case where you didn't already know how to do it. I love fish, but the fact that every answer to your questions is written in another language and has to be translated affects EVERYONE.

BeetleB 5y ago
> every time someone asks "how do i accomplish X task on the command line" (witness literally thousands of Stack Overflow posts like this) the answer is in bash. I don't get this argument: The solution is to search for: "how do i accomplish X task in fish" This is what I do with xonsh. Of course, the bigger point that is being missed is that when someone opts to use a shell like fish or xonsh, they're less likely to search how to do X! The reason they picked another shell is often because it is easier to use, etc. In the case of xonsh, it's mostly just Python. I do a lot more in it than I could do in bash, because I don't need to search the Internet for anything.
jkubicek 5y ago
I've been using Fish as my primary shell for years. The vast majority of the time those Stack Overflow answers written for Bash work as written in Fish with no changes. Occasionally you'll need to write the command substitution or command chaining in a different way, but once you get over the initial learning curve this is easy and pretty mechanical. Very rarely I find some command that just doesn't work in Fish, in those instances it's easy enough to open the bash shell or throw it into a script file.
lucideer 5y ago
> every time someone asks "how do i accomplish X task on the command line" (witness literally thousands of Stack Overflow posts like this) the answer is in bash. Those answers, imo, come in 3 forms: 1. Short simple bash commands that will work in fish 2. Overly clever "one-liners" that would be better as a script 3. Edge cases. (3) is rare enough that I don't see it as a big enough hurdle to avoid using fish.

voidfunc 5y ago

> The logical step many people miss is that shebangs make the compatibility of the user's shell largely irrelevant: the only real compatibility concerns are the bash version or `sh` aliasing on the user's system. It's a huge problem if you have stuff that is expected to be sourced into the shell rather than executed as a script., for example, because the sourced stuff provides a large API of functions.

lucideer 5y ago
In my experience, the only time I do this is with files that have been provided explicitly for my shell of choice. The only exception to this that I see regularly is shell installers auto-adding some directory to the PATH env by making automated changes to bash/zsh confs in $HOME. This may be a slight annoyance for some, but tbh I like it as having to manually paste in a PATH addition myself allows me to audit them (and it's still quick enough).