Im Allgemeinen wäre ich damit einverstanden, eine Hauptversion zu machen, mit Breaking Changes und so.

Die große Frage ist jedoch: "Wie viel brechen wir?". Gehen wir All-In und ändern zB die Befehlsersetzungssyntax auf $() (was ich eigentlich gerne hätte!) negativ codieren)?

Dann noch eine andere Frage: Wie viel sind wir in der Lage, zeitnah umzusetzen (niemanden würde damit gedient haben, dass wir zwei Jahre brauchen, um etwas zu veröffentlichen)? Eine kleine Hauptversion könnte eine schlechte Idee sein.

Dann gibt es das Problem, genug Karotten an coolen Sachen zu bekommen, um mit der Bruchstange einherzugehen - wenn die Änderungen sich nicht lohnen, werden die Leute nicht wechseln wollen.

Diese letzten beiden Punkte sind vielleicht ein bisschen zu doom'n'gloom, ich will nur nicht noch ein Programmier-Ding-mit-einem-Tiernamen-springen-von-Version-2.6-zu-3.

Okay, sagen wir, wir machen es. Wie gehen wir vor? Wie lange wird fish 2.x unterstützt? Verzögern wir das geplante Release-Datum für jetzt-3.0? Wird die arme @zanchey eine Kernschmelze erleiden und ein Wombat-Farmer werden? Bieten wir eine Möglichkeit zur Versionierung (zB fish 3.0 wird als "fish3" installiert oder wir benennen das gesamte Projekt in "Great Original SHell" um)?

Das ist also ein "Ja, wenn wir es schaffen". Ich würde vorschlagen, dass wir versuchen, 4 coole, kompatible Änderungen in den PRs zu erreichen. Dh wir verschmelzen #4149 und #4082 erst, wenn wir zwei weitere haben. Dann verzweigen wir einen 2.7.0-Zweig als Backup und führen sie alle zum Master zusammen. Dann versuchen wir einfach, 3.0 mit coolen Features voll zu stopfen, damit es 2.6.0 komplett in den Schatten stellt.

Außerdem wünsche ich mir eine größere Akzeptanz und Kommunikation mit der Community. Dass #4103 uns erst nach der Veröffentlichung erreicht hat, ärgert mich etwas, obwohl es schon früher entdeckt wurde.

Wir sollten so groß wie möglich gehen und uns dennoch auf eine Hauptversion in nicht mehr als sechs bis zwölf Monaten in der Zukunft festlegen. Denn sobald wir damit beginnen, werden wir nur sehr wenige Ressourcen haben, um Probleme mit dem 2.x-Zweig zu beheben. Wir sollten zum Beispiel () auf jeden Fall in $() ändern. Obwohl wir mit ziemlicher Sicherheit immer noch () außerhalb von Strings in Anführungszeichen erkennen müssen. Wir sollten auch die Gelegenheit nutzen, PATH , MANPATH und CDPATH nicht mehr automatisch in Arrays umzuwandeln, indem wir die Änderung der gebundenen Variablen, die ich im Gange habe, nutzen. Ähnliche Elemente zu finden, die in naher Zukunft implementiert werden können, sollte nicht schwer sein.

Meiner Meinung nach würde fish 2.x noch zwei oder drei Jahre lang unterstützt werden. Aber nur kritische Fehlerkorrekturen und möglicherweise neue Vervollständigungsskripte, die die Leute einreichen. Wir würden master zu einem Integration_2.7 Branch verzweigen und das wäre unser letztes 2.x Minor Release. Danach wären es 2.7.1, 2.7.2 usw., um kritische Fehler zu beheben.

Ob wir in "fish3" umbenannt werden sollten, ist eine schwierige Frage. Als iTerm 2.0 herauskam, wurde es als iTerm2 bekannt und befindet sich in /Applications/iTerm2.app/ . Aber iTerm 3.0 wird immer noch als iTerm2 bezeichnet und befindet sich im selben Verzeichnis. Das habe ich auch schon bei anderen Projekten gesehen. Und nur oberflächlich "fish3" zu nennen, macht es den Leuten leichter, beide Versionen zu installieren. Betrachten Sie die Situation zum Beispiel mit Python.

Eine weitere Änderung, die wir vornehmen sollten: math sollte eher ein eingebautes als ein Wrapper um bc . Dies muss in einer Hauptversion erfolgen, da wir bc aufgrund von Lizenzproblemen nicht einfach in unser Projekt einbetten können. Wir müssen also eine andere Implementierung auswählen, deren Lizenz mit diesem Projekt kompatibel ist.

Okay, also habe ich angefangen, Issues/PRs mit einem neuen Meilenstein "fish-3.0" zu versehen (und ich habe ein zufälliges Fälligkeitsdatum aus Hammerspace gezogen). Die vollständige Liste finden Sie unter https://github.com/fish-shell/fish-shell/milestone/18 .

Die Idee ist, dass dieser Meilenstein Dinge enthält, von denen wir ziemlich sicher sind, dass wir sie für 3.0 tatsächlich tun wollen, während "Next-Major" für vorgeschlagene Breaking Changes wäre.

math sollte eher ein eingebautes als ein Wrapper um bc sein. Dies muss in einer Hauptversion erfolgen, da wir bc aufgrund von Lizenzproblemen nicht einfach in unser Projekt einbetten können.

Ja, #3157, in der Liste enthalten.

Aus Sicht eines Distro-Packagers/Maintainers macht es mein Leben viel einfacher, wenn Breaking Changes immer nur in Hauptversionen auftreten und wenn das bedeutet, dass Hauptversionen häufiger veröffentlicht werden, dann ist das meiner Meinung nach keine schlechte Sache.

Wenn Sie der Meinung sind, dass wir den folgenden Major.Minor.Point haben, denke ich stark, dass Folgendes zutreffen sollte

Punkt: Nur Bugfixes
Minor: Alles Wichtige + Neue Funktionen, die die Kompatibilität nicht beeinträchtigen
Major: Jede Änderung, einschließlich brechender.

Das sendet ein klares Signal an diejenigen von uns, die Fische in Distributionen bringen, wann und welche Updates wir veröffentlichen können. In der openSUSE-Welt haben wir zum Beispiel Tumbleweed, das für Benutzer gedacht ist, die das Neueste und Beste wollen. Im Extremfall könnten Sie dort alle paar Monate eine neue Hauptversion erstellen und wissen, dass sich jemand beschweren würde (ich behaupte nicht, dass Sie es tun würden). Dann haben wir Leap, das konservativer gestaltet ist. Und während wir immer eine neue Fisch-Hauptversion für eine neue Leap-Version und eine Nebenversion (keine Pausen) für ein neues Leap Service Pack/Minor-Version nehmen würden, kann es sein, dass ich je nach Änderungen und der Zeit im Release-Zyklus keine neue Major-Version für einen neuen Leap SP abhängig von den Brüchen, dh ich nehme möglicherweise keine neue Major-Version zwischen Leap SP3-SP4, wenn sie mehrere Brüche hat, aber ich würde sie eher zwischen SP1 und SP2 nehmen. Ähnlich für unser Paketierungssystem für SUSE Linux Enterprise, obwohl Benutzer über OBS immer die neueste Version auswählen können, wenn sie dies wünschen.

Und dann würde ich für eine bereits veröffentlichte Version von Leap immer nur auf eine neue Point-Version von fish aktualisieren und wenn eine kleinere Version mit Bugfixes herauskommt, die den Benutzern wichtig sind, würde ich sie wahrscheinlich manuell in unsere Pakete zurückportieren.

Zusammenfassend schätze ich, dass ich es vorgezogen hätte, wenn Sie 3.0 statt 2.5 mit den Breaking Changes (insbesondere der Verhaltensänderung für laufende Anwendungen beim Beenden von Fischen) anstelle von Releases durchgeführt hätten. Wenn Sie grundlegende Änderungen vornehmen und die Hauptversion nicht ändern, bedeuten die Haupt- / Nebenversionsnummern nicht wirklich etwas.

Wir sollten zum Beispiel () auf jeden Fall in $() ändern. Obwohl wir mit ziemlicher Sicherheit () außerhalb von Strings in Anführungszeichen noch erkennen müssen.

Ich stimme hier zu, wenn Sie eine Änderung wie diese Kompatibilität für eine Weile vornehmen müssen, können Sie in fish 4.0 vielleicht etwas nach std:err drucken, wenn es erkannt wird, und die alte Syntax in fish 5.0 entfernen (Nur als Beispiel) es hängt natürlich von den tatsächlichen Veröffentlichungsfristen ab). Es wäre auch schön, wenn Sie eine Umgebungsvariable in fish 3.0 aktivieren könnten, um auch nach std:err zu drucken, um es den Leuten zu erleichtern, die versuchen, alles zu portieren.

Meiner Meinung nach würde fish 2.x noch zwei oder drei Jahre lang unterstützt werden. Aber nur kritische Fehlerkorrekturen und neue Vervollständigungsskripte, die die Leute einreichen. Wir würden master zu einem Integration_2.7 Branch verzweigen und das wäre unser letztes 2.x Minor Release. Danach wären es 2.7.1, 2.7.2 usw., um kritische Fehler zu beheben.

Wenn ich mit einem Distro-Maintainer-Hut spreche, gefällt mir diese Idee, aber wie viele kritische Fixes werden wir Ihrer Meinung nach finden? Für mich scheint Fish 2.X wirklich stabil zu sein, daher würde ich einen halben Weg in Betracht ziehen, den Zweig erstellen, aber keine Veröffentlichungen planen. Wenn kritische Probleme oder Sicherheitsprobleme auftreten, können Sie eine Veröffentlichung drehen, aber wissen, dass man sonst eine erwartet .

Ich vermute auch, dass die meisten Leute außerhalb derer, die nur die Version von fish verwenden, die die Distribution anbietet, ziemlich schnell auf 3.0 migrieren werden. Ich sehe diese Gruppe nicht so besorgt über neue Vervollständigungen usw. Von all den Leuten, mit denen ich spreche, gibt es nicht viele dieser Leute, die meisten sprechen davon, Fisch als interaktive Shell zu verwenden und verwenden immer noch Bash oder Python zum Skripting.

Ob wir in "fish3" umbenannt werden sollten, ist eine schwierige Frage. Als iTerm 2.0 herauskam, wurde es als iTerm2 bekannt und befindet sich in /Applications/iTerm2.app/. Aber iTerm 3.0 wird immer noch als iTerm2 bezeichnet und befindet sich im selben Verzeichnis. Das habe ich auch schon bei anderen Projekten gesehen. Und nur oberflächlich "fish3" zu nennen, macht es den Leuten leichter, beide Versionen zu installieren. Betrachten Sie die Situation zum Beispiel mit Python.

Ich denke nicht, dass wir das tun sollten, zumindest in der Linux-Welt tun dies die meisten Anwendungen nicht und diejenigen, die es tun, bereiten uns eine Menge Kopfschmerzen. Python ist ein anderes Beispiel, die Änderungen zwischen 2 und 3 waren massiv und viele Leute hatten massive Python-Codebasen und 10 Jahre später gibt es immer noch einige davon, von denen Knowone die Portierung auf Python3 noch abgeschlossen hat. Distros haben diesen Arch auch alle etwas anders gehandhabt, zum Beispiel hatte /usr/bin/python seit langer Zeit als Python3 und /usr/bin/python2 als Python 2. Python 2 -> Python 3 hatte mindestens 10 bis 20 als Big Break ändert sich als Übergang von () zu $(), ohne abwärtskompatibel zu sein. (Sie haben inzwischen erkannt, dass das zu viel war und werden mit Python nicht so weit gehen. 4)

Zumindest unter Linux ist es einfach, mehrere Fischversionen zusammen zu installieren, Sie können eine in /usr/local installieren. oder installieren Sie sie nach /opt/fish2 /opt/fish3, dann symbolisieren Sie sie oder verwenden Sie Update-Alternativen, um die tatsächlich verwendete auszuwählen. Dies lässt Sie immer noch mit beiden Versionen, die dieselben Konfigurationsdateien verwenden, und der Grund, warum Sie wahrscheinlich mehrere Versionen installiert haben möchten, ist, dass Sie noch nicht alle Ihre Konfigurationen / Skripte migriert haben. Um also mehrere Versionen zu installieren, möchten Sie auch neue fish3-Konfigurationsdateien erstellen, was für die meisten Leute mehr Aufwand ist, als es wert ist, da die meisten Leute wahrscheinlich in der Lage sein werden, die neue Version zu bekommen, um alle Probleme in der Konfiguration zu beheben und dann sei mit fish Version 3 zufrieden. Es wird einige Leute geben, die eine größere Anzahl von fish-Skripten haben, die sie portieren müssen, und ich würde erwarten, dass diese Leute in der Lage sein werden, beide Versionen gemeinsam zu installieren, bis sie portiert haben.

Es wird ein interessanteres Problem sein, wenn Fish 3 die Plugin-Manager wie Fisherman oh-my-fish usw. kaputt macht, aber dort sollten Entwickler wirklich die Betas ausprobieren, damit sie rechtzeitig fertig sind, aber wenn nicht, warten die Benutzer einfach und migrieren wenn es fertig ist.

Ich habe auch vergessen, in meiner letzten Nachricht zu erwähnen, dass ein weiterer Grund dafür, kein /usr/bin/fish3 usw fish 4.0 wird veröffentlicht, anstatt zu versuchen, sie in eine fish 3.X-Version zu quetschen, und die Binär- und Konfigurationsdateien erneut ändern zu müssen, würde diesen Prozess viel schwieriger machen.

@simotek : Vielen Dank für das Feedback.

Wie viele kritische Fixes werden wir Ihrer Meinung nach finden?

Sehr wenig. Wahrscheinlich nicht mehr als fünf in den zwei bis drei Jahren, von denen wir erwarten würden, dass sie sie unterstützen. Denn obwohl wir weiterhin Leute sehen werden, die Fehler gegen 2.x melden, werden nur wenige von ihnen genug Leute betreffen oder ein Sicherheitsproblem darstellen, um eine punktuelle Veröffentlichung zu rechtfertigen.

Deine Gedanken zu "fish3" spiegeln meine. Ich habe fish23, fish24 und fish25 mit verschiedenen Root-Verzeichnissen installiert. Damit kann ich das Verhalten älterer Versionen einfach testen. Aber da ich meine Fischkonfiguration so aktualisiert habe, dass sie sich auf die letzten Änderungen stützt, muss ich fast immer den env HOME=xxx fish23 Trick verwenden, wenn ich diese alten Versionen verwende. Nicht etwas, mit dem sich ein typischer Benutzer auseinandersetzen möchte. Was ziemlich stark dafür spricht, dass wir den Binärnamen nicht ändern. Jeder, der mehrere Versionen benötigt, wird bereit sein, über Symlinks und dergleichen damit umzugehen. Diejenigen, die das nicht tun, werden sich nur ärgern, dass es jetzt "fish3" statt "fish" heißt.

Warum die Syntax der Befehlsersetzung in $() ändern? Wird das in einer anderen Ausgabe diskutiert? Ich habe versucht, danach zu suchen, ohne Erfolg.

Außerdem bin ich ziemlich stark der Meinung, dass wir eine Veröffentlichung von Fish 3.0 in sechs Monaten als in zwölf Monaten anstreben sollten. Wenn das bedeutet, kein Fish 2.7-Release zu machen, denke ich, dass das ein vernünftiger Kompromiss ist.

Warum die Syntax der Befehlsersetzung in $() ändern?

Aus einer Vielzahl von Gründen, aber der wichtigste ist, Befehlsersetzungen innerhalb von Strings in doppelten Anführungszeichen zuzulassen. Auch für die Konsistenz mit ksh/zsh/bash. Es gibt keinen guten Grund für Fische, in dieser Hinsicht anders zu sein. Es mag andere geben, aber das Hauptproblem, bei dem dies diskutiert wird, ist # 159.

Meine 2 Cent sind einfach:
Wenn Python das kann, kann Fish es auch. Es kommt immer wieder vor, dass Ideen, die zu ihrer Zeit gut schienen, als veraltet oder sogar falsch angesehen werden, sodass Änderungen nicht nur wünschenswert, sondern tatsächlich notwendig sind, um die Qualität des Produkts zu verbessern. Bitte greifen Sie also zu den Änderungen, wenn die meisten von uns der Meinung sind, dass es sich um gute Änderungen handelt.

Noch ein +1 zum Fischen 3.0, FWIW. Ich bin sicherlich voreingenommen, weil ich ziemlich neu im Fischen bin, aber es ist vielleicht wichtig, dass ich bereits zweimal auf # 159 gestoßen bin und – wie von mindestens einem zusätzlichen Benutzer in dieser Ausgabe bemerkt – ich das komplett vergessen hatte Problem und seine Problemumgehungen, als ich das zweite Mal darauf gestoßen bin.

Zusätzlich:

Und nur oberflächlich "fish3" zu nennen, macht es den Leuten leichter, beide Versionen zu installieren. Betrachten Sie die Situation zum Beispiel mit Python.

Nicht nur das, die Benennung von fish3 könnte (meiner bescheidenen Meinung nach zu Unrecht) die Benutzer dazu bringen, von Fisch 2 weiterzumachen.

Mein 1/2 Cent: Ich stimme Braham-Snyder zu. Isolieren Sie Benutzer nicht, indem Sie den Namen ändern. Zum Rest wurde es oben schon gesagt.

Langjähriger Fischbenutzer, erstmaliges Poster. Freaking liebe diese Muschel!

Habe nichts gegen Vorwärtsfortschritt und brechende / nicht kompatible Änderungen.

Fish 3.0 klingt für mich gut, aber ich empfehle dringend, dass der binäre Name gleich bleibt. Der vollständige Pfad zu einer Shell-Binärdatei wird an vielen Stellen angezeigt, die Sie vielleicht nicht erwarten (chsh, /etc/passwd, Benutzerskripte, crontab usw.). Für eine Shell würde ich es vorziehen, den Binärnamen beizubehalten, selbst wenn die Änderungen nicht funktionieren. Auch die anderen Dinge, die die Leute über die Zukunft erwähnen (fish4?), lassen mich zweifeln.

Ich persönlich denke, Python hat sich viel Ärger gemacht, als sie sich entschieden haben, mit zwei Binärdateien (zB Python3) fortzufahren, und das ist wahrscheinlich vieles, was die breite Öffentlichkeit daran hindert, weiterzumachen (und auch die Python-Programmierer zu belasten, da sie müssen nun weiterhin zwei völlig separate Codezüge unterstützen und entwickeln). Nur meine 2 Cent.

Was ich mir in einem Major Release wünschen würde, ist mehr Sicherheit (Ref #805). Das ist der Grund, warum ich bash für die Skripterstellung verwende .

Von den tief hängenden Früchten verstehe ich nicht, warum wir nicht standardmäßig das Äquivalent von set -u von bash haben:

> set hippopotamus
> ls $typopotamus
fish: $typopotamus is not defined.
ls $typopotamus
   ^

Vergleichen Sie das mit failglob, das wir bereits haben:

> ls *nonexist
fish: No matches for wildcard '*nonexist'. See `help expand`.
ls *nonexist
   ^

Ich weiß nicht, ob ich der einzige Fish-Benutzer bin, der Fish nicht zum Skripting verwendet, aber wir überschätzen möglicherweise die Bedeutung der Abwärtskompatibilität: Im Gegensatz zu den meisten Programmiersprachen ist Fish eine Benutzeroberfläche, die zufällig eine Programmiersprache ist . Vergleichen Sie das mit Python: Python ist eine Programmiersprache, die zufällig eine REPL-Schnittstelle hat. Es war also wichtiger für Python.

Python3 war insofern ein Fehler, als einige Leute immer noch an Python2 festhielten. Ich denke, die Lehre daraus muss sein, dass selbst eine Hauptversion nicht zu abwärtskompatibel sein darf.

Ich stimme @anordal zu, dass Fish 3.0 das Dereferenzieren einer nicht

Es ist ziemlich klar, dass es eine starke Unterstützung für eine Version von Fish 3.0 gibt. Und wir haben eine solide Liste von Dingen, von denen wir wissen, dass wir sie tun wollen, und einige weitere, die wir, wenn es die Zeit erlaubt, aufnehmen könnten. Was sind die nächsten Schritte?

Wollen wir in zwei Monaten eine 2.7-Version veröffentlichen? Ich denke, die Antwort ist ja, da es uns einen weiteren veröffentlichten Meilenstein für die Behebung von Fehlern in der 2.x-Serie gibt, bevor wir aufhören, 2.x-Releases zu machen, außer für einen kritischen / Sicherheitsfehler. Auf der anderen Seite weiß ich, dass @zanchey aufhören möchte, für das Release-Management verantwortlich zu sein. Es könnte besser sein, ihn darauf zu konzentrieren, den Prozess stärker zu automatisieren und die manuellen Schritte besser zu dokumentieren, damit jemand anderes die Verantwortung für die Veröffentlichung eines Releases übernehmen kann. In diesem Fall wird 2.6 unser letztes Minor-Release in der 2.x-Reihe.

Was wollen wir mit den nächtlichen Builds machen? Am einfachsten ist es für uns, einen Integration_2.7.0 Zweig zu erstellen, den wir vor der Veröffentlichung explizit hinzufügen (oder einen Integration_2.6.1 Zweig). Der Zweig master steht uns dann frei, um nicht abwärtskompatible Änderungen vorzunehmen. Das Problem dabei ist, dass jeder, der zum Beispiel vom nächtlichen Ubuntu PPA aktualisiert, ziemlich überrascht sein könnte. Es könnte besser sein, wenn wir den nächtlichen Build auf den Integration_2.7.0 Zweig umstellen. Zumindest bis wir innerhalb eines Monats vor dem Veröffentlichungsdatum von Fish 3.0 sind, zu dem wir offiziell in den Betatest von 3.0 eintreten und den Nightly Build auf den master Zweig umstellen, damit unsere nicht abwärtskompatiblen Änderungen mehr Aufmerksamkeit erfahren . Alternativ erstellen wir einen Integration_3.0.0 Zweig, von dem aus die Core-Entwickler arbeiten und master bleibt 2.x, bis 3.0 veröffentlicht wird. Das Risiko hier besteht darin, dass das Ausführen von git checkout master dann das Zusammenführen anderer Zweige so ziemlich eine Reflexaktion ist (zumindest für mich). Das bedeutet, dass wir wahrscheinlich Änderungen sehen werden, die in den defacto 2.x-Zweig einfließen, die wir nicht enthalten möchten.

Unabhängig von der Antwort auf die oben genannten und andere Fragen, an die ich nicht gedacht habe, sollten wir wahrscheinlich einen Beitrag leisten und erklären, dass ab heute nur noch Bugs und neue Vervollständigungsskripte in den 2.7-Zweig aufgenommen werden (wie wir es auch schaffen es). Dies wird es uns ermöglichen, unsere Bemühungen auf die "großen" Änderungen zu konzentrieren, die wir für die 3.0-Version wünschen.

Wenn $() unterstützt werden soll, könnte das gleiche für && und || ?

Wenn $() unterstützt werden soll, könnte das gleiche für && und || gemacht werden?

Wahrscheinlich nicht. Nicht zuletzt deshalb, weil letzteres ausgiebig diskutiert wurde und die Core-Entwickler nicht davon überzeugt sind, dass in Fisch Syntax benötigt wird. Fisch hat bereits einen gleichwertigen Mechanismus. Bitte verwandeln Sie dieses Thema nicht in eine Diskussion über && und || . Lesen Sie Ausgabe 150. Und wenn Sie immer noch der Meinung sind, dass Sie ein überzeugendes Argument dafür vorbringen können, es zu fish 3.0 hinzuzufügen, eröffnen Sie mit Ihrem Argument ein neues Thema.

(Dies wurde letzte Woche geschrieben, aber nicht gepostet; ich werde versuchen, einige der Nachverfolgungen anzusprechen, da ich zu gegebener Zeit geschrieben habe.)

Im Oktober 2013 hatten die Fisch-Committer einen Thread, in dem wir uns mit der Versionierung befassen, der leider nicht öffentlich ist, aber in dem wir uns geeinigt haben:

(@zanchey)
Ich war davon ausgegangen, dass wir die Versionierung entlang der
Zeilen von Python und der Semantic Versioning-Spezifikation; dh diese Skripte
Fisch 2.N anzuvisieren funktioniert immer in Fisch 2.N+x, und dieser Fisch 3.0
bricht diese Abwärtskompatibilitätsgarantie.

Irgendwelche direkten negativen Aspekte zu dieser Idee? Ein Problem, auf das wir stoßen könnten, ist, dass wir
fish 2.10 und wollte die Hauptrevision nur zur Vereinfachung anheben.
Dafür gibt es keinen wirklichen Grund, aber das haben wir nirgendwo aufgeschrieben
das ist die Absicht.

(@lächerlichfisch)
Ja, das ist der Versionierungsstil, den ich im Sinn hatte, mit dem Vorbehalt, dass kleinere Überarbeitungen möglich sind
grundlegende Änderungen enthalten, wenn wir sicher sind, dass die meisten Skripte davon nicht betroffen sind. Ein Beispiel ist
die Änderung der Dateiumleitungen in fish 2.1 - das kann jemanden kaputt machen, wird es aber wahrscheinlich nicht.

Sicherlich wird fish 3.0 die geeignete Version für abwärts-inkompatible Änderungen sein.

Es ist bemerkenswert, dass dies der erste große bewusste Abwärtskompatibilitätsbruch in meinen fünf Jahren mit fish sein wird - fish 2.0 ließ alle Skripte weitgehend unverändert laufen. Es gibt ein Argument, dass sich die Sprache in den 12 Jahren seit der Freilassung der Fische eigentlich hätte stabilisieren sollen; Sicherlich ist eine abwärtsinkompatible Syntax für Shells ungewöhnlich und eine benutzerfeindliche Änderung. Wenn wir eine bewusste Entscheidung treffen, müssen wir das Versagen von Voraussicht (in der Vergangenheit) und Vorstellungskraft (gegenwärtig) anerkennen.

Wenn wir weitermachen, frage ich mich, ob wir etwas tun können, um den Schmerz zu lindern.

Einige Optionen:

• separate Binärdateien bereitstellen (dh fish2, fish3) oder zumindest an der Infrastruktur arbeiten, um die gleichzeitige Installation mehrerer Versionen zu ermöglichen, vermutlich durch Hinzufügen eines Flags zum configure-Skript. Vielen Dank für die oben berücksichtigten Meinungen - ich stimme zu, dass dies nicht etwas ist, was wir standardmäßig tun möchten.
• Kompatibilitätsgrade, ala bash : Es ist möglicherweise ein enormer Arbeitsaufwand, um mehrere Parsing-Implementierungen am Laufen zu halten, und wie wir den effektiven Kompatibilitätsgrad von Skripten beschreiben, ist schwer richtig zu machen. Der interaktive Modus startet vermutlich im neuesten Kompatibilitätslevel - laufen Skripte im ältesten oder neuesten, bis etwas anderes erklärt wird? Gibt es ein Pragma oder einen status compatibility-level Unterbefehl, um die aktive Ebene zu ändern?

Ich mag beides nicht besonders, aber mir fällt nichts besseres ein.

Ich freue mich, weiterhin Release-Zweigs für 2.x und 3.x zu pflegen - tatsächlich wurde die Art und Weise, wie die Distributions-Repositories eingerichtet sind, explizit darauf ausgelegt, dies zu ermöglichen, und die neue Release-Infrastruktur, die sich langsam entwickelt, wird leicht zu erweitern sein zum Selben.

@zanchey , Soweit ich das $( ) . Und das wird abwärtskompatibel sein, solange wir weiterhin ( ) außerhalb von doppelten Anführungszeichen unterstützen. Vielleicht möchten wir es als veraltete Syntax markieren, die in fish 4.0 entfernt werden soll, aber es sollte definitiv noch in fish 3.0 gültig sein

Es gibt eine vorgeschlagene Änderung, die eine signifikante abwärtsinkompatible Verhaltensänderung darstellt: die Dereferenzierung einer undefinierten Variablen zu einem Fehler zu machen. Alle anderen Änderungen (z. B. gebundene Variablen) bergen einige Risiken, werden aber bei 99% der Benutzer wahrscheinlich keine Probleme verursachen. Was die Verhaltensänderung von undef var betrifft, die immer noch sehr zur Debatte steht. Es wird definitiv schmerzhaft sein und von einem erheblichen Prozentsatz der Benutzer bemerkt. Möglicherweise müssen wir etwas tun, wovor wir bisher gescheut haben: das Verhalten konfigurierbar zu machen. Mit der Standardeinstellung nur warnen und nur wenn interaktiv. Aber das sollte in #4163 besprochen werden.

@zanchey und andere: Sollten wir den master Zweig für 3.0-Arbeiten verwenden und einen Integration_2.7.0 Zweig erstellen, den wir selektiv hinzufügen, bis wir bereit sind, die 2.7.0-Version zu veröffentlichen? Oder sollten wir einen Integration_3.0.0 Zweig (oder gleichwertig) erstellen, in den wir nur 3.0-Änderungen zusammenführen? Letzteres bedeutet, dass das aktuelle Setup für "nächtliche" Builds weiterhin 2.x-Pakete ohne Änderung erstellt. Ersteres bedeutet, dass wir die Nightly-Build-Konfiguration ändern müssen, damit Benutzer, die die Nightly-Build-Pakete verwenden, nicht unerwartet einen Fisch 3.0 in Arbeit bekommen. Ich bevorzuge die erstere (3.0-Arbeit, die mit dem master Zweig zusammengeführt wurde), da es weniger wahrscheinlich ist, dass größere Release-Änderungen in die 2.x-Serie eindringen.

Es gibt eine vorgeschlagene Änderung, die eine signifikante abwärtsinkompatible Verhaltensänderung darstellt: die Dereferenzierung einer undefinierten Variablen zu einem Fehler zu machen.

Diese Änderung wurde nun abgelehnt, sodass wir jetzt eine Reihe von "etwas inkompatiblen" Änderungen haben. Was in Ordnung ist, um ehrlich zu sein.

Beachten Sie, dass ich noch kein einziges Beispiel für Bruch gehört habe, der aus #4149 resultiert, nach dem ich ausdrücklich gefragt habe. Es wäre also in Ordnung, das in 2.7.0 hinzuzufügen - wenn es in der Praxis nichts kaputt macht, ist es praktisch abwärtskompatibel.

@faho , ich würde es vorziehen, dass wir in Bezug auf die Version 2.7.0 konservativ sind, da es unsere letzte Version in der 2.x-Serie sein soll. Daher sollten selbst Änderungen, die Probleme verursachen könnten, aber unwahrscheinlich sind, auf die Version 3.0.0 verschoben werden. Wir sollten vorsichtig sein und nur Merge-Änderungen, von denen wir zu 100 % überzeugt sind, werden keine bestehenden 2.x-Benutzer zerstören. Ich glaube nicht, dass #4149 in diese Kategorie fällt.

Da niemand sonst eine Meinung geäußert hat, lassen Sie uns einen major Zweig erstellen und master für 2.7.0 als Ziel beibehalten. Das ist der sicherste Ansatz für jeden, der aus dem Quellcode baut, und bedeutet, dass wir nichts tun müssen, um unsere "nächtlichen" Build-Pakete, die viele Benutzer installieren, weiterhin basierend auf dem 2.x-Baum zu halten.

Ich möchte standardmäßig den strikten Modus - sofort fehlschlagen, wenn ein Befehl einen Nicht-Null-Status zurückgibt, der nicht verarbeitet wird.

@techtonik , Ihre Anfrage, ein ähnliches Verhalten wie bash/zsh set -e zu implementieren, wird bereits in Ausgabe Nr. 510 verfolgt. Wenn Sie möchten, dass es in fish 3.0 enthalten ist, sollten Sie dieses Problem kommentieren. Aber, FWIW, angesichts all der anderen Änderungen, die wir bereits vorläufig für fish 3.0 vorgenommen haben, ist es sehr unwahrscheinlich, dass sie umgesetzt werden.

Nicht unbedingt für die erste 3.0-Version, aber wenn wir von großartigen Breaking Changes sprechen, gab es eine Diskussion darüber, die Abscheulichkeit, die test durch eine native (einfache) Evaluierung in den Builtins zu ersetzen?

Kommt es nicht in Frage, if $status == 2 oder while (echo foo) != (echo bar) nativ zu unterstützen?

(Ich denke, letzteres sollte jetzt $(echo ...) ..)

@mqudsi , Das konnten wir nur in einer Hauptversion (also Fish 4.0) tun, da dies umfangreiche Änderungen am Parser erfordern würde. Aber wichtiger ist, dass es gegen das Fisch-Manifest verstößt, um die magische Syntax zu minimieren und so viel wie möglich in Bezug auf Befehle zu implementieren. Was schmackhafter wäre, wäre ein Befehl, der eine Alternative zu test jedoch ohne seine seltsamen Eigenarten. Beispiel: test versus test '' versus test 'x' .

Meh. IMO-Operatoren wie == sind kaum undurchschaubare Teile einer magischen Syntax, die einen grundlegenden Fischglauben verletzen. Fish 3.0 ist noch eine Weile entfernt; Wenn Sie versuchen möchten, es denke ich, dass die Leute es gerne überprüfen würden.

Ich bin sehr verblüfft über all die Daumen hoch für den vorherigen Kommentar von @floam . == als Gleichheitsoperator hat absolut nichts Magisches. Magisch und problematisch sind Konstrukte wie diese:

if abc == $var
   # do something
end

Wie würde fish feststellen, dass es das als if test "abc" == "$var" behandeln sollte, anstatt einen Befehl namens abc mit Argumenten == und was auch immer $var expandiert auszuführen? Die Art und Weise, wie Korn-Shell (ksh), bash, et. al. Behandeln Sie dies über die Syntax mit zwei Klammern:

if [[ abc == $var ]]; then

Beachten Sie, dass es sich nicht um einzelne Klammern handelt, die nur ein Alias ​​​​für test . Wir könnten sicherlich Unterstützung für die Syntax mit zwei Klammern einführen. Was wir selbst in einer Hauptversion nicht tun können, ist die Unterstützung für bloße Ausdrücke nach den Schlüsselwörtern if und while einzuführen, da dies die Natur der Sprache grundlegend ändert. Oder schlagen Sie vor, dass wir benötigen

if some-command + x
    # do something
end

umgeschrieben als

some-command + x
if $status == 0
    # do something
end

Der Vorschlag ist eigentlich tot im Wasser, weil Sie das Verhalten von > nicht ändern können, um der Größer-als-Vergleichsoperator anstelle des Umleitungsoperators zu werden.

... weil Sie das Verhalten von > nicht ändern können ...

Sie könnten sozusagen verlangen, dass es durch einen umgekehrten Schrägstrich maskiert wird. Aber das ist schlimmer als die aktuelle Situation. Auch hier ist die einzige Möglichkeit, so etwas wie die von der Korn-Shell (ksh) entwickelte Double-Bracket-Syntax zu implementieren.

Meine Vorliebe für C würde mich dazu bringen, ( condition ) gegenüber [[ condition ]] bevorzugen, aber die Geschichte von Fish mit ( .. ) für die Subshell-Ausführung macht dies zu einem No-Go.

Der Vorschlag ist eigentlich tot, weil Sie das Verhalten von > nicht ändern können, um der Größer-als-Vergleichsoperator anstelle des Umleitungsoperators zu werden.

Die ksh-Syntax mit doppelten Klammern macht Folgendes:

[[ 2 < 5 ]] && echo smaller

@faho richtig, ich bezog mich auf "nackte" Ausdrücke (was eigentlich nicht der Sinn meines ursprünglichen Vorschlags war. Ich bin nicht gegen Dekorateure, nur gegen die unnötig geheimnisvolle Syntax von test ). Ich würde mit der Syntax von ksh gut sein, tbh.

Da es bei fish 3 anscheinend der Name des Spiels ist, die Syntax von fish mit anderen Shells kompatibel zu machen, möchte ich vorschlagen, dass wir FOO=bar cmd endlich erlauben, eine Umgebungsvariable für cmd .

Wir unterstützen bereits export FOO=bar als Kompatibilitäts-Shim für set -x foo bar , so dass FOO=bar cmd keine große Reichweite hat und eine ständige Frage beantworten würde, die Neulinge im Fischbereich von so ziemlich allen haben andere Schale.

Ich möchte vorschlagen, dass wir endlich FOO=bar cmd zulassen...

Der Grund, warum wir dies nicht unterstützt haben, ist, dass es überflüssig ist, da es nur vermeidet, dem Job env voranzustellen. Und es wird den Parser stark verkomplizieren. Allerdings bin ich philosophisch nicht dagegen, aber jemand anderes muss die Arbeit machen, da ich den Sinn nicht sehe. Fahren Sie fort und öffnen Sie ein Problem mit dem Tag "RFC".

Auch "die Syntax von fish mit anderen Shells kompatibler zu machen ist der Name des Spiels für fish 3" ist kein explizites Ziel. Und abgesehen von der Unterstützung von $(...) kann ich mir keine Änderung vorstellen, die auf Inklusion abzielt, die dies tut.

Auch "die Syntax von fish mit anderen Shells kompatibler zu machen ist der Name des Spiels für fish 3" ist kein explizites Ziel. Und abgesehen von der Unterstützung von $(...) kann ich mir keine Änderung vorstellen, die darauf abzielt, dies zu tun.

Ja, ich übertreibe vielleicht. Ich denke, () vs $() ist einfach so groß, dass es sich für mich so anfühlte.

Das Problem liegt nicht in der einfachen Verwendung von env an sich, sondern wenn Sie mehrere Variablen setzen müssen und Sie am Ende verschachtelte env Befehle haben, die ein halbes Dutzend oder so tief sind.

(Außerdem vergesse ich dank des Muskelgedächtnisses _noch_, wann man foo bar oder foo=bar , aber das ist weder hier noch dort.)

Das Problem liegt nicht in der einfachen Verwendung von env an sich, sondern wenn Sie mehrere Variablen festlegen müssen und Sie am Ende verschachtelte env-Befehle haben, die ein halbes Dutzend oder so tief sind.

Hä? Jede env Implementierung, die ich jemals verwendet habe, unterstützt das Festlegen mehrerer Umgebungsvariablen. Das ist völlig legal: env FOO=bar BAZ=frob my_command .

Wir unterstützen bereits export FOO=bar als Kompatibilitäts-Shim für set -x foo bar, sodass FOO=bar cmd nicht sehr weitreichend ist und eine ständige Frage beantworten würde, die Fisch-Neulinge aus so ziemlich jeder anderen Shell haben.

Sollte es nicht set -gx foo bar ? wenn es zumindest mit bash kompatibel ist. In bash müssen Sie das Schlüsselwort local verwenden, wenn Sie die Variable mit lokalem Gültigkeitsbereich setzen möchten, dh local FOO=bar anstelle von export FOO=bar

Erlaube FOO=bar cmd, eine Umgebungsvariable für cmd zu setzen.

Frühere Diskussionen: #587, #438 und https://github.com/fish-shell/fish-shell/issues/564#issuecomment -13261782

Wilde Idee: Lassen Sie echo seine Argumente zeilenweise ausgeben (oder fügen Sie eine Option oder ein anderes eingebautes dazu hinzu), weil:

• Befehlsersetzungen durch Zeilenumbruch geteilt → so geben Sie einen Vektor zurück
• es ist trivial zu hemmen, indem man die Argumente verkettet (und alle Variablenerweiterungen zitiert)
• weniger umwerfend als printf '%s\n' mit mehreren Argumenten

Wir können das Standardverhalten von echo nicht ändern. Nicht einmal in einem Major-Release. Wenn wir das tun würden, würde viel zu viel Code kaputt gehen, @anordal. Und wir können kein Flag hinzufügen, um das alternative Verhalten zu erhalten, genau weil der Satz von Flags, die es erlaubt, nicht erweiterbar ist. Der Befehl echo sollte aufgrund seiner historischen Eigenheiten als veraltet markiert werden.

Ein kurzer Vorschlag: Wenn gültige Breaking Changes es nicht in fish 3.0 schaffen, aber in einer zukünftigen Version enthalten sein könnten, dokumentieren Sie sie bitte auf eine auffindbare Weise. Zum Beispiel eine Wiki-Seite nach der Version 3.0, ein Meilenstein "Breaking Changes", ein Issue-Tag "Breaking Change"...

ein Meilenstein für "Breaking Changes"

Das ist im Grunde der "Fisch-Major"-Meilenstein.

Okay, hier sind die letzten Blocker für die Veröffentlichung von 3.0:

• [x] #4394 (Entfernung von ^ ) muss entschieden werden

• [x] #4230 (Entfernen von % , Umbenennen von var) muss die Abwärtskompatibilität aussortiert haben

• [x] #4896 muss repariert werden (trivial) - oder irgendeine Form von Kompatibilität für ? falls Anweisungen wieder eingesetzt werden müssen

• [x] #4897 muss repariert werden - und ich weiß nicht genau wie

• [x] #4893 muss herausgefunden und möglicherweise behoben werden - und ich muss die Ursache finden

• [ ] #4778, vielleicht?

Außerdem _glaube_ ich, dass wir die $_ Kerfuffle gelöst haben? Haben wir andere Variablen umbenannt, die wir wieder hinzufügen könnten?

Und ich denke, @ridiculousfish wollte . (als anderen Namen für source ) wieder hinzufügen.

Das Beste, was wir für #4897 gefunden haben, ist mir immer noch nicht ganz sicher, daher würde ich es jetzt lieber nicht zu 3.0 hinzufügen.

4394 und #4230 wurden jetzt behandelt, so dass wir, soweit es mich betrifft, jetzt veröffentlichen können.

Wir haben immer noch einige Probleme im Meilenstein , wir müssen uns entscheiden, ob wir jedes beheben oder punten.

Wir haben immer noch einige Probleme im Meilenstein, wir müssen uns entscheiden, ob wir jedes beheben oder punten.

Die Liste durchgehen:

• 4965 ist ein bisschen ein Mondschuss - ich würde diesen Fehler gerne nicht noch einmal versenden, aber ich möchte auch, dass die Lösung gut funktioniert, und ich bin nicht zu 100% verkauft.

• 4230 wurde effektiv behoben, indem "%self" zu allem hinzugefügt wurde, was es braucht

• 4794 und #4825 handeln beide von cmake, während wir immer noch Autotools liefern. Außerdem handelt es sich bei beiden um unkritische Teile des cmake-Builds.

• 4478 braucht mehr Arbeit

• 4627 ist völlig unkritisch

• 4540 ist schade, aber auch nichts Neues

• 4255 hat zwei Teile, und der Teil, der in 3.0 sein sollte, ist.

• 4191 ist unkritisch und auch etwas, das eine Menge Arbeit erfordert.

• 154 braucht mehr Arbeit.

• 436 braucht mehr Arbeit.

• 4154 ist dieses Problem und wird automatisch durch die Freigabe von :smile_cat gelöst:

Das einzige verbleibende Problem ist also #4778.

Auch das . / source Ding. Um die ich mich jetzt kümmern werde.

Ist es möglich #4849 zusammenzuführen? Persönlich möchte ich diese Funktion in 3.0.

Es ist mir immer noch nicht klar, was wir gewinnen, wenn wir CMD_DURATION , FISH_VERSION usw. (#4414) fallen lassen (anstatt Kleinbuchstaben hinzuzufügen).

@faho Ich werde heute an #4778 arbeiten, DV.

@faho nicht genau am selben Tag, aber ich habe den Code für #4778 aktualisiert, um die Situation so gut wie möglich widerzuspiegeln.

Da das einzige verbleibende Problem in https://github.com/fish-shell/fish-shell/issues/4154#issuecomment-387762493 behoben ist, wie geht es uns damit? :)

Ich arbeite mich durch die riesige Anzahl von Commits, während ich die Versionshinweise vorbereite, aber ich möchte auch die oben erwähnten Variablen wiederherstellen und möglicherweise eine bessere Geschichte zum Entfernen der Prozesserweiterung.

Ich möchte auch die oben genannten Variablen wiederherstellen

Wenn es um $FISH_VERSION geht, sollten wir uns entweder dazu verpflichten (und $version endgültig verwerfen) oder wir sollten $version behalten. Der Vorteil von $version ist, dass es in allen Fischen, die jemals freigelassen wurden, enthalten war.

$FISH_VERSION ist der schönere Name, geht aber nur auf 2.0.0 zurück. Auf der anderen Seite... erwarten wir wirklich, dass die Leute Fisch < 2 verwenden? Es ist effektiv eine ganz andere Anwendung.

Also... Ich bevorzuge etwas $FISH_VERSION (weil der Name schöner ist), aber es interessiert mich sowieso nicht so sehr. Ich möchte nur, dass wir uns endlich auf eines festlegen.

Wenn es um $CMD_DURATION geht, glaube ich nicht, dass sich die Umbenennung gelohnt hat. Ich mag den Aufwand des Wechselns nicht, und ich hasse es, Early Adopters mehr Ärger aufzuerlegen, indem ich zurückwechsele (obwohl sie wahrscheinlich den $CMD_DURATION $cmd_duration Trick gemacht haben, den ich an einigen Stellen erklärt habe).

Beides zu behalten und das alte hier abzulehnen, ist jedoch die schlechteste Lösung - das bedeutet, dass Sie das neue ausprobieren und zurückgreifen müssen, anstatt nur den obigen Trick zu machen, und einige werden einfach beim alten bleiben, bis es zu spät ist.

eine bessere Geschichte für die Entfernung der Prozesserweiterung.

Einverstanden! Ich würde argumentieren, dass wir %self als Sonderfall beibehalten und das eingebaute jobs sollten, damit Sie dies verwenden können, um die erforderlichen PIDs und so weiter zu erhalten. Ich mag das %something DSL nicht wirklich.

Beides beizubehalten ist in beiden Fällen reibungsarm - es beeinträchtigt die Leistung der Shell nicht merklich oder macht die Shell (glaube ich) schwieriger zu erlernen.

Hi. Ich bin nur neugierig - haben wir einen neuen Zeitplan oder eine Schätzung, wann 3.0 veröffentlicht wird? Ich habe mit Spannung beobachtet, wie die mit dem 3.0-Meilenstein markierten Tickets geschlossen werden, aber auch neue Tickets werden dem Meilenstein hinzugefügt.

Keine Schätzung; Ich betrachte alle Probleme, die im 3.0-Meilenstein verbleiben, als Blocker und diese tendieren langsam nach unten. Dinge, die an dieser Stelle hinzugefügt werden, sind neu entdeckte Blocker (zB Zancheys Beobachtung, dass Tarballs außerhalb des Baumes nicht funktionieren).

Okay, nachdem ich gerade ein paar unwichtige Dinge aus der Checkliste herausgepickt habe (falls jemand sie umsetzt, nehmen wir sie natürlich trotzdem! Es ist einfach nicht nötig, dass sie 3.0 blockieren), der Zustand ist:

• [x] #5210 und #3805 würden durch Zusammenführen von #5219 behoben
• [x] #5251 ist einfach genug, ich würde nur gerne wissen, ob der Sonderfall wirklich die kluge Entscheidung ist
• [x] #5229 ist im Großen und Ganzen nicht _zu_ wichtig
• [x] #5267
• [x] #4154 ist dieser und würde durch die Veröffentlichung gelöst

Ich habe das Fälligkeitsdatum auf den 11.11 zurückgesetzt.

Ich habe #5267, #5251 und #5229 behoben.

Außerdem hat @ridiculousfish #5271 eröffnet, was eine Art Nachfolger von #5245 ist. Das nicht in 3.0 zu haben, wäre ein bisschen umständlich.

Die Release Notes brauchen noch ein bisschen Arbeit, zu der ich hoffentlich diese Woche komme.

Sind Sie dabei, 3.0 zu veröffentlichen? Ich glaube nicht, dass ich von bash wechseln muss, aber ich habe zur Abwechslung nach besseren Alternativen gesucht.

Ich habe Zsh und Fisch gefunden. Zsh wird häufiger veröffentlicht und ist stabiler. Fish befindet sich noch in der Beta-Testphase, funktioniert aber sofort nach dem Auspacken.

Fisch befindet sich noch in der Beta-Testphase,

Es ist nicht? Fish ist seit zwölf Jahren Software freigegeben.

Wir bereiten die nächste Veröffentlichung vor, das ist alles.

Ich habe die Frist auf 3.0 bis 11.11 gesetzt, also in etwas mehr als einer Woche. Wir wollen wahrscheinlich vorher eine Beta haben.

Außerdem werden Sie vielleicht feststellen, dass es große Unterschiede zwischen Fisch und Zsh gibt, sodass diese Kategorisierung nicht wirklich passt. Fish ist absichtlich nicht posix-kompatibel und versucht, angenehmer zu sein, ohne alles konfigurieren zu müssen. Zsh hingegen versucht, jedem alles zu bieten, sodass Sie alles konfigurieren können. Es hat eine erschreckende Anzahl von Knöpfen und Optionen, mit denen Sie herumspielen können, und eine Reihe von Erweiterungen für das Shellscripting im Posix-Stil, wie erweiterte Globs ( print *.c(#q:s/#%(#b)s(*).c/'S${match[1]}.C'/) ist legaler ZSH-Code, entnommen aus der zshexpn Manpage). .

Mangelnde POSIX-Kompatibilität kann ein Problem mit Terminalprogrammen sein.

Ich benutze vim, nvim, htop, ranger und so weiter.

@crocket : Nicht wirklich. vim benötigt "set shell=/bin/bash", wenn Sie Plugins verwenden, die $shell verwenden (und die Verwendung von $shell auf diese Weise ist keine Vorgehensweise, die ich empfehlen kann). Andere Dinge sollten einfach funktionieren, da sie in der Shell laufen, für die sie geschrieben wurden. Sie geben es einfach in der Shebang-Zeile an (zum Beispiel).

Ich weiß, dass htop funktioniert, da ich es selbst benutze, und ich habe noch nie von Problemen mit Ranger gehört.

Das einzige bedeutende Problem ist, wenn Sie Dinge verwenden, die source erfordern, wie nvm oder direnv.

Wie auch immer, Fisch 2.7.1 ist draußen, also können Sie es einfach ausprobieren.

Ich benutze (n)vim und htop den ganzen Tag sowohl in meinem Job als auch um Fische selbst zu entwickeln. Ich kann Ihnen versprechen, dass sie ohne Bash gut funktionieren (ja sogar mit allem anderen als den schäbigsten Plug-Ins).