[SnowLprd]

🐟 Fish rocks. I've been using it exclusively for the last year, and I can't imagine giving it up.

There seem to be a number of misconceptions, which I will endeavor to address. The first is: "Fish isn't POSIX/bash-compliant, so there are compatibility problems." POSIX non-compliance is a feature, not a disadvantage, of the fish shell. It means there is less legacy baggage and syntactical inconsistency. I can count the number of POSIX/bash compliance-related issues I've had with fish on one hand, all of which were easily dealt with. For example, Vim assumes that your shell is sh compatible, but adding set shell=sh in your .vimrc solves that. The only other significant one for me was virtualenvwrapper, which doesn't support fish. Not a problem: Virtualfish solves that handily: https://github.com/adambrenecki/virtualfish

Want to run a bash script? Just run bash fooshnizzle.sh. Want to switch to bash for a moment? Run bash and then exit when you want to switch back to fish. This POSIX-compatibility topic is, in my opinion, much ado about nothing.

Another misunderstanding seems to be, "I can do XYZ in bash, but fish doesn't support that." Fish purposefully limits the number of "builtins" -- commands that fish includes by default -- in order to maintain simplicity. For me, that's a feature. When I find that there's something I want to be easier to do in fish, I whip up a tiny function to do it. Not only is that extremely easy to do in fish, but then that command performs precisely the way I want it to. I haven't pushed many of those to my dotfile repository yet, but you can check out some of my fish functions there: https://github.com/justinmayer/dotfiles/tree/master/fish

Fish is fast, the auto-completion is amazingly helpful, and it's intuitive to use without too much configuration. Give it a try. 🐟

[sliverstorm]

I just wish it didn't insist on doing everything differently. For example, PATH is traditionally delimited with colons in just about every shell; fish uses spaces. This instantly breaks compatibility with legacy environment configuration, and for no particularly good reason that I can see.

I was excited to try fish, but I found it impossible to get configured in an established environment with entrenched bash usage (which zsh, by the way, has no problem with)

[ridiculous_fish]

Do you mind sharing more details about your legacy environment configuration? How are you currently setting $PATH? Usually the differences in syntax for setting variables causes more problems than the colons.

Regarding $PATH: it is actually not delimited at all in fish. Instead, $PATH is an array, which is a first class notion in fish. This allows for nice tricks like, say, looping through $PATH:

   for dir in $PATH
        echo $dir
   end

or deleting its last entry:

    set --erase PATH[-1]

Of course, fish flattens $PATH into a colon-delimited string when setting it as an environment variable, and unflattens it when reading it from the environment.

[sliverstorm]

PATH gets set the way it always did. For example in bash:

export PATH=$PATH:<new_dir>

As for the larger question of environment configuration; we pull in a number of shell configuration scripts owned by the infrastructure teams. You are right, there is no universal way to set path due to things like "export" vs "setenv", but often multiple shells support the same syntax so you can sometimes use a config script meant for bash in zsh, for example. I had hoped that fish would be able to use csh scripts, because it shares "setenv", but csh of course delimits PATH with colons.

You say that PATH is treated as a colon-delimited string when accessed as an environment variable... Hmm. That wasn't what I was seeing, but it is entirely possible I made a mess of things, or that I broke things when I compiled it.

Anyway, it's unlikely I personally will be able to use fish. I hit many more obstacles than just PATH, but that was the easiest example and I thought I'd share some feedback.

[ridiculous_fish]

Thanks for elaborating. Yes, it's a common issue to encounter configuration scripts, .profile files, etc. that use POSIX syntax, and it's understandable that people will be unwilling or unable to port them to fish. Usually these are just standalone scripts which can be run directly via /bin/sh, but sometimes you want them to be part of your interactive shell.

https://github.com/fish-shell/fish-shell/issues/522 tracks having a bash compatibility layer - as you can see there's a lot of discussion!

[mturmon]

I've solved the configs-in-other-shells problem by writing a translator that sources the target config file, and then exports the needed variables in their desired syntax for my shell of choice. Simple example (config in csh, my language of choice was bash):

   jsoc_mach=`csh -f -c 'source /home/jsoc/.setJSOCenv && echo $JSOC_MACHINE'`

It could be abstracted farther.

Still a pain point, though.

[chasingtheflow]

So you add one line to your config to replace colons with spaces? I'm not sure that's a legitimate reason to bail on trying it.

[sliverstorm]

I don't own all the configs.

[chasingtheflow]

fair.

[mixmastamyk]

I use fish. I write short scripts in bash and longer ones in Python for portability. Everyone's happy... posix has never come up.

[jlgreco]

> Want to run a bash script? Just run bash fooshnizzle.sh

Why not just

  #!/usr/bin/env bash

? In zsh I never worry about running bash scripts because they run by the kernel with the shell/interpreter specified after the hashbag.

[SnowLprd]

Same thing in fish. Either way works just fine.

[Paul_D_Santana]

🐟

Where did you get that fish? And are there more animal characters?

I'm surprised I can copy it into other apps and it doesn't bug out.

🐟