4 ms·

As far as I know, fish is not compatible with bash scripts ( most legacy stuff) and this makes zsh attractive.

kungfufrog 5y ago
I don't get it. Are you executing extremely convoluted bash one liners at your shell prompt? I still write for bash and use a bash shebang to run it when I need to script. Mostly because the likelihood a colleague or whoever else comes along later happens to be using fish is pretty low. Bash remains the most portable option!
- activitypea 5y ago
  A lot of CLIs don't ship with fish autocompletion :/
- phero_cnstrcts 5y ago
  I tried fish and uninstalled it because nothing from stackoverflow worked. Sure, I could spend time learning the fish syntax. But I won’t, since zsh works.
  - kungfufrog 5y ago
    I see. I just dump that kind of stuff in a bash script or bash -c '...' it directly if necessary. Still, to each his own! That's the great thing about having a glut of viable options.
- CJefferson 5y ago
  I often find I write out a series of commands interactively in the shell, then decide I want to save them as a shell script, which I might then want to share. I enjoyed fish, but found it too annoying to have to translate things into bash when I wanted to share them.
  - cies 5y ago
    exactly, that's why im back too. back to zsh from fish, that is.
- lapser 5y ago
  Generally my workflow when developing scripts is running individual commands on the CLI so I can see what it's doing so I can get it right. This is not possible with fish unless I start a bash shell, so at that point, what is the point? With zsh, most of the code I would run in a bash script still runs in a zsh interactive session. Sure there a few edge cases, but they're quite well documented.
  - samatman 5y ago
    Generally my workflow when developing scripts (in Python) is to run individual functions in the repl so I can get it right. This isn't possible with bash unless I start the python repl, so at that point, what is the point? Hey, it's possible you spend a lot of time writing scripts, and they need to be bash compatible. Zsh is great for that. Just wanted to reflect how made-up this sounds to those of us who treat sh like any other language.
    - lapser 5y ago
      > Generally my workflow when developing scripts (in Python) is to run individual functions in the repl so I can get it right. As a matter of fact, this is exactly what I do when I write Python scripts too. It helps understand exactly what things do quickly and figure certain smaller things. > Just wanted to reflect how made-up this sounds to those of us who treat sh like any other language. What do you think sounds made-up?
      - samatman 5y ago
        I mean that "can't use fish because I have to use bash to write bash" makes about as much sense to me, given how I use the terminal, as "can't use fish because I have to use python to write python". I'm assuming that means you write more shell scripts than I do, or think of the context switch between shells as qualitatively different from the context switch between shell and (some other) repl. All of which is fine.
- inkyoto 5y ago
  From the fush documentation: Special variables Some bash variables and their closest fish equivalent: $*, $@, $1 and so on: $argv $?: $status $$: $fish_pid $#: No variable, instead use count $argv $!: $last_pid $0: status filename $-: Mostly status is-interactive and status is-login Replacing «$$» with «$fish_pid»? A contentious choice at the very least – does it also apply to non-interactive fish scripts? «…use count $argv» instead of «$#» – why? Both, $$ and $#, are non-bashism's and go way, way back into the UNIX prehistoric times – hardly bash-ism's. Fish does not appear to have basic conditional variable expansions, matching affix removals and pattern substitutions, either; i.e. ${_var:-substitute}, ${parameter<# / ##>word}, ${parameter<% / %%>word} and ${parameter/pattern/string}. Or, at least their nearest equivalent are not prominently featured in the documentation.
  - Beltalowda 5y ago
    How often do you type these things in an interactive shell though? Also things like $status and $argv are reminiscent of csh, which also goes back a long way!
    - inkyoto 5y ago
      With a varying frequency but I do use them in interactive sessions: $ grep -c '\$\?' ~/.history 137 $ grep -c '\$\$' ~/.history 30 $ grep -c '\$!' ~/.history 6 $ grep -c '\$#' ~/.history 13 Less so when it comes to affix removals… I use them liberally in scripts as well as in data transformation pipelines or more complex one-liners, though. I also semi-frequently quit the shell with «kill -9 $$» when I do not want to pollute the shell history with garbage, which is not refelcted in the count above for obvious reasons. It is quick and efficient. > Also things like $status and $argv are reminiscent of csh, which also goes back a long way! Ah, I thought somebody would mention csh as the prior art! Frankly, the C shell syntax have never really clicked with me precisely because of the more verbose syntax, and, as soon as other shells have borrowed history, job control, aliases and a few other features from (t)csh, I was out of the house!
      - Beltalowda 5y ago
samatman 5y ago
bash isn't compatible with python either, unless you use #!/usr/bin/python or the like. All my shell scripts start with #!/bin/sh, so the language my user shell runs is irrelevant. Sometimes I do have to preface copypasta with "bash" and end it with "exit", but it ain't the end of the world. There are a bunch of good reasons to prefer one shell over another, this isn't one of them.
- dngray 5y ago
  Indeed, just use the shebang #!/bin/sh (if it's posix sh), and #!/bin/bash if you must use bash functionality. There is no reason to not use a different interactive shell.
  - adrusi 5y ago
    Please use #!/usr/bin/env bash if you're using bash. It seems more common to have env in /usr/bin than it is to have bash in /bin. On BSD systems, bash is often in /usr/local/bin, and on macOS the user often has a more modern bash in /opt/homebrew/bin or other package manager directory.
- Ensorceled 5y ago
  > bash isn't compatible with python either, unless you use #!/usr/bin/python or the like. You're rather aggressively missing the point. If you need to write and maintain bash scripts but use fish as your command line, you now need to know the idiosyncrasies of both shells ...
  - adrusi 5y ago
    If you want to write portable scripts and use a reasonable interactive shell, you need to know two shells anyway. Scripts should ideally be written to only use shell features defined in POSIX, since bash isn't available on every system. It's available pretty widely, but not on e.g. Alpine Linux by default, and the version on macOS is so ancient it doesn't have features like wait -n. Unless you're going to use rlwrap /bin/dash as your default interactive shell (please don't) you need to know both your interactive shell and standard shell if you're going to write portable scripts.

I don't get it. Are you executing extremely convoluted bash one liners at your shell prompt? I still write for bash and use a bash shebang to run it when I need to script. Mostly because the likelihood a colleague or whoever else comes along later happens to be using fish is pretty low. Bash remains the most portable option!

activitypea 5y ago
A lot of CLIs don't ship with fish autocompletion :/
phero_cnstrcts 5y ago
I tried fish and uninstalled it because nothing from stackoverflow worked. Sure, I could spend time learning the fish syntax. But I won’t, since zsh works.
- kungfufrog 5y ago
  I see. I just dump that kind of stuff in a bash script or bash -c '...' it directly if necessary. Still, to each his own! That's the great thing about having a glut of viable options.
CJefferson 5y ago
I often find I write out a series of commands interactively in the shell, then decide I want to save them as a shell script, which I might then want to share. I enjoyed fish, but found it too annoying to have to translate things into bash when I wanted to share them.
- cies 5y ago
  exactly, that's why im back too. back to zsh from fish, that is.
lapser 5y ago
Generally my workflow when developing scripts is running individual commands on the CLI so I can see what it's doing so I can get it right. This is not possible with fish unless I start a bash shell, so at that point, what is the point? With zsh, most of the code I would run in a bash script still runs in a zsh interactive session. Sure there a few edge cases, but they're quite well documented.
- samatman 5y ago
  Generally my workflow when developing scripts (in Python) is to run individual functions in the repl so I can get it right. This isn't possible with bash unless I start the python repl, so at that point, what is the point? Hey, it's possible you spend a lot of time writing scripts, and they need to be bash compatible. Zsh is great for that. Just wanted to reflect how made-up this sounds to those of us who treat sh like any other language.
  - lapser 5y ago
    > Generally my workflow when developing scripts (in Python) is to run individual functions in the repl so I can get it right. As a matter of fact, this is exactly what I do when I write Python scripts too. It helps understand exactly what things do quickly and figure certain smaller things. > Just wanted to reflect how made-up this sounds to those of us who treat sh like any other language. What do you think sounds made-up?
    - samatman 5y ago
      I mean that "can't use fish because I have to use bash to write bash" makes about as much sense to me, given how I use the terminal, as "can't use fish because I have to use python to write python". I'm assuming that means you write more shell scripts than I do, or think of the context switch between shells as qualitatively different from the context switch between shell and (some other) repl. All of which is fine.
inkyoto 5y ago
From the fush documentation: Special variables Some bash variables and their closest fish equivalent: $*, $@, $1 and so on: $argv $?: $status $$: $fish_pid $#: No variable, instead use count $argv $!: $last_pid $0: status filename $-: Mostly status is-interactive and status is-login Replacing «$$» with «$fish_pid»? A contentious choice at the very least – does it also apply to non-interactive fish scripts? «…use count $argv» instead of «$#» – why? Both, $$ and $#, are non-bashism's and go way, way back into the UNIX prehistoric times – hardly bash-ism's. Fish does not appear to have basic conditional variable expansions, matching affix removals and pattern substitutions, either; i.e. ${_var:-substitute}, ${parameter<# / ##>word}, ${parameter<% / %%>word} and ${parameter/pattern/string}. Or, at least their nearest equivalent are not prominently featured in the documentation.
- Beltalowda 5y ago
  How often do you type these things in an interactive shell though? Also things like $status and $argv are reminiscent of csh, which also goes back a long way!
  - inkyoto 5y ago
    With a varying frequency but I do use them in interactive sessions: $ grep -c '\$\?' ~/.history 137 $ grep -c '\$\$' ~/.history 30 $ grep -c '\$!' ~/.history 6 $ grep -c '\$#' ~/.history 13 Less so when it comes to affix removals… I use them liberally in scripts as well as in data transformation pipelines or more complex one-liners, though. I also semi-frequently quit the shell with «kill -9 $$» when I do not want to pollute the shell history with garbage, which is not refelcted in the count above for obvious reasons. It is quick and efficient. > Also things like $status and $argv are reminiscent of csh, which also goes back a long way! Ah, I thought somebody would mention csh as the prior art! Frankly, the C shell syntax have never really clicked with me precisely because of the more verbose syntax, and, as soon as other shells have borrowed history, job control, aliases and a few other features from (t)csh, I was out of the house!
    - Beltalowda 5y ago

samatman 5y ago

bash isn't compatible with python either, unless you use #!/usr/bin/python or the like. All my shell scripts start with #!/bin/sh, so the language my user shell runs is irrelevant. Sometimes I do have to preface copypasta with "bash" and end it with "exit", but it ain't the end of the world. There are a bunch of good reasons to prefer one shell over another, this isn't one of them.

dngray 5y ago
Indeed, just use the shebang #!/bin/sh (if it's posix sh), and #!/bin/bash if you must use bash functionality. There is no reason to not use a different interactive shell.
- adrusi 5y ago
  Please use #!/usr/bin/env bash if you're using bash. It seems more common to have env in /usr/bin than it is to have bash in /bin. On BSD systems, bash is often in /usr/local/bin, and on macOS the user often has a more modern bash in /opt/homebrew/bin or other package manager directory.
Ensorceled 5y ago
> bash isn't compatible with python either, unless you use #!/usr/bin/python or the like. You're rather aggressively missing the point. If you need to write and maintain bash scripts but use fish as your command line, you now need to know the idiosyncrasies of both shells ...
- adrusi 5y ago
  If you want to write portable scripts and use a reasonable interactive shell, you need to know two shells anyway. Scripts should ideally be written to only use shell features defined in POSIX, since bash isn't available on every system. It's available pretty widely, but not on e.g. Alpine Linux by default, and the version on macOS is so ancient it doesn't have features like wait -n. Unless you're going to use rlwrap /bin/dash as your default interactive shell (please don't) you need to know both your interactive shell and standard shell if you're going to write portable scripts.