Hacker News Reader

Comment by andix | Hacker News Reader

I really don’t get this argument. In my shell I don’t type scripts on the prompt.

I use fish most of the time as a shell, but I still write bash or even sh scripts, because fish is not installed on most systems. If you run a bash script from fish, it is still executed by bash (because of the shebang).

View on HN

Even something like

   # only test if the build succeeds
   ./build.py && ./test.py

didn't work in fish until recently. It used to be 'and' but they recently added && for compatibility.

I think redirects and possibly pipelines work differently in fish too, although I don't remember the details. I type those on the command line frequently. I occasionally use loops as well, though when it gets big I do put it in a file.

It looks like all of these are the same

    echo hi > out.txt
    echo append >>  out.txt
    sort < stdin.txt
    ls /bad 2>&1 | tee out.txt

But here docs don't work the same way:

   sort <<EOF  # syntax error in fish

I don't really like the here doc syntax so I guess that is pretty good. The && issue is still there on my Ubuntu Bionic machine:

    fish: Unsupported use of '&&'. In fish, please use 'COMMAND; and COMMAND'.

ls && ls

The && syntax was added in fish 3, released in 2018.

Redirects and pipes work as you'd expect. Loop syntax is different. The difference in subshell invocation is the thing that sticks out the most: $(cmd) vs (cmd) in fish.

Piping and redirects seem to just work, command substitution is always just parentheses with no $ in front. Process substitution is not magic syntax like in sh, it's just a command that reads from stdin, writes to a temporary file, and outputs the path to that file:

vim (ls -lh | psub)

But one of the selling points of fish is (from their website, I am not a user) that it has sane scripting.

That point appealed me most. If I continue have to use bash for scripting, I wonder what fish provides over zsh.

I think fish's syntax is cleaner, though as others have pointed out, the incompatibility is often not worth it.

Even though it's "sane", I would say it's not "powerful". It's significantly less powerful than bash, e.g. there is a list of missing things here:

https://github.com/pirate/fish-utils/blob/master/README.md

The first one seems like one of the bigger issues: https://github.com/fish-shell/fish-shell/issues/159

I have a particular viewpoint since I'm writing a shell for scripting, and I wrote this FAQ. http://www.oilshell.org/blog/2021/01/why-a-new-shell.html#wh...

But I didn't come up with that list of issues, and I've only used fish a tiny bit.

#159 kind of works with the `string collect` mechanism, although it is indeed not very obvious, compared to bash:

    set file_contents (cat filename | string collect -N)

I understand that this is purely anecdotal, but I'm using fish for quite a long time, I've written a lot of tooling for myself in fish, and I agree that sometimes there are some things which are annoyingly missing from fish (like this multiline variable thing), but I would not say it makes fish significantly less powerful. And these things are sometimes fixed, too.

For me, the main thing fish provides over zsh is nice defaults. oh-my-zsh can be incredibly slow, and without it zsh does take a reasonable amount of scripting & setup to make it as "nice" to use (which is why oh-my-zsh exists).

I think their "sane" scripting is more about ux for writing short disposable logic (the type you write in a terminal), rather than more detailed/advanced/structured programming that you might save to a shell script file.

Bash/zsh walk the line of being usable enoughh for typing terse quick commands (terminal syntax) while also being complex enough for writing large scripts (programming language). They end up being imperfect at both.

Reply on news.ycombinator.com