1. if you want to install something, give you a choice of a container or native install? 2. or ONE set of repositories whose goal is to provide everything Ubuntu requires snaps for? If I have to add a repository for everything I want pure not snap, that could get ugly fast. especially since IME, I go to update maintenance, and it tells me it can't get to all my repositories, but DOES NOT LIST WHICH ONE(S) it can't get to. Sorry if this is a stupid question: can I request to install something from a repository, without adding that repository to be used for EVERY other install I want to use? Remember, you guys are all way more expert than I am. as an aside, is there any movement to demand Ubuntu indicate whether something you want to install from them is a snap or not? I just went to look for the fish shell, and it DID tell me it was a snap. It didn't tell me for all the other snaps it shoved up my (censored). My first reaction was "that's too deep inside the system, a snap is asking for trouble", no way Then I thought, huh? isn't a shell just one program, no matter where? ..well maybe not, as I said, I'm ignorant Then I thought, well, maybe a snap just to try it out a little, if that's positive, seek an apt install. Carey

On 08/17/2025 6:16 AM CDT bitmap via Talk <talk@lists.gtalug.org> wrote:

I did try it 2-3 years ago. I am mostly familiar with zsh but I would prefer GPL over MIT license so wanted to switch. Couldn't manage to get bash set up to my liking. And I had seen posts about how cool fish was. Some people really like it.

## I didn't like fish

I honestly cannot recall what barriers got in my way but there were a few. I know that I spent quite a bit of time trying to orient myself. Enough that I was able to confidently conclude that the problems I was having were "working as intended", "not a bug" situations. So just not for me.

This in contrast to bash: In that case, I think solutions to many frictions likely *do exist*. I just don't know how to do it owing to my inadequate skills. I haven't given up on bash, just put it away for the time being.

In general, when it comes to the shell trying to be too "smart", I haven't enjoyed these features. Prediction, correction, auto complete: just get in the way. I like my tab, arrow up/down, type to filter history or available arguments, etc.

## But I like the fish vibe

Despite the (admittedly vague) criticism I still appreciate fish. I think it's cool to do something to try to address the needs of users who want to use the terminal in a different way. The fabulous thing about the terminal, is it can do *anything* which is available to computing. The little box is limitless. So we should have experiments in how to communicate with the computer. To see what else it can do.

Particularly I respect the explicit goal of making the terminal more accessible, pleasant and easier to dive in. Only with the assistance similar initiatives did I manage to get functional in the terminal. I wish the basic methods would be more widely available to people who aren't hardcore nerds. But since that's the existing userbase, the tools are catered to them. So-called "libre" software is name only when even the most basic tools are hidden from view of most people. But how to address that?

### making something innovative for non-experts = tough

It's a challenging project to suggest users, especially novices, to ditch one of the most standard components of the linux environment. By which I mean bash or other POSIX shell. Even if you manage to design something that's *objectively better* for some use cases, there is no way to compete with the maturity and depth of community support available to a bash user. When was the last time someone asked a *novel* question about bash? Every conceivable situation has been iterated to death. Vs with fish, having a minuscule user base, it's way less likely to find a good thread etc to help in your own quandary.

And it is very difficult to think of exactly who the users would be. Example: Fish has a feature to edit the dotfiles with a web interface. (https://fishshell.com/assets/img/screenshots/web_config.webp) That's actually a real neat idea because editing text files with their weird syntaxes and code can be overwhelming at first. So somebody thought to apply the Unix Philosophy to this task and make it more approachable by feeding the dotfiles through a little webserver. Sweet. :) Similar to `xfce4-settings-editor` or `dconf-editor` but not making any demands on the GUI environment.

But where are we finding people who: run linux, use the terminal, know what a shell is, take the initiative to switch to a non-standard shell--- *and* who are too nervous to edit text files in gedit? Perhaps this experiment can lead to some general improvements in helping users to gain confidence in the linux environment, but the idea as it is currently implemented is kinda confused.

I think a new linux user is best advised to go with the most standard things when possible, as it will be more likely to find solution for problems. When you start introducing strange components, nobody can really help you. If fish had a stronger community presence it might be more viable. I don't really have a constructive idea about how to solve that.

## conclusion

overall: Not for me on a daily or even monthly basis but the world is better with fish.

On Sun, Aug 17, 2025, at 2:35 AM, Evan Leibovitch via Talk wrote:

...

Wondering if anyone here has experience with the fish shell https://fishshell.com/, which I discovered as it is the default in Bazzite Linux.

Non-POSIX-compliant by design, it appears to be far more advanced in tab-completion and inline syntax checking than bash.

("You'll never write esac again", they say...)

Has anyone tried it? Is it anyone's daily driver? Thanks! - Evan ------------------------------------ Description: GTALUG Talk Unsubscribe via Talk-unsubscribe@lists.gtalug.org mailto:Talk-unsubscribe@lists.gtalug.org Start a new thread: talk@lists.gtalug.org mailto:talk@lists.gtalug.org This message archived at https://lists.gtalug.org/archives/list/talk@lists.gtalug.org/message/JADOBOC...

------------------------------------ Description: GTALUG Talk Unsubscribe via Talk-unsubscribe@lists.gtalug.org Start a new thread: talk@lists.gtalug.org This message archived at https://lists.gtalug.org/archives/list/talk@lists.gtalug.org/message/Q7RCLVD...

What they say is

Whenever possible without breaking the above goals, fish should follow POSIX. https://fishshell.com/docs/current/design.html So they will be POSIX unless not feeling like it.

More clear:

fish is intentionally not fully POSIX compliant, it aims at addressing POSIX inconsistencies (as perceived by the creators) with a simplified or a different syntax. This means that even simple POSIX compliant scripts may require some significant adaptation or even full rewriting to run with fish. https://wiki.archlinux.org/title/Fish

On Sun, Aug 17, 2025, at 9:28 AM, Steve Litt via Talk wrote:

Evan Leibovitch via Talk said on Sun, 17 Aug 2025 02:35:59 -0400

...

Non-POSIX-compliant by design, it appears to be far more advanced in tab-completion and inline syntax checking than bash.

I saw nothing about POSIX on <https://fishshell.com/> , so what what leads you to say it's non-POSIX compliant?

SteveT

Steve Litt

http://444domains.com

------------------------------------ Description: GTALUG Talk Unsubscribe via Talk-unsubscribe@lists.gtalug.org Start a new thread: talk@lists.gtalug.org This message archived at https://lists.gtalug.org/archives/list/talk@lists.gtalug.org/message/CVOURHQ...

On Sun, Aug 17, 2025 at 12:33 PM Steve Litt via Talk <talk@lists.gtalug.org> wrote:

The preceding quotes are a whole lot different from the Poetteristic "Non-POSIX-compliant by design". Nobody's 100% POSIX compliant, and these quotes don't mean they're going out of their way to discard POSIX. There's a big difference.

Functionally there isn't. Much that one would expect from a POSIX shell is fixed/broken depending on perspective. The migration path is significant. In any case, this is all mostly moot. Since many (and many more to come) just use chatbots to write their scripts, ease of (human) coding for newcomers is increasingly a non-issue. If people install fish it will be because of the pretty colours and advanced tab completion. That may alone be enough to make it a useful replacement to people who will AI their scripts regardless of what language is in play. - Evan

On Sun, Aug 17, 2025 at 9:34 AM Steve Litt via Talk <talk@lists.gtalug.org> wrote:

Evan Leibovitch via Talk said on Sun, 17 Aug 2025 02:35:59 -0400

...

Non-POSIX-compliant by design, it appears to be far more advanced in tab-completion and inline syntax checking than bash.

I saw nothing about POSIX on <https://fishshell.com/> , so what what leads you to say it's non-POSIX compliant?

From their handy (and necessary) guide to bash-to-fish migration <https://fishshell.com/docs/current/fish_for_bash_users.html>: *"Fish is intentionally not POSIX-compatible and as such some of the things

you are used to work differently."*

- Evan

On Sun, Aug 17, 2025 at 11:21:10AM -0400, D. Hugh Redelmeier via Talk wrote:

"works out to the box" BASH seems to work and come pre-installed on most systems. Not in (some?) debian, but ash or whatever debian defaults to doesn't cater to my muscle memory.

Debian defaults user shells to bash. It also defaults /bin/sh to dash since it is posix compliant and leaner than bash and if a shell script says /bin/sh it should not get bash features. -- Len Sorensen

It's arithematic expression, so an easy way to remember: number 0 --> returns 1 ("fail") number non-0 --> returns 0 ("success") On 2025-08-17 19:55, Ron via Talk wrote:

We've seen how bad bash can be just this week in another thread:

((-1)) returns 0 (success) ((0)) returns 1 (normally failure) ((1)) returns 0 (success)

It's this stuff I can't stand and would be unacceptable if introduced today.

On 2025-08-19 16:16, Ron via Talk wrote:

William Park via Talk wrote on 2025-08-17 21:51:

...

It's arithematic expression, so an easy way to remember: number 0 --> returns 1 ("fail") number non-0 --> returns 0 ("success")

You're right, once one knows about it it's easy to remember.

But it's highly counter-intuitive (*who* here knew about this behaviour before this thread?).

And bash is littered with such weirdness.

This is actually not a bash-ism. Early Unix (at least V7) used 0 as a successful program completion code. Because numbers other than 0 were used to designate the kind of error. The most logical would be to make true=1=sucess and false=0=failure but there is no way in the 8bit return code of V7 to specify what the failure was. This specific problem is older than Bash. Bash just inherited a weird answer. BSD carried it on with and then Linux. Take a look at /usr/include/sysexits.h -- Alvin Starr || land: (647)478-6285 Netvel Inc. || home: (905)513-7688 alvin@netvel.net ||

From: Ron via Talk <talk@lists.gtalug.org>

But it's highly counter-intuitive (*who* here knew about this behaviour before this thread?).

And bash is littered with such weirdness.

Two values summing to zero gives the same result as "a" + "b"?!?

$ (("b"+"a")) ; echo $? 1

$ ( ((0+0)); echo $? ) 1

$ ( ((0+1)); echo $? ) 0

It's just mindbogglingly illogical and utterly nonsensical (in my not so humble opinion).

You seem to be reallly upset about what (( )) does for a result code. But it is clearly spelled out on the tin. What I'm upset about is that the ((,,,)) composite command is a hacky extension to the Bourne Shell. I have no idea why it is a good idea. I've never used it even though I've used the BASH since it was released. Allowing assignments within that expression that affect the environment outside is, uh, unnatural. But without them, the only purpose could be to set the result code. It does two things badly. A more natural form would be that (( )) evaluates an expression and produces a string that is the result. In addition, it sets the result code to reflect actual errors (eg. division by 0). The set -e would behave well. And while I'm complaining: why does (( )) allow for silent overflow when the result doesn't fit in some "fixed width integers"? At a minimum, it should fail on overflow. But in a language like this, it should just get the right answer, as a string. Things get dicier with fractions but they are not supported anyway. Oh, and that wording is silly because every integer has a fixed width; what they mean is that all calculations are done in some C integral type with undisclosed range. Yuck! Just a badly designed feature that trapped you. Don't use it unless you understand it.

D. Hugh Redelmeier via Talk wrote on 2025-08-19 23:49:

You seem to be reallly upset about what (( )) does for a result code.

I guess that's one way of putting it.

But it is clearly spelled out on the tin. Yes. But also, "0+0 returns an error. RTFM." isn't great except to verify that it's intentional (which might be worse).

In fact, "RTFM", "it's easy to remember", "it's an historical precedent", without acknowledging it's dumb is what might be most frustrating. After all, I'll probably not encounter this "bug"; who checks exit codes of math ops vs the results? I get it's an historical anomaly and quirky features are everywhere and trying to understand the "why?" helps one's understanding. Not working in this case. I'm used to hearing about what a joke {PHP | JavaScript | ...} is, but bash is left out of that. It deserves mention. bash status: ((Love--)) ((Hate++)) Can I just point out that fish feels *fast* and *multi-line auto-complete* options are amazing. With *descriptions* of the choices offered too! fish status: ((++Love++)) ((--Hate--)) I'm on board with rewriting crufty relics with streamlined options and discarding anachronistic "features".

On 2025-08-20 10:45, CAREY SCHUG via Talk wrote:

mainframe ignoramous here.

We can start a script with #!/bin/fish

or whatever it is called and use different shells for different scripts, right? and call bash scripts from within the fish script as long as they start with #!/bin/bash ?

or am I missing something?

Seems like so much hate for something that can be kept on the sideline and used occasionally. are there system variables or parameters that cannot be passed from bash to fish and back?

The unix rule is If the file is executable and has #! as the first 2 characters then it will execute the program on the rest of the line passing information to the executed program as the first parameter. So if the file "/tmp/xxx.sh" has: #! /bin/cat hello world The program cat will be executed as "cat xxx.sh" Wikipedia explains it well in: https://en.wikipedia.org/wiki/Shebang_(Unix) -- Alvin Starr || land: (647)478-6285 Netvel Inc. || home: (905)513-7688 alvin@netvel.net ||

From: Evan Leibovitch via Talk <talk@lists.gtalug.org>

On Wed, Aug 20, 2025 at 3:23 AM Ron via Talk <talk@lists.gtalug.org> wrote:

...

Did you end up going with Bazzite?

Sorry, you've asked this a few times and I've been meaning to answer.

TL;DR: No, I ended up at Fedora and am very happy with a few caveats

Bazzite's concept of an 'immutable' system based on Fedora Atomic Desktop may be good to keep Linux newcomers from accidentally damaging their system, but for someone using Linux since the turn of the century that just gets in the way.

Immutable has been cool for a while. (My PhD work, finished four decades ago, was on functional programming where everything is immutable.)

Bazzite is known for improved and streamlined Nvidia support, which does nothing for me on this all-AMD rig. It's also primarily aimed at being primarily a games system and secondarily anything else; I can and have installed Steam under Fedora, but to me that's Just Another Repository rather than the OS's main reason for existing. Games that work on the Steamdeck Just Work on Fedora too.

Steamdecks use AMD APU's. So AMD support ought to be good. But they have iGPUs that are a few generations behind that in your box.

The final straw was the slow boot time. Really slow. Between two and four minutes.

Annoying. I tend to only boot every couple of weeks -- when I feel the urge to do updates -- so slow boots would not be a veto.

*"Run systemd-analyze blame".*

(The very existence of a software flag "blame" amuses me for some reason.)

This command is great. The old init systems didn't have such useful instrumentation. The other thing with blame: "git blame". Very useful. It shows you each line of a file prefixed with the revision and author of this line. So blame is good.

I admit to lacking patience, especially with a distro that touts itself as being super newbie friendly. I decided to go with Fedora as a safer, better understood path. No snaps and no software designed to lay blame. Haven't looked back for a moment.

Fedora does have flatpaks. I think that they are slightly better, but pretty similar. I don't actually know when flatpak's are installed and when regular RPMs are installed. One of my machines has flatpaks for reasons unknown. You can check if you have flatpaks: "flatpak list". One annoyance: "sudo dnf update" won't update them. You can use "gnome software" gui updater or you can use "flatpak update"

My remaining challenges on Fedora are mainly power management. Sometimes USB devices won't work when waking from sleep and sometimes the whole system refuses to wake after sleeps and needs to be power-cycled. "Screen off but don't sleep" doesn't seem to work either. Any help on this issue is appreciated.

KDE or GNOME? You used to use KDE, I think. I only use GNOME. Where is "Screen off but don't sleep" setting? Fedora desktop (not server) goes to sleep after some minutes of inactivity. Unfortunately, only desktop input events are considered activity. This is somehow mandated by EU regulations. Changing the setting for you desktop screen is easy.but changing the settings for GDM (the login screen) is more arcane. Here's the command I use. It affects all users and GDM. for i in gdm $( ls /home | grep -v 'lost+found' ) do echo $i: sudo -u "$i" dbus-run-session gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type nothing done I have a little "mouse jiggler" USB device that I can use when I want to suppress blanking (rare).

Evan Leibovitch wrote on 2025-08-21 09:28:

"Run `systemd-analyze blame`"

I'll be honest, that's one of my favourite commands. D. Hugh Redelmeier via Talk wrote on 2025-08-21 23:33:

This command is great. The old init systems didn't have such useful instrumentation.

I might be late to reply, so thank you for pointing out this was not possible in the past. I just ran it on a few machines, it's nice to see <10s for the longest service to start (postfix). On my desktop, almost 50s for "plocate-updatedb", 44.5s for fsck, etc. At least systemd runs them asynchronously, so it's not noticeable.