Inxi and neofetch shows different shell

[Dipanjan]

1. {neofetch} shows that current shell is bash whereas {inxi -I} shows current shell is fish.
2. {echo $SHELL} shows the following:
   {/bin/bash}
3. {echo $0} shows nothing

I am using Garuda KDE Dr460nized edition.

How to know which shell is running?

[SGS]

Welcome

---

Neofetch

Shell: fish 3.3.1

inxi -I
Info:  Shell: fish inxi: 3.3.08

echo $SHELL
/bin/fish

The following works on zsh, bash, and dash, but not on csh:

$ echo $0

I check this on Garuda i3wm

And

cat /etc/shells
File: /etc/shells
# Pathnames of valid login shells.
# See shells(5) for details.

/bin/sh
/bin/bash
/usr/bin/git-shell
/bin/zsh
/usr/bin/zsh
/usr/bin/fish
/bin/fish

[dr460nf1r3]

Bash is login shell to preserve compatibility while fish is used in Konsole/Alacritty for a better user experience

[thunder-son]

what terminal app have you run ? konsole or alacritty ?
neofetch display the default shell you use on your garuda system, shown by
Garuda assistant>Settings> Default shell.
try read alacritty config

kate $HOME/.config/alacritty/alacritty.yml

you will see about line 327, 328, 329 the default shell path of alacritty . By default alacritty configuration use as a shell: fish
each terminal app can use own shell which is different of default global shell of the system.

[h2-1]

Technically, if in doubt, inxi is far more likely to be right about your current real shell and the 'running in:' item than neofetch, because inxi runs a lot more logic to get that data, and uses a more powerful language to get it, than neofetch does. Handling the corner cases with that logic is extremely difficult, to put it mildly, but a lot of stuff that was basically unimaginable to do with Bash is simply an interesting problem with Perl.

It's still possible to make inxi get the wrong shell or 'running in:' item, but it's much harder than it used to be.

Neofetch focuses on being a bash tool that is cross platform, with its distro ascii art stuff, but doesn't get the difficult details right in many corner cases, at least from what I've seen. inxi focuses on getting the stuff as right as possible for the biggest part of its user base as possible (in other words, man hours are spent to help the most users per man hour, with some major exceptions), and doesn't worry about the ascii art or how much code is required to get stuff right.

Getting stuff right more often takes more code than neofetch uses, and it's a lot harder to do with bash than with Perl, which is a big reason inxi moved to Perl from bash/gawk several years ago, far too often the language was the obstacle that was blocking the logic with Bash, that never happens with Perl. Basically Bash discourages complex logic and data structures, and Perl encourages them, since its essence is to be a Practical Extraction and Reporting Language.

Any time inxi is having trouble being consistently 'right', that generally leads to a refactor of the logic, so it can then be right more. These refactors tend to take the logic away from the crude form it had to use in bash, and towards a more complicated robust form that Perl enables. One such refactor is starting with some 'core' cpu logic right now, for example, because it's having trouble being 'right' consistently when it comes to certain cpu report features.

Trying to do advanced logic in bash is like trying to pull a 1 ton load with a bunch of bicycles. Yes, you can kind of do it, but it's a real pain, and not a very good idea. Having made that mistake myself several times, I empathize with anyone who has gotten trapped with a growing bash application, because at some point they have to rewrite to a proper language, and the longer they wait, the harder it is to rewrite.

Having done way too much bash myself, i was somewhat impressed with how neofetch is written, only it's so 'cleverly' done that in many cases you can't correct corner cases because the code is too terse (those are what cause some of the failures I've seen in it sometimes), and you can't ever escape the fact you are working with a radically incomplete shell language, which was never really intended to be a full scale programming language, even when you use all the latest neat features, it's still just a shell, meant to do shell things.

The old formula was if you find your program is getting over 100 lines long, it's time to drop shell and use a real language. In retrospect, I suspect 100 lines is too much, probably better to cut it off at 50 lines before it gets too complicated, or, better yet, realize it's going to be longer, and never start with shell in the first place. I wish I'd followed that rule on every single shell program I've ever written, because the end result has without exception been a weak, hard to maintain, non robust, program with no future, instead of a clean, powerful, easy to expand and debug, bit of software that can grow into the future. Live and learn...