Hacker News Reader

I use fish and on the very, very rare occasion I need to copy and paste bash from the internet it's pretty easy to just type 'bash' into fish and paste it in. Its not like bash and fish conflict, you can have them both installed.

FWIW, fish is much more bash-compatible these days. We've introduced support for a lot of bash-isms that don't completely break the fish spirit or clash with its syntax in the last few releases.

I personally liked "; and" but... "&&" solves around half of the problems with copy-pasting and does not look terrible, so it was probably the right thing to add.

Thanks! I'm trying fish once in a while, and currently, the following are missing:

    $ cat <(echo "Hello")
    Hello
    $ cat <<<"Test"
    Test

In regards to the former, you use the psub function instead of special syntax (a pattern that fish often follows):

$ cat (echo Hello | psub)

Also, fish doesn't have here-strings/here-docs, I believe. That is far and away the main thing I miss in fish.

> 2. For standalone scripts... well, I think it's best to reach for a proper programming language (e.g. Python) instead of any shell language, but if I had to use one, I would pick bash. Sure, it has many footguns, but I know them pretty well. And fish language is also not ideal - e.g. IIRC it doesn't have an equivalent of `set -e`, you have to add `; or return 1` to each line.

I'm sure you know this, but: no particular reason the interactive shell you use has to match the shell you use for scripts. All of my scripts are in bash, but I haven't used bash interactively in decades now, at least on purpose.

I write all my scripts with the hash bang as "#! /bin/bash" so even though fish is my interactive shell, I still use bash for all shell scripts. I think the restrictions you mention only apply if you use "#! /bin/sh" rather than bash specifically.

Just fyi, you should use `#!/usr/bin/env bash` instead of `#!/bin/bash` or whatever because you can't assume the location of bash (but the location of `env` is indeed portably fixed). e.g. FreeBSD (and macOS?) has bash at `/usr/local/bin/bash`

And NixOS has bash somewhere in the Nix store... :)

Clarification: /usr/bin/env should be used for pretty much every shebang since it looks up the binary on $PATH.

I'm confirming. Often, when you run a script on more than just your own computer, bash is located in unexpected places.

For me, for example: `/data/data/com.termux/files/usr/bin/bash`

In such cases, scripts containing the absolute path to bash in shebang do not run correctly.

bash is /bin/bash on macOS, unless the user really likes bash, in which case it's probably /opt/homebrew/bin/bash or /opt/local/bin/bash

In any of those cases, using `/usr/bin/env bash` gets what the user probably wants

Yeah I'm just commenting on what the path for that would be

I wouldn't say I particularly like bash, bash has seen a ton of improvements since Apple stopped updating the vendored version. Using that old bash which is frozen for non-technical reasons just seems stupid to me.

If you don't want bash-specific features, you might as well use zsh or dash or whatever lives in /bin/sh. If you do want bash-specific features, you might as well take advantage of the latest and greatest.

On that note, on my Macs, the bash I want is usually /opt/pkg/bin/bash or /run/current-system/sw/bin/bash :)

That assumes you care about portability. Not everybody does.

Writing portable software is difficult, and doing it for shell scripts even more so. Blindly pursuing portability for its own sake is not worth it. Weigh the cost of portability against the odds that the software will ever run on different systems.

For me personally it is never worth it to write my personal programs portably. This would require that I test them on different systems that I do not even use. Pointless.

It’s not so much a portability thing IMO as it is a utility thing. If I have a newer bash in my PATH than what is in /bin/bash, I want to use it.

I “devolved” mostly along the same path. Bespoke shell to OMZSH to Zsh to Bash.

Zsh has a few nasty Bashism footgun incompatibilities. If I remember correctly the worst one is with how globbing / “*” works, which is why that is guarded with an option.

My main reason for sticking with Bash is that it’s everywhere, and the places where it isn’t try very hard to support the most-used featureset of Bash.

A stock Bash shell does feel a little naked without my dotfiles though :)

Bash on osx is pretty old due to avoiding GPLv3. I think they have zsh as the default login shell

True. But it’s easy to install Bash 5 via Homebrew or MacPorts.

Reading the associated issue (https://github.com/fish-shell/fish-shell/issues/510) about the lack of "set -e" was interesting as it highlighted how weird Bash, and shell scripting in general, is from a programming language perspective. Imagine programming in any other environment where every function you call could either succeed or fail catastrophically. There's some talk about adding exception handling to Fish, but maybe the sensible thing to do is to have a mode where Fish ensures that you've dealt with each possible error before moving on. Which is what you would do anyway if you were invoking external programs from a non-shell language (like Python's subprocess.check_call).

In any case the discussion in that issue made a convincing (to me) argument that if you're doing the sort of scripting for which "set -e" makes sense, which is most of it, you should be using Bash. That doesn't mean you need to use Bash interactively though, as others have pointed out.

> Imagine programming in any other environment where every function you call could either succeed or fail catastrophically

There's not much to imagine since that's pretty much every other language?

Sure you can recover with error handlers (sometimes[0]), but by default all of them will hard abort in case of exceptions.

In our modern language landscape shells are very much the odd ones, where errors are completely silent by default and the thing just carries on oblivious that the world around it might be crumbling completely.

[0]: https://doc.rust-lang.org/book/ch09-01-unrecoverable-errors-...

> Imagine programming in any other environment where every function you call could either succeed or fail catastrophically

Laughs in client-side JS.

Hmm? It’s not like a JavaScript exception crashes the entire browser tab.

Client-side JS is event-driven. An unhandled exception stops processing for that event, but doesn’t block other events.

But, scripting languages are not programming languages, scripting languages are made to run commands, and by default a script should halt if a command fails, at least in the CLI execution context. The problem is, scripting languages mix programming context and scripting context, so a condition written in the script shouldn't be treated as a CLI exit status. Anyway, I don't use fish for scripts just for the lack of exit on command error. That's essential while scripting.

I think that oilshell is aimed at people like you. I’ve never used it, but their website does make some interesting points about how a shell ought to work and how this could be compatible with bash.

As a go programmer, "; or return" makes a lot of sense to me