5 ms·

I don't get why people expect POSIX compliance from fish. Your interactive shell and your scripting shell can be, should be, and often are, different. I use ba

I don't get why people expect POSIX compliance from fish. Your interactive shell and your scripting shell can be, should be, and often are, different. I use bash as my default user shell, fish as the default shell of my terminal emulator, and I write scripts for both POSIX sh (dash and busybox ash) and bash. I end up using three different shells with different purposes. Sure, I could use zsh both as an interactive and scripting shell but I don't have the time or willingness to configure it when fish offers a nice out of the box experience. Not to mention that zsh shouldn't be used as a scripting shell in the first place.

pxc 5y ago
> Not to mention that zsh shouldn't be used as a scripting shell in the first place. Why not? If I'm writing scripts for automating configuration on modern macOS, for example, where ZSH is installed by default, why not write ZSH scripts?
- R0b0t1 5y ago
  It's more "why not write scripts?" Actually making use of a shell's control structures is code smell until we have far better shells than we currently do. They're optimized for user interaction, not necessarily anything else.
  - pxc 5y ago
    If you're gonna be calling a lot of external programs and interacting with files a lot, non-shell scripting languages tend to feel pretty clunky. I know what you mean, though. Most shell languages don't feel like flexible, expressive programming languages in the way that they ought to and could. As you may know, there are some new shells/languages that are trying to bridge the gap in a way that still leaves the shell well-suited to interactive use. The Oil shell wiki has a great list of them (and Oil is one such shell itself, of course): https://github.com/oilshell/oil/wiki/Alternative-Shells https://github.com/oilshell/oil/wiki/Alternative-Shells
    - remexre 5y ago
      > If you're gonna be calling a lot of external programs and interacting with files a lot, non-shell scripting languages tend to feel pretty clunky. Perl's actually pretty good here; I'm pretty new to it, but it's generally what I reach for when I feel like a bash script has gotten just a bit too complicated.
      - R0b0t1 5y ago
        Perl definitely is the sweet spot. Even then, I think python with multiprocessing and the pipe class is better than bash in some circumstances. If all you're doing is `a | b | c | d` then use bash but if you're pulling stuff out of the middle in a loop, yeah, might want to use a real language.
- ayushnix 5y ago
  > Why not? If I'm writing scripts for automating configuration on modern macOS, for example, where ZSH is installed by default, why not write ZSH scripts? I guess there are two reasons - if the script doesn't need arrays, POSIX sh (dash) scripts will be much faster than bash/zsh scripts - if you do need arrays, bash is vastly more ubiquitous than any other shell on the planet right now (except POSIX sh). It's installed on almost all Linux distributions by default. I'm not gonna use a ZSH script because I'd have to install ZSH, which seems unnecessary. A good example is tomb, which is a ZSH script for encryption on Linux. If you're sure that your scripts will always run on macOS, use POSIX sh if you don't need arrays and ZSH if you do need them.
  - DavideNL 5y ago
    Good advice, thank you..
Aloha 5y ago
Exactly this. I script in bash (though I'm super interested in oil), and use fish as my interactive shell, it's pinned to screen 0 in my screen session.
alerighi 5y ago
Then you have to learn two languages. And switch from one to another when you need to do some scripting. I don't write shell scripts a lot, I prefer to write python scripts (that are more maintainable and simple to write). But I write complex commands in the shell a lot, for example I may need to convert a bunch of images from one format to another, just use a for loop with imagemagik directly from the command line, then maybe a regex with sed to rename them, and done. It's not rare that I write commands that are more than 5 lines long. With all the quirks of POSIX shell scripting languages (well in reality I use zsh that is nicer) they let you hack things together fast, and that makes them powerful.
- ayushnix 5y ago
  > Then you have to learn two languages. Why would I need do to that? > But I write complex commands in the shell a lot ... It's not rare that I write commands that are more than 5 lines long. Ah, well, yeah, in that case, you might wanna stick to ZSH. I don't write complex commands on the shell. If it's more than 1 line long, I will make it a script. Multiple lines of commands with, or without, backward slash separators look ugly and unwieldy to me. A text editor like vim would do a far better job handling those 5 lines instead of an interactive shell.
  - renewiltord 5y ago
    For what it’s worth, as another long line she’ll user, I actually do write those in some combination of the terminal and C-x C-e bringing up my nvim.
    - ayushnix 5y ago
      Right, as I said, writing multiple lines of commands on a shell doesn't really make sense because it's not interactive usage, it's scripting. And scripting should be done using an editor, which is what you're doing by using nvim to write the command.
- tekknik 5y ago
  > Then you have to learn two languages. And switch from one to another when you need to do some scripting. The more languages you know the more valuable you are. I prefer to only write golang but sometimes that leads to typescript, Makefiles and bash scripting as well.
xkgt 5y ago
I am a fish shell user, but for me the biggest drawback is that a lot of tools rely on updating bashrc as part of installation and some of them don't have an equivalent `config.fish`.
- ayushnix 5y ago
  > ... a lot of tools rely on updating bashrc as part of installation and some of them don't have an equivalent `config.fish` such as?
  - waterhouse 5y ago
    For example, Macports puts its installed binaries into /opt/local/bin (and sbin), and the installation process put this into my .profile: # MacPorts Installer addition on 2016-07-01_at_00:46:04: adding an appropriate PATH variable for use with MacPorts. export PATH="/opt/local/bin:/opt/local/sbin:$PATH" # Finished adapting your PATH environment variable for use with MacPorts. And I had to put the fish equivalent of that into ~/.config/fish/config.fish myself.
    - ayushnix 5y ago
      Umm, you don't need to define your PATH variable in `config.fish`, not unless you make it your default login and user shell. You should keep using bash as your default login and user shell, define your environment variables, like PATH, in your `.bashrc`/`.bash_profile` but use fish as the default shell of your terminal emulator. In that case, fish should pick up the PATH from bash.
      - xkgt 5y ago
        That addresses only the part of setting up PATH variable. Some init scripts go beyond that and have additional code embedded in them (see sdkman, pyenv). These needs separate init scripts for fish users. Just a cursory look at github issues can show how prevalent this issue is: https://github.com/search?q=fish+support&type=issues https://github.com/search?q=fish+support&type=issues

pxc 5y ago

> Not to mention that zsh shouldn't be used as a scripting shell in the first place. Why not? If I'm writing scripts for automating configuration on modern macOS, for example, where ZSH is installed by default, why not write ZSH scripts?

R0b0t1 5y ago
It's more "why not write scripts?" Actually making use of a shell's control structures is code smell until we have far better shells than we currently do. They're optimized for user interaction, not necessarily anything else.
- pxc 5y ago
  If you're gonna be calling a lot of external programs and interacting with files a lot, non-shell scripting languages tend to feel pretty clunky. I know what you mean, though. Most shell languages don't feel like flexible, expressive programming languages in the way that they ought to and could. As you may know, there are some new shells/languages that are trying to bridge the gap in a way that still leaves the shell well-suited to interactive use. The Oil shell wiki has a great list of them (and Oil is one such shell itself, of course): https://github.com/oilshell/oil/wiki/Alternative-Shells https://github.com/oilshell/oil/wiki/Alternative-Shells
  - remexre 5y ago
    > If you're gonna be calling a lot of external programs and interacting with files a lot, non-shell scripting languages tend to feel pretty clunky. Perl's actually pretty good here; I'm pretty new to it, but it's generally what I reach for when I feel like a bash script has gotten just a bit too complicated.
    - R0b0t1 5y ago
      Perl definitely is the sweet spot. Even then, I think python with multiprocessing and the pipe class is better than bash in some circumstances. If all you're doing is `a | b | c | d` then use bash but if you're pulling stuff out of the middle in a loop, yeah, might want to use a real language.
ayushnix 5y ago
> Why not? If I'm writing scripts for automating configuration on modern macOS, for example, where ZSH is installed by default, why not write ZSH scripts? I guess there are two reasons - if the script doesn't need arrays, POSIX sh (dash) scripts will be much faster than bash/zsh scripts - if you do need arrays, bash is vastly more ubiquitous than any other shell on the planet right now (except POSIX sh). It's installed on almost all Linux distributions by default. I'm not gonna use a ZSH script because I'd have to install ZSH, which seems unnecessary. A good example is tomb, which is a ZSH script for encryption on Linux. If you're sure that your scripts will always run on macOS, use POSIX sh if you don't need arrays and ZSH if you do need them.
- DavideNL 5y ago
  Good advice, thank you..

Aloha 5y ago

Exactly this. I script in bash (though I'm super interested in oil), and use fish as my interactive shell, it's pinned to screen 0 in my screen session.

alerighi 5y ago

Then you have to learn two languages. And switch from one to another when you need to do some scripting. I don't write shell scripts a lot, I prefer to write python scripts (that are more maintainable and simple to write). But I write complex commands in the shell a lot, for example I may need to convert a bunch of images from one format to another, just use a for loop with imagemagik directly from the command line, then maybe a regex with sed to rename them, and done. It's not rare that I write commands that are more than 5 lines long. With all the quirks of POSIX shell scripting languages (well in reality I use zsh that is nicer) they let you hack things together fast, and that makes them powerful.

ayushnix 5y ago
> Then you have to learn two languages. Why would I need do to that? > But I write complex commands in the shell a lot ... It's not rare that I write commands that are more than 5 lines long. Ah, well, yeah, in that case, you might wanna stick to ZSH. I don't write complex commands on the shell. If it's more than 1 line long, I will make it a script. Multiple lines of commands with, or without, backward slash separators look ugly and unwieldy to me. A text editor like vim would do a far better job handling those 5 lines instead of an interactive shell.
- renewiltord 5y ago
  For what it’s worth, as another long line she’ll user, I actually do write those in some combination of the terminal and C-x C-e bringing up my nvim.
  - ayushnix 5y ago
    Right, as I said, writing multiple lines of commands on a shell doesn't really make sense because it's not interactive usage, it's scripting. And scripting should be done using an editor, which is what you're doing by using nvim to write the command.
tekknik 5y ago
> Then you have to learn two languages. And switch from one to another when you need to do some scripting. The more languages you know the more valuable you are. I prefer to only write golang but sometimes that leads to typescript, Makefiles and bash scripting as well.

xkgt 5y ago

I am a fish shell user, but for me the biggest drawback is that a lot of tools rely on updating bashrc as part of installation and some of them don't have an equivalent `config.fish`.

ayushnix 5y ago
> ... a lot of tools rely on updating bashrc as part of installation and some of them don't have an equivalent `config.fish` such as?
- waterhouse 5y ago
  For example, Macports puts its installed binaries into /opt/local/bin (and sbin), and the installation process put this into my .profile: # MacPorts Installer addition on 2016-07-01_at_00:46:04: adding an appropriate PATH variable for use with MacPorts. export PATH="/opt/local/bin:/opt/local/sbin:$PATH" # Finished adapting your PATH environment variable for use with MacPorts. And I had to put the fish equivalent of that into ~/.config/fish/config.fish myself.
  - ayushnix 5y ago
    Umm, you don't need to define your PATH variable in `config.fish`, not unless you make it your default login and user shell. You should keep using bash as your default login and user shell, define your environment variables, like PATH, in your `.bashrc`/`.bash_profile` but use fish as the default shell of your terminal emulator. In that case, fish should pick up the PATH from bash.
    - xkgt 5y ago
      That addresses only the part of setting up PATH variable. Some init scripts go beyond that and have additional code embedded in them (see sdkman, pyenv). These needs separate init scripts for fish users. Just a cursory look at github issues can show how prevalent this issue is: https://github.com/search?q=fish+support&type=issues https://github.com/search?q=fish+support&type=issues