4 ms·

from a comment from tfa: 'Now if you’re really tired of seventies tech you should try fish.' Really, that's pretty much it.

_verandaguy 8y ago
The problem with fish is that it's not POSIX-compliant, and it doesn't try to be (it's a design non-goal), and it's not backwards-compatible with the literally billions of POSIX-compliant scripts and tools already out there. It doesn't even support `!!` since the maintainers don't seem to like it[0]. [0] https://github.com/fish-shell/fish-shell/issues/288
- eat_veggies 8y ago
  I've been using fish as my daily driver for a few months now, and I don't really miss zsh or bash. I get the occasional hiccup, but most scripts have a proper shebang line, so they work with fish anyway.
- ronjouch 8y ago
  The literally billions of POSIX-compliant scripts and tools already out there will run just fine under fish with a hashbang/shebang (a first line that defines what the file executed should be opened with, e.g. `/usr/bin/env sh`) :) . And it's not as if adding a hashbang was painful, not having one is super bad anyway as it leads to uncertainty of whether the script is bash / sh / etc, and can lead to tricky corner cases. I was a wary zsh user too, until I moved my zsh aliases to scripts with a proper hashbang, then migration to fish was painless, and the benefits are real: I get all the features I expected from my long-tuned zsh, with none of the maintenance/performance pains. Actually, even for one-time personal scripts I still default to writing (ba)sh, because 1. habit/competence, 2. shellcheck, 3. what you say: examples and resources are everywhere. Tangentially, upcoming fish will support POSIX && and || (in addition to maybe-even-weirder `; and` / `; or`), and already does if you build from sources now.
  - prg318 8y ago
    So long as you don't need to "source" any of these POSIX-compliant scripts into your environment... A shebang'd script cannot affect the environment of the parent process
    - ronjouch 8y ago
      Indeed, thanks for the precision. Never ran into that, though; config.fish is the only thing touching my environment.
      - prg318 8y ago
        Lucky for you. I have really come to love zsh's sh and ksh emulation features for this very reason. I have worked in various work environments where setting up a build environment or a testing environment required sourcing ksh scripts that sourced even more ksh scripts. The majority of the engineers on these teams would "deal with" ksh for this reason but a few of the "geekier" engineers would set up zsh with ksh emulation in order to work in a more usable shell.
  - _verandaguy 8y ago
    A shebang is good practice, but the state of the industry is such that many scripts don't use them (unfortunately). I'm still of the opinion that fish is little more than a novelty and won't see widespread adoption in the long run.
    - rovr138 8y ago
      `bash script.sh` works fine. The source issue mentioned above is more of an issue.

_verandaguy 8y ago

The problem with fish is that it's not POSIX-compliant, and it doesn't try to be (it's a design non-goal), and it's not backwards-compatible with the literally billions of POSIX-compliant scripts and tools already out there. It doesn't even support `!!` since the maintainers don't seem to like it[0]. [0] https://github.com/fish-shell/fish-shell/issues/288

eat_veggies 8y ago
I've been using fish as my daily driver for a few months now, and I don't really miss zsh or bash. I get the occasional hiccup, but most scripts have a proper shebang line, so they work with fish anyway.
ronjouch 8y ago
The literally billions of POSIX-compliant scripts and tools already out there will run just fine under fish with a hashbang/shebang (a first line that defines what the file executed should be opened with, e.g. `/usr/bin/env sh`) :) . And it's not as if adding a hashbang was painful, not having one is super bad anyway as it leads to uncertainty of whether the script is bash / sh / etc, and can lead to tricky corner cases. I was a wary zsh user too, until I moved my zsh aliases to scripts with a proper hashbang, then migration to fish was painless, and the benefits are real: I get all the features I expected from my long-tuned zsh, with none of the maintenance/performance pains. Actually, even for one-time personal scripts I still default to writing (ba)sh, because 1. habit/competence, 2. shellcheck, 3. what you say: examples and resources are everywhere. Tangentially, upcoming fish will support POSIX && and || (in addition to maybe-even-weirder `; and` / `; or`), and already does if you build from sources now.
- prg318 8y ago
  So long as you don't need to "source" any of these POSIX-compliant scripts into your environment... A shebang'd script cannot affect the environment of the parent process
  - ronjouch 8y ago
    Indeed, thanks for the precision. Never ran into that, though; config.fish is the only thing touching my environment.
    - prg318 8y ago
      Lucky for you. I have really come to love zsh's sh and ksh emulation features for this very reason. I have worked in various work environments where setting up a build environment or a testing environment required sourcing ksh scripts that sourced even more ksh scripts. The majority of the engineers on these teams would "deal with" ksh for this reason but a few of the "geekier" engineers would set up zsh with ksh emulation in order to work in a more usable shell.
- _verandaguy 8y ago
  A shebang is good practice, but the state of the industry is such that many scripts don't use them (unfortunately). I'm still of the opinion that fish is little more than a novelty and won't see widespread adoption in the long run.
  - rovr138 8y ago
    `bash script.sh` works fine. The source issue mentioned above is more of an issue.