Software-update: fish 4.9.1

Versie 4.9.0 van fish is uitgekomen met kort erachteraan een opvolger die enkele kleine problemen moet verhelpen. Fish, wat staat voor 'friendly interactive shell', is een Unix-shell met een focus op interactiviteit en gebruikersvriendelijkheid. Het kan bijvoorbeeld worden gebruikt als vervanger van Bash. Downloads zijn beschikbaar voor macOS, Linux, BSD en onder Windows is het ook in Windows Subsystem for Linux te gebruiken. De changelog voor deze uitgave kan hieronder worden gevonden.

fish 4.9.1

This release fixes the following problems identified in fish 4.9.0:

• On non-default keyboard layouts, fish executed bindings for physical keys instead of only bindings for the layout's key. For example, on the Dvorak layout, typing s would insert ; because there is a default binding for ; (#12968).
• When typing space to accept a character entered via certain IMEs, fish would insert a space instead of the desired character, which has been fixed (#12974).
• On macOS terminals, keys like option-l would execute bindings for alt-l instead of the historical behavior of inserting a character (like @ on a German layout) (#12973).

fish 4.9.0

This release exists mainly to work around an issue with the Konsole terminal which would cause shift-pageup to stop working. This release brings 151 new commits since 4.8.1, contributed by 26 authors, 18 of which are new faces.

Interactive improvements

• To mitigate issues in Konsole version v26.07.80’s implementation of the kitty keyboard protocol, fish no longer requests that protocol on Konsole. The omit-term-workarounds feature flag can be turned on to enable the kitty keyboard protocol on Konsole again (#12948).
• On some terminals like kitty, keys like shift-space and space can now be mapped independently (#12898).
• Fixed slow tab completion in directories that contain slow-to-resolve symlinks (e.g. links to network-mounted files) (#12905).
• Abbreviations can now be given a description, which will be displayed in the completion pager (#11291).
• Vi mode commands like cF and cT now work correctly (#12947).

Scripting improvements

• List indexing can now be nested in more cases; for example $foo[$bar[1] 2] is now allowed (#12903).
• Escaped square brackets (e.g. \133 for [) are no longer considered a slicing operator (#7969).
• Variables containing a closing square brackets and used to index into another variable will no longer close the slice early (#12819).
• Builtin help pages now respect an override of the man function (#12886).
• Commands like status=123 echo $status now throw an error instead of silently ignore the variable override (#7790).

Regression fixes:

• (From 4.6.0) Chinese and Japanese translation of error messages owned by the C library were broken (#12895).
• (From 4.3.2) Erasing read-only variables with set --erase was accidentally allowed.
• (From 4.0.0) Builtin fg was not working on NetBSD (#12929).

Versienummer	4.9.1
Releasestatus	Final
Besturingssystemen	Linux, BSD, macOS, Windows 10, Windows 11
Website	Fish
Download	https://fishshell.com
Licentietype	GPL

Reacties (21)

[Jack Flushell]

Gebruik deze al een paar jaar op mijn laptop en heel tevreden mee. Vooral de auto-complete werkt voor mij beter dan de standaard bash auto-completion: hij onthoudt vooral de relevante dingen. De kleurenprompts zijn onnodig, maar uitermate noodzakelijk als nerd .

[L0g0ff]

Ik heb er ook een maandje mee gespeeld auto complete was goud. Maar zo vaak dat bash scripting brak dat het niet betrouwbaar genoeg was voor me.

Ik wil niet moeten denken elke keer of een issue aan fish ligt of aan het script wat ik draai.

Ik ben overgestapt naar zsh icm ohmyzsh met auto complete plugin en dat werkt nagenoeg hetzelfde en is wel posix compliant.

Voor de liefhebber; ik heb een justfile met mijn config hier staan: https://github.com/L0g0ff/KompassOS/blob/main/files%2Fjustfiles%2Fsetup_zsh.just

[The Zep Man]

Ik wil niet moeten denken elke keer of een issue aan fish ligt of aan het script wat ik draai.

Als je script de juiste shebang heeft aan het begin (#!/usr/bin/env bash) en je het direct aanroept vanuit wat voor omgeving dan ook, dan draait het script gewoon onder bash en heb je geen compatibiliteitsproblemen.

[Reactie gewijzigd door The Zep Man op 4 september 2026 09:19]

[L0g0ff]

Ja eens, maar dat blijkt dus niet altijd het geval te zijn. En dan zeggen scripts soms krak terwijl het met bash/zsh wel doorloopt.

[beerse]

De echte #! is #!/bin/bash of #!/usr/bin/bash. Dan weet je zeker dat je script met bash wordt gedraait.

Als je "#!/usr/bin/env bash" gebruikt, ga je alsnog door je environment heen op zoek naar de bash die daar in geconfigureerd is. En als dat dan een alias/functie is om fish (of welke andere shell) te starten, ga je alsnog nat.

Als je #!/usr/bin/env wilt gebruiken, doe daar dan wat mee. En geef dan ook het path naar de shell op zodat je die ook forceert. Bijvoorbeeld "#!/usr/bin/env -i /usr/bin/sh".

[The Zep Man]

De echte #! is #!/bin/bash of #!/usr/bin/bash. Dan weet je zeker dat je script met bash wordt gedraait.

Je kan maar één pad opgeven. Dus niet en /bin/bash en /usr/bin/bash. Dit is dus geen oplossing. Je weet niets zeker.

Als je "#!/usr/bin/env bash" gebruikt, ga je alsnog door je environment heen op zoek naar de bash die daar in geconfigureerd is. En als dat dan een alias/functie is om fish (of welke andere shell) te starten, ga je alsnog nat.

Het is niet de taak van een script om fouten of afwijkingen van standaarden door de gebruiker of het systeem te compenseren (tenzij je het er expliciet voor schrijft). Zo kan een Bashb script bijvoorbeeld niets doen als Bash helemaal niet beschikbaar is.

De man page van env gebruikt geen absolute paden om naar de interpreter te refereren. Keep calm and follow the standards.

[Reactie gewijzigd door The Zep Man op 4 september 2026 18:53]

[beerse]

De standaard in deze is dat /bin/bash er is voor boot, root en systeem taken. Die is er 'altijd', maar mogelijk beperkt. De /usr/bin/bash en zo zijn er voor gewoon dagelijks gebruik.Het is al sinds vorige eeuw gebruikelijk om dat zo te gebruiken, zowel in scripts als in $PATH.

Uiteindelijk zijn /bin/bash en /usr/bin/bash op veel systemen gelijk. Zeker daar waar het 1 filesysteem is, daar is het vaak zelfs fysiek de zelfde inode.

En in de #! regel kan en mag je elk commando opvoeren als de hele regel maar werkt als commando met als eerste een path naar een executable die de rest van de regel op de commandline krijgt (zonder shell-interpretatie) en dat hele commando krijgt de rest van het script op stdin. Meer doet die #! regel niet, minder ook niet.

Voor de echte script-hackers: daar kan ook #!/usr/bin/awk of #!/usr/bin/ftp en dergelijke staan. Been there, done that.

Wat env daar doet is de environment variabelen aanpassen. Als er dan een executable met de naam 'bash' ergens in je $PATH staat dan zou dat zomaar opgepakt kunnen worden, ook al is het toevallig een executable-script dat heel wat anders doet. Dat /usr/bin/env het commando bash oppakt en daarbij gebruikt maakt van het $PATH, dat is aan env. Mijn scripts zijn zo min mogelijk onderhevig van afhankelijkheden. Als systeembeheerder ben ik voorbereid op hak en zaag werk dat ik in het verleden zelf heb gedaan om rechten te krijgen.

[MartenBE]

De standaard in deze is dat /bin/bash er is voor boot, root en systeem taken. Die is er 'altijd' ...

Niet op alle distro's, dus blijkbaar toch geen standaard. Op mijn NixOs:

$ /bin/bash
zsh: no such file or directory: /bin/bash

$ /usr/bin/env bash
[martijn@pc:~]$ # Succes!

En dan hebben we nog niet gesproken over BSD, Guix, MacOS (recente versies staan in homebrew), ... .

[Reactie gewijzigd door MartenBE op 4 september 2026 21:13]

[RoestVrijStaal]

Vreemd. Hoewel in de linux wereld /bin "legacy" is, zou de symlink van /bin naar /usr/bin wel moeten bestaan voor compatibiliteit.
Dat zegt meer wat over NixOS dan over andere distro's en *nixen.

[The Zep Man]

Vreemd. Hoewel in de linux wereld /bin "legacy" is, zou de symlink van /bin naar /usr/bin wel moeten bestaan voor compatibiliteit.

Niet alles is Linux. Bash draait prima onder andere besturingssystemen, zoals BSD en macOS. Niet alles daarvan heeft behoefte aan /bin. Als een script daar iets hardcoded uit aanroept, dan is dat een fout in het script en niet in het OS.

[Reactie gewijzigd door The Zep Man op 5 september 2026 09:00]

[rbr320]

Het belangrijkste is gewoon om er niet vanuit te gaan dat je shell scripts portable zijn tussen Linux, *BSD en macOS. Als je die mate van compatibiliteit wilt zal je iets geavanceerders moeten gebruiken zoals Python.

[MartenBE]

Maar het is geen standaard (zoals bv. posix), dat is net mijn punt. Zeker nu met de grotere diversiteit aan distro's die soms op fundamentele manieren verschillen, mag je hier niet meer vanuit gaan. "Dat zegt meer wat over NixOS" is in mijn eigen een onbenullig argument: zulke distro's bestaan en worden nu eenmaal (meer en meer [^1]) gebruikt.

[^1]: https://gg-solutions.hashnode.dev/linux-the-silent-revolution

[beerse]

Voor een test: Voer het volgende commando uit (het is 1 regel):

echo echo hallo > `echo $PATH | cut -d : -f 1`/bash; chmod a+x `echo $PATH | cut -d : -f 1`/bash

en open daarna een nieuwe shell en start jouw commando:

/usr/bin/env bash

en vergelijk dat met

/usr/bin/env /usr/bin/bash

[MartenBE]

Als ze jouw $PATH kunnen hijacken, dan heb je grotere issues dan dit script want ze hebben dan al access tot jouw account. Daarbovenop wordt setuid genegeerd bij shebang calls [^1] wat privilege escalation via shebangs tegen gaat.

[^1]: https://www.in-ulm.de/~mascheck/various/shebang/#setuid

[Reactie gewijzigd door MartenBE op 6 september 2026 18:17]

[beerse]

Hier wordt $PATH niet gehackt, er wordt gebruik gemaakt van schrijfrechten in de eerste directory in je $PATH. Het is als voorbeeld om te zien waar/hoe je nat kan gaan als je er blind van uit gaat dat het $PATH werkt zoals je verwacht.

[MartenBE]

Ik weet niet goed waar je naartoe wil. Ik wou gewoon aantonen dat vertrouwen op `/bin/bash` ook niet allesoplossend is.

- `/bin/bash` is nu eenmaal niet overal ondersteund, want geen standaard.
- `env` is niet deterministisch.

Mijn conclusie is: Ok, er is dus geen deftige oplossing. Ik denk dat we dan hetzelfde denken?

[TeleMax]

[...]


Als je script de juiste shebang heeft aan het begin (#!/usr/bin/env bash) en je het direct aanroept vanuit wat voor omgeving dan ook, dan draait het script gewoon onder bash en heb je geen compatibiliteitsproblemen.

Dit is naar mijn mening het enige juiste antwoord. Als je scripts hebt/maakt zonder de interpreter te definieren is dat een MEGA-security risico en zou je er eigenlijk niet aan moeten beginnnen, vind ik.

Sinds januari 1992 heb ik bash gebruikt en half Nederland ermee gebouwd (en afgebouwd ), mijn ~/bin folder heeft nog altijd meer dan 100 (voor mij) essentiele bash-scripts via voor een groot deel nog backward compatible zijn met bash 1.1, maar sinds vorig jaar overgestapt voor mijn default werk shell op fish... sommige dingen zijn wat makkelijker, maar iets complexere scripts zijn en blijven toch echt bash.

Die ~/bin folder reist al 34 jaar met me mee en heb er 95% van mijn opdrachten mee kunnen doen. (nog geen 1 MB)...

[MartenBE]

Je stelt toch best fish niet in als login shell, niet alle distro's kunnen daar even goed mee overweg, en als je in emergency mode valt kan het zijn dat die niet goed meer werkt (wat je net niet wil op dat moment).

- https://fishshell.com/docs/current/index.html#default-shell
- https://wiki.nixos.org/wiki/Fish#Setting_fish_as_the_login_shell
- https://wiki.archlinux.org/title/Fish#Modify_.bashrc_to_drop_into_fish

Jammer dat ik zoveel moet werken in andere shells en environments: Fish is wel echt modern en goed. Zal voorlopig toch bij zsh moeten blijven, helaas :/.

[Jack Flushell]

Op mijn servers altijd bash inderdaad vanwege scripts. Vandaar alleen laptop en dan niet voor root.

[Reactie gewijzigd door Jack Flushell op 4 september 2026 23:48]

[RoestVrijStaal]

Ik heb liever bash autocompletion, want dat is op commando (TAB).

Hoe vaak mijn collega's wel niet per ongeluk de verkeerde commando uitvoerden door de "slimme" autocompletion van fish/zsh/etc.
En wie mag het weer fixen? Moi.

Vooral "leuk" bij mensen die onbekend zijn met de *nix shell, en dus eigenlijk maar half weten wat er gebeurd en dus wat ze doen.

[Jack Flushell]

Ik heb liever bash autocompletion, want dat is op commando (TAB).

Hoe vaak mijn collega's wel niet per ongeluk de verkeerde commando uitvoerden door de "slimme" autocompletion van fish/zsh/etc.
En wie mag het weer fixen? Moi.

Vooral "leuk" bij mensen die onbekend zijn met de *nix shell, en dus eigenlijk maar half weten wat er gebeurd en dus wat ze doen.

Ik vind het goud. En loop al meer dan 30 jaar mee in de *nix wereld. Overigens niet in server-omgevingen.