If you're running scripts, what difference does it make that you use fish? You're not really supposed to write scripts for fish, unless it is meant to be used be the fish shell itself. A shebang on the top of your script will invoke the script with the right executable, and whether you called it from bash, zsh or fish would make no difference.

So, instead of just typing shell commands, you type something else, but as soon as you need a shell script, you have to go back to shell commands.... Why not just cut out the middleman?

Answer to the first question: yes. Answer to the second question: because bash is a rather poor terminal shell.

In my experience, the middleman you mention doesn't exist. Or, if anything, it is a very tiny man that hardly gets in the way. It's either a one-liner with a syntax change you can pick up in 5 minutes, or it falls under any combination of these:

- might as well belong in a script

- the complicated stuff is in awk or the likes

- you can just enter bash for any copy-pasted bashisms

- you can execute it explicitly with bash -c

In any case, none enough of a hassle that it could demerit the immense productivity benefit I've gotten from fish. The only regret I have on that matter is not having ditched it sooner. Use bash to run scripts, or even better, sh. Use a different shell to make your life on the terminal better. Doesn't need to be fish, zsh is pretty good too.

If I can offer any advice: if you still want to stick with bash, at the very least take a look at fzf, https://github.com/junegunn/fzf , aside from fish/zsh it's the best and most lowest hanging fruit.

I personally use zsh, bash is too primitive with regards to its user interface (line editing, searching, vi keys, etc.) The syntax however is my key point here, I often take my commands and smack them into Makefiles for example.

> You're not really supposed to write scripts for fish

Given that 95% of my time in a shell is running a script, a shell that doesn't do that well isn't a great fit for me.

> A shebang on the top of your script will invoke the script with the right executable,

Assuming the person who wrote it had the foresight to do so. That person isn't always me, and if I have to manually check if each script I run has a shebang, I should just default to running them in bash.

I haven’t seen a shell script in ages that was missing the shebang. Is this common in some places?

I’ve started to write dash scripts because that seems to be reasonably posix and bash on macOS is ancient.

I don’t think I’ve ever seen a script written without the shebang.

Btw, you can get around the ancient bash in macOS by installing a more modern bash and invoking with /usr/bin/env bash as your shebang. Not sure if that’s a great idea, mind you, but if you’re already writing scripts in something non-portable, it’s an option.

There are hundreds of sh files on github that don't have a shebang. Just because you don't write them and your colleagues don't doesn't mean they don't exist in the wild.

I didn’t mean to imply that they didn’t exist nor that it might not be important to account for them in some contexts. I meant only to convey my own personal experience: that it had never occurred to me that I might need to account for a missing shebang, since providing an interpreter for a script via shebang is all I have ever personally encountered.

wait how does the OS even invoke an interpreter without a shebang? If you have to explicitly call an interpreter when you invoke it, then it's no extra work to call

    bash some_script.sh

anyway

As I’ve learned in response to this thread, apparently some (but not all) Unixy OSes will run a file marked as executable using /bin/sh if no shebang is supplied.

Oh right, I think that's part of how APE[1] works. But I thought the Thompson shell was old and weird, and that it might not support what people use when they write ‘POSIX’ shell scripts nowadays.

Anyway it sounds like in that case the OS _doesn't_ know how to run the script, it just assumes `/bin/sh` will do.

I always assumed that scripts without an interpreter line were like snippets to be invoked via `source`, from some shell script with knowledge of the context in which it should be used.

Anyway, if that's the way it works, the behavior actually isn't a problem for users of Nushell or Elvish or Fish or anything else, since their executables are never installed to `/bin/sh` anyway. Nushell probably gets installed to `/usr/bin/nu`, Fish to `/usr/bin/fish`, and `elvish` can be installed anywhere. So it's still not clear that there's a real problem with un-shebanged scripts when it comes to using a boutique shell for login.

—

1: https://justine.lol/ape.html

Any random blog post that you find with instructions to run something in a shell that uses a variable just won't work copy and pasted, you now need to either modify them for your esoteric shell, or wrap them in a script to be ran through bash

I would consider a person who doesn't use a shebang to be bad at their jobs.

Even the most basic of tutorials will include it even if it means nothing to the user.

That's not entirely weird to me.

For the longest time bash was in various states of disrepair on different Unixes. I could make it segfault pretty easily.

I wrote scripts that had to run across Linux, BSD, HP-UX, Solaris, and AIX at the time. So we relied on a ksh88 implementation on each. Whether it was AT&T, mksh, or pdksh, it was fine. Couldn't rely on 93isms, but basically anything POSIX was cool.

I used ksh93 interactively for the longest time. But then Linuxes stopped testing interactive use w/ their packages and it became unusable (looking at you RedHat). So I used bash interactively but still wrote those ksh scripts.

These days, I use zsh locally on MacOS and BSD, but mostly write bash scripts for those and Linux. I still stick to the POSIX habits I have for portability. But the variances are so less. The only one that annoys me is the "does sed -i do in-place" game.

I don't think my interactive shell and target scripting shell have ever matched 1:1 in feature set. And what I slap together interactively or for 1-off script, I would never do for a "real" script. And that's a thing that bugs me with a lot of shell scripts I see in the wild.

A "real" script should make very little assumptions, fail safely, be low on resource utilization to not risk impacting a business workload, and be maintainable. I write everything real like it might be run thousands of times accross thousands of hosts. Even when I didn't intend for it to be, I've caught it in the wild because someone borrowed what I did.

I do love shellcheck, because it teaches our newer folks good habits and they're used to that kind of feedback in other languages. It catches so many things that make me cringe. It's not perfect, of course, but pretty great.

When I started out, I worked 9-6 and the Unix sages in my group worked later hours. So they'd walk through my work on the RCS host and I'd come into the morning with a critique in my email. If I didn't understand, I could hit their desk after lunch and they would patiently explain to me. I love them for it, but it is nice to have tools without a 24-hour feedback loop.

Shellcheck is nowadays a must for writing decent shell scripts. it is like a centralized knowledge base of all those brilliant minds that did the sanity checking for you in the old days :)

It boggles my mind that people use a language where

x = 0 doesn't work and x=$y is a security flaw

Sometimes it's easier to use tools you know will be available than to ensure your tool of choice will be available everywhere you need it to be. JavaScript, esp. pre v6, is another example that makes almost no sense when you ignore its ubiquity

> x = 0 doesn't work

Maybe it's just me, but I love how the assignment syntax can be used just for a single command: 'MANPAGER=cat man' is a lot nicer than '(MANPAGER = cat; man)'.

> and x=$y is a security flaw

When is variable assignment a security flaw?

if $y is untrusted input then you need to quote it or you've introduced shell injection attack to the script.

You don't need to quote variables on the right hand side of an assignment.

I used fishshell for years, and the bottom line ended up being that it created enough mental overhead to be a burden because it diverged from the UNIX norm too much. Sort of like the colemak keyboard layout, sounds great in theory, in practice, not so much.

Fish user here. I've accepted having to drop down to bash here and there. No big deal for me.

I tried fish for a short while too and quickly realized everything depends on bash/dash. I then switched to zsh which is mostly compatible. I installed Oh My Zsh and a fish-inspired theme with line autocompletion and coloring and never looked back. But I still use zsh for the interactive prompt only, still writiiing #!/bin/sh scripts for maximum compatibility between platforms.

I went through the same thing.

It also got on my nerves that scripts which did not identify themselves correctly as bash would run in [ whatever hot new shell im running ], often with bizarre results.