Warum nicht beides miteinander verbinden. Wieso nicht mit ls ne Dateiliste ausgeben und dann per Maus welche per Drag und Drop irgendwo hinziehen? Ich kann mir da durchaus so Einiges vorstellen, was machbar wäre.
Von Josef Hahn am Sa, 7. September 2019 um 17:43 #
Oh, die Idee finde ich spannend. Wenn man da noch ein paar Feinheiten zuende denkt, und um noch ein paar weitere simple GUI-Konzepte erweitert - vielleicht auch mal ein Button, auf den mal klicken kann - könnte das ein interessanter Mittelweg sein. Das API sollte idealerweise simpel bleiben, sonst ginge ein wesentlicher Vorteil der Konsole ja verloren. Nicht ganz einfach. Kennst du denn ein Projekt, was mit sowas schonmal experimentiert hat?
Wie wäre es damit (ist der 2. Text - den ersten hatte vor einigen Stunden mein Firefox gefressen)
Bisher sind solche Befehle wie ls mit ASCII-Color-Informationen angereichert. Die kommen allerdings aus der ASCII-Tabelle.
Wie wäre es, wenn man stattdessen eine Ausgabe mit Metainformation geben würde?
Z.B. sendet der Befehl ls eine url (file://...) und eine Benennung (datei001) mit. Das übernimmt die Bibliothek. ls ist nach dem Funktionsaufruf auch völlig raus aus der Verwaltung (Speicher, ...). Nun gibt es einen "Verwalter" in Wayland und X oder einzeln, der diesen Dienst Frameworks wie Gnome oder KDE anbietet (GPM 2?). Wenn nun eine (Maus-)Aktion mit einem Zeichen ausgelöst wird (z.B. D&D), kann dazu die Metainformation abgefragt werden.
- Wichtig fände ich, dass es trotzdem noch einfach bleibt und in die GNU-Tools nicht ein riesiges Framework reinkommt. Denn im Gegensatz zu den GUIs sind echte Unix-Programme meist absichtlich klein und beschränkt. - muss man dabei über Sicherheit reden? Ein Programm kann ja schließlich ziemlich viel in die Metainfos reinschieben und evtl. auch etwas untergeschoben bekommen ... - Pipes haben evtl. einfach nicht diese Schnittstelle, dass die Metainfo einfach in Ablage P (Edit: /dev/null) fällt
Im Übrigen: Ich hab grad keine Zeit und nicht genug Knoff Hoff :o)
Interessant wäre es aber schon, bevor da wieder ein so großer Druck entsteht, dass jemand großes Monster erschafft und nichts einfaches erschafft. Es wäre gut, wenn die Kommandozeile auf einfache Weise stetig verbessert würde. Dazu gehören evtl. auch ein paar Experimente. Das oben ist ein Vorschlag. Die Idee finde ich auch gut.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 07. Sep 2019 um 18:09.
Ich würde das auch gar nicht unbedingt im großen Stil aufziehen. Also jetzt hat man ja bei einer Kommandozeile innerhalb seiner Desktopumgebung im Wesentlichen die Shell als solches (bash or whatever) und eine Terminalemulation, die sozusagen das Interface zur Shell herstellt.
Das ich machen würde ist sozusagen die Terminalemulation eben nicht nur ein Frontend sein zu lassen, sondern Ausgaben zusätzlich mit Semantik hinterlegen. Sprich wenn irgendwo ein Dateiname ausgegeben wird das halt nicht nur textuell der Name der Datei ist, sondern verknüpft damit die Information, das dieser Text eine Datei (Pfad oder was auch immer) repräsentiert.
Da mir die "Terminalemulation" (die ja keine reine Terminalemulation mehr ist) gehört, kann ich halt auch auf Drag-Ereignisse selbst reagieren. Zieh ich also nen angeklickten Dateinamen irgendwo hin, gebe ich dann einfach dem Desktop-System die Information so mit wie es wäre wenn man es aus nem Dateimanager Drag-gen würde.
So hätte man zunächst ein mal nur eine Applikation und auch keinen Bedarf irgendetwas anderes anpassen zu müssen. Das begrenzt sicherlich die Möglichkeiten, aber ich denke mal allein damit kommt man schon sehr weit. Und der Aufwand ist überschaubar. Zumal man ja nicht alles auf einmal umsetzen muss, sondern es Schritt für Schritt machen kann. Was noch nicht umgesetzt ist, deklarierst Du halt als Text und es verhält sich erst mal noch so wie bisher gewohnt.
Überschaubarer Aufwand mit raschen einstellen von ersten sichtbaren Erfolgen sind schon mal gute Vorzeichen, damit so ein Projekt ans rollen kommt.
Kennst du denn ein Projekt, was mit sowas schonmal experimentiert hat?
Nein. Aber mich beschäftigt die Thematik schon eine Weile. Auf meiner Suche bin ich bisher aber noch nicht wirklich auf was gestoßen ,weshalb ich mich mal selbst daran machen wollte, wenn sich Zeit & Muße ergibt.
Ich empfinde übrigens die bisherige Shell nicht als simpel. Man hat sich dran gewöhnt und beherrscht sie und empfindet es deshalb als simpel. Aber umso mehr man drüber nachdenkt, umso mehr Dinge fallen einem auf die man besser lösen kann.
Das ist auch nicht als Negativ-Kritik gemeint. Wenn man guckt, wie sich das alles entwickelt hat, dann erklärt sich daraus warum bestimmte dinge so sind wie sie sind.
Was mich nur wundert ist, das innerhalb der Linux-Community da niemand ist der mal mutiger an die Sache ran geht und ruhig auch mal mit Ungewöhnlichen experimentiert.
Die Shell wird ja immer als wichtiges Werkzeug hochgehalten. Und trotzdem finden dort die wenigsten Innovationen statt. Grotesk.
Die Shell wird ja immer als wichtiges Werkzeug hochgehalten. Und trotzdem finden dort die wenigsten Innovationen statt. Grotesk.
Das halte ich für eine einigermaßen gewagte Aussage. Zudem kommt es ja auch nicht auf die bloße Menge an Innovationen an, sondern darauf, ob sie wesentliche Verbesserungen darstellen.
Ich habe da mal ein paar Dinge zusammengesucht:
Bereits 1989 erschien eine von Tom Duff für Plan 9 entwickelte Shell namens rc (die zuerst allerdings einfach Plan 9 Shell hieß), die so Einiges an Innovationen zu bieten hatte. Zu den erklärten Zielen des Projekts gehörte es, eine „weniger idiosynkratische Syntax“ als die klassische Bourne-Shell zu verwenden. Eine von Duff verfasste Beschreibung von rc gibt's unter https://9p.io/sys/doc/rc.html.
Diese Shell wurde dann Anfang der 90er von Byron Rakitzis für Unix reimplementiert und später von anderen weiterentwickelt. Die aktuelle Version ist 1.7.4 und kann bspw. unter Debian einfach über die Paketverwaltung installiert werden. Den Quelltext gibt's unter https://github.com/rakitzis/rc. Soweit mir bekannt, hat rc aber einen wesentlich geringeren Funktionsumfang als die weit verbreiteten Bourne-ähnlichen Shells wie Bash, Z Shell oder KornShell.
Ein Folgeprojekt von Rakitzis' Unix-Port der Plan-9-Shell war schließlich die Entwicklung von Es, einer weiteren Shell, die von Rakitzis zusammen mit Paul Haahr geschrieben wurde. Ziel war dabei, durch eine grundlegend andere Konzeption der Shell-Sprache die Programmierbarkeit der Shell wesentlich zu verbessern. Orientiert wurde sich dabei an funktionalen Programmiersprachen, wie Scheme und ML, aber auch an Tcl. Den Standardtext zu Es gibt's unter: https://stuff.mit.edu/afs/sipb/user/yandros/doc/es-usenix-winter93.html.
Es wird schienbar auch noch mehr oder weniger weiter gepflegt. Auf Systemen aber, die musl libc verwenden, lässt sich der Quelltext aus dem verlinkten GitHub-Depot nicht übersetzen.
Eine ganz aktuelle Innovation, die mit all dem eher nichts zu tun zu haben scheint, ist im Übrigen Nu Shell. Da wurde auch kürzlich auf der Website des Linux-Magazins drüber berichtet.
Bereits 1989 erschien eine von Tom Duff für Plan 9 entwickelte Shell namens rc
Ist mir bekannt. Ich bezog mich aber auf Linux.
Den Quelltext gibt's unter https://github.com/rakitzis/rc. Soweit mir bekannt, hat rc aber einen wesentlich geringeren Funktionsumfang als die weit verbreiteten Bourne-ähnlichen Shells wie Bash, Z Shell oder KornShell.
Kein Wunder. rc ist ist ja auch schon etwas älter. Abgesehen davon das Plan-9-Tools ohne Plan-9 System nur begrenzt Sinn machen.
Ein Folgeprojekt von Rakitzis' Unix-Port der Plan-9-Shell war schließlich die Entwicklung von Es
Das kannte ich noch nicht.
Konzeption der Shell-Sprache die Programmierbarkeit der Shell wesentlich zu verbessern. Orientiert wurde sich dabei an funktionalen Programmiersprachen, wie Scheme und ML
Was sehr interessant klingt und mir auch eher gefallen würde. Mit der Syntax rund um Bash und Co konnte ich mich nie so richtig anfreunden. Daher schreib ich damit auch eher selten Skripte.
Eine ganz aktuelle Innovation, die mit all dem eher nichts zu tun zu haben scheint, ist im Übrigen Nu Shell.
Klingt ein wenig nach Powershell. Und das sind so Sachen die ich unbedingt drin haben will. Es ist echt nervig wenn irgendwelche Werte nur textuell sind und man die erst umständlich rausfischen und ggf. parsen muss um sie weiter zu verarbeiten.
Auch die Berücksichtigung des Inhalts von Dateien (sprich: den Dateityp) schwirrt auch schon länger in meinen Gedanken zu der Thematik herum.
Gut. Zugegeben. Es gibt ein paar nette Sachen.
Nichtsdestotrotz führt das Thema doch ein Nischendasein.
Wenn Du Linuxer fragst kommt i.d.R. Bash als Antwort. Manchmal auch so was wie zsh. Und mich wundert, das da nicht mehr Diversität drin ist. Bei den Desktops mit KDE,GNOME,XFCE und wie sie alle heißen ists doch auch so.
Nichtsdestotrotz führt das Thema doch ein Nischendasein.
Das stimmt schon. Ich habe diese paar Sachen ja sozusagen aus 30 Jahren Unix- und Linux-Geschichte zusammengekratzt, wobei ich allerdings z. B. fish gar nicht erwähnt habe.
Wenn Du Linuxer fragst kommt i.d.R. Bash als Antwort. Manchmal auch so was wie zsh. Und mich wundert, das da nicht mehr Diversität drin ist. Bei den Desktops mit KDE,GNOME,XFCE und wie sie alle heißen ists doch auch so.
Mir fallen da verschiedene mögliche Gründe ein.
Zum einen ist es so, dass POSIX eine erweiterte Bourne-Shell als Standard für alle Unix-Systeme spezifiziert und zumindest unter Linux und OpenBSD standardmäßig erweiterte – und in ihrem Erweiterungen weitgehend kompatible – POSIX-Shells zum Einsatz kommen. Solaris wird das schätzungsweise auch so machen. (FreeBSD fällt hier aus der Reihe, aber auch dort ist zumindest die Standard-Shell für normale Nutzer eine erweiterte POSIX-Shell, wenn auch deren Erweiterungen nicht so weit reichen wie bei Bash, KornShell oder Z Shell.)
Das heißt, es gibt neben dem explizit definierten Standard für die Kommandozeilensprache unter Unix auch noch eine Art De-facto-Standard an Erweiterungen. Und das ist, bei aller berechtigten Kritik an der idiosynkratischen Syntax und der Mangelhaftigkeit der Shell-Sprache, eine ziemlich komfortable Situation, denn die Unix-Kommandozeile kommt damit faktisch einer universellen Benutzerschnittstelle relativ nah.
Hinzu kommt, dass, im Gegensatz zu grafischen Desktop-Umgebungen, der Kommandozeileninterpreter offenbar viel eher in Aufgabenbereichen eingesetzt wird, in denen es wirklich drauf ankommt, dass Dinge stabil laufen. Die Shell ist schlicht das klassische Werkzeug von (professionellen) Systemadministratoren, deren Arbeitsbereich sich üblicherweise eher schlecht für Experimente eignen dürfte.
Und sind Skripte einmal in Bash oder KornShell geschrieben und wurden womöglich über Jahre hinweg vorsichtig verbessert, wird da sicherlich (und verständlicherweise) wenig Bereitschaft bestehen, daran grundlegend etwas zu ändern.
Das führt gleich zum nächsten Punkt: Bei Betriebssystemshells spielt Rückwärtskompatibilität eine große Rolle.
Desktopumgebungen unter Linux nimmt, wie mir scheint, ohnehin niemand wirklich ernst, was ich gut nachvollziehen kann. Daher ähnelt dieser Bereich, wohl oder übel, auch eher einer Spielwiese für Entwickler.
Mir wäre mehr Diversität bei Unix-Shells auch eher ein Graus. Gut wäre stattdessen, wenn einfach eine Shell wie Es den Status einer gängigen Alternative zu den Bourne-ähnlichen Shells erlangen würde.
Ja. Fish kenne ich auch. Finde ich eigentlich auch gar nicht so schlecht. Bietet nette Funktionen und ist auch vom Start weg sehr gut benutzbar ohne das man irgendwas konfigurieren muss. Man hat sozusagen schon was davon, indem man sie einfach nur installiert. Mir geht sie aber in manchen Dingen einfach nicht weit genug und macht Dinge anders als ich sie mir wünschen würde. Dennoch ist es eine sehr empfehlenswerte Shell für Leute die da mal was anderes abseits von Bash probieren wollen.
Das heißt, es gibt neben dem explizit definierten Standard für die Kommandozeilensprache unter Unix auch noch eine Art De-facto-Standard an Erweiterungen. Und das ist, bei aller berechtigten Kritik an der idiosynkratischen Syntax und der Mangelhaftigkeit der Shell-Sprache, eine ziemlich komfortable Situation, denn die Unix-Kommandozeile kommt damit faktisch einer universellen Benutzerschnittstelle relativ nah.
Ich sag ja auch nicht, das andere Shells dafür verschwinden sollen. Aber als Ergänzung? warum nicht?
Kann man ja so ein bisschen vielleichen mit dem vi. Den gibts auch "überall". Wenn Du also irgendwie unter nem "UNIX" ne Datei editieren willst, kannst Du sicher sein nen vi zu haben. Es ist praktisch, wenn man den zumindest halbwegs beherrscht. Trotzdem würde ich nicht auf die Idee kommen ihn deshalb ständig einzusetzen.
Warum sollte ich das bei einer Shell nicht machen? Ich muss ja nicht mal meine Standardshell ändern. Ich kann ja meine Lieblingsshell jederzeit aufrufen, wenn ich meine ich möchte sie in dem Augenblick nutzen.
Hinzu kommt, dass, im Gegensatz zu grafischen Desktop-Umgebungen, der Kommandozeileninterpreter offenbar viel eher in Aufgabenbereichen eingesetzt wird, in denen es wirklich drauf ankommt, dass Dinge stabil laufen. Die Shell ist schlicht das klassische Werkzeug von (professionellen) Systemadministratoren, deren Arbeitsbereich sich üblicherweise eher schlecht für Experimente eignen dürfte.
Genau dann ist aber die Shell eher wacklig. Gerade wenn Du Scripting-Sachen machst. Es gibt einfach so viele Stolperfallen. Klar kann man die umgehen. Aber besser ist natürlich, wenn es die gar nicht erst gibt.
Und sind Skripte einmal in Bash oder KornShell geschrieben und wurden womöglich über Jahre hinweg vorsichtig verbessert, wird da sicherlich (und verständlicherweise) wenig Bereitschaft bestehen, daran grundlegend etwas zu ändern.
Hat ja auch niemand behauptet, das bestehende Skripte alle neu geschrieben werden sollen.
Aber wo wir gerade beim Scripting sind: Ne Shell erfüllt ja i.d.R. heutzutage zwei Aufgaben. Erstens das schon angesprochene Scripting, zweitens eine interaktive Benutzerstelle. Mal abgesehen davon, das es gegen "one Job one tool" verstößt ist es auch so, das es beides nicht optimal erfüllt und vielleicht auch nicht erfüllen kann. Nicht umsonst gibt es ja immer mal wieder Bestrebungen den Scripting-Teil mit was anderem zu machen. Perl ist ja da das klassische Beispiel für. Die reellen Geschehnisse zeigen also schon, das es da eine gewisse Spannung in der Thematik gibt.
Fürs Bereich Skripting hat sich da ne Menge getan. Sei es nun Perl, Python, Ruby oder was auch immer, da gibt es reichlich Optionen die den Teil angehen und Alternativen bieten. POSIX-Shell-Scripte oder von mir aus auch noch Bash-Skripte haben natürlich weiterhin den Charme, das sie überall ohne großarige Voraussetzungen laufen. Aber damit hat es sich auch schon an Vorteilen. Auf der Seite der Interaktion mit dem Nutzer hast Du das meines Erachtens nach weniger Bewegung drin. Es gibt sie, aber die sind eben (wie schon gesagt) nicht so präsent.
Wie gesagt. Es schätze es auch, wenn es einen Minimalstandard gibt der überall funktioniert. Für den täglichen Gebrauch wäre mir das aber dann doch zu rudimentär und unkomfortabel.
Ich für meinen Teil arbeite gerne mit dem Programm "Konsole" in der GUI. Dort per Tastatur aufgerufen 'mc' (Aufruf könnte man auch komplett mit dem Desktop verbinden) lässt sich einiges per Maus machen. Nur nicht Drag&Drop. Beim Mac (zertifiziertes UNIX mit Bash) geht was.
Unter Linux kenne ich nur Terminalprogramme, die damit zurechtkommen, mit Klick auf "Knöpfe" und Doppelklick auf andere Elemente inn mc. Ich benutze beides, Tastatur und Maus.
Man könnte sich aber weitergehendes selber machen. Nur nicht Drag&Drop, sondern über Kontext-Menü.
Ja. Dummerweise nützt Dir so was heutzutage wenig. Linux ist inzwischen so dominant, das man vermehrt auf Programme trifft, die nur unter Linux (vernünftig) laufen. Grad bei KDE5 hat man das schön beobachten können. Wenn man mal überlegt, das KDE sogar mal unter Windows anständig lief, dann sind solche Entwicklungen eher unerfreulich.
Zumal ja Viele aus der Linux-Community früher immer Microsoft vorgehalten haben das die eigene Standards durchdrücken und zu nichts kompatibel sind. Und jetzt macht mans nicht besser.
Man könnte sich aber weitergehendes selber machen. Nur nicht Drag&Drop, sondern über Kontext-Menü.
Ja. Wobei ich ungern Sachen machen würde, die nur auf einem Desktop funktionieren. Wenn dann würde ich wohl eher auf freedesktop.org-Standards zurückgreifen auch wenn ich dafür eingeschränkte Möglichkeiten in Kauf nehmen muss.
Es fehl also jemand, der Yoink äh .
Das kannte ich bisher noch gar nicht. Zeigt aber Ansätze wie ich sie mir auch vorstelle. Als Demo wie so was aussehen könnte ist die Seite jedenfalls prima
Es fehl also jemand, der Yoink äh ... ja nein Yoink für die Linux-Welt nachprogrammiert
Naja. Warum nur für Linux? Wenn, dann gleich plattformunabhängig.
Von Josef Hahn am So, 8. September 2019 um 17:24 #
Es ist ja sowieso immer wieder zu beobachten, dass MS eigentlich lieber ein abgeschlossenes Windows ala iOS/Android hätte, in dem ohne Tricksereien nur über den Store irgendwas installieren kann, und die Software dann auch nicht einfach per win32 api loslegt, sondern nur über "moderne" Schnittstellen, die überall verkappt sind. Wo solche Systeme die Normalität werden, ist auch Plattformunabhängigkeit nicht einfach. Schreib mal einen Webbrowser für iOS...
Das wid für Drag&Drop nicht gehen, weil die zugrunde liegenden Architekturen das nicht zulassen werden. Aber schön wär's.
Allein Yoink! ist doch eine fürchterliche Krücke. Aber interessant, dass das mit einer entsprechenden bash-Konfiguration möglich ist. Also müsste man das auch für Linux hinbekommen. Ich persönlich werde mich in nächster Zeit mal um die KDE-Konfiguration von Kontext-Menüs hermachen und meine eigenen Skripte durchgehen, was ich dahin übertragen kann.
Das wid für Drag&Drop nicht gehen, weil die zugrunde liegenden Architekturen das nicht zulassen werden. Aber schön wär's.
Wenn es plattformspezifischen Code im überschaubaren Rahmen braucht, kann ich damit auch noch leben. Was ich halt nicht will ist so was wie: Läuft nur auf Linux Läuft nur auf KDE Läuft nur bei Vollmond :-)
Ich persönlich werde mich in nächster Zeit mal um die KDE-Konfiguration von Kontext-Menüs hermachen und meine eigenen Skripte durchgehen, was ich dahin übertragen kann.
Ja. Klingt alles ja auch ganz interessant und relativ einfach umzusetzen. Von der her ist es schon eine Sache, die man "einfach mal machen kann".
Warum nicht beides miteinander verbinden. Wieso nicht mit ls ne Dateiliste ausgeben und dann per Maus welche per Drag und Drop irgendwo hinziehen?
Ich kann mir da durchaus so Einiges vorstellen, was machbar wäre.
Oh, die Idee finde ich spannend. Wenn man da noch ein paar Feinheiten zuende denkt, und um noch ein paar weitere simple GUI-Konzepte erweitert - vielleicht auch mal ein Button, auf den mal klicken kann - könnte das ein interessanter Mittelweg sein. Das API sollte idealerweise simpel bleiben, sonst ginge ein wesentlicher Vorteil der Konsole ja verloren. Nicht ganz einfach. Kennst du denn ein Projekt, was mit sowas schonmal experimentiert hat?
Wie wäre es damit (ist der 2. Text - den ersten hatte vor einigen Stunden mein Firefox gefressen)
Bisher sind solche Befehle wie ls mit ASCII-Color-Informationen angereichert. Die kommen allerdings aus der ASCII-Tabelle.
Wie wäre es, wenn man stattdessen eine Ausgabe mit Metainformation geben würde?
Z.B. sendet der Befehl ls eine url (file://...) und eine Benennung (datei001) mit. Das übernimmt die Bibliothek. ls ist nach dem Funktionsaufruf auch völlig raus aus der Verwaltung (Speicher, ...). Nun gibt es einen "Verwalter" in Wayland und X oder einzeln, der diesen Dienst Frameworks wie Gnome oder KDE anbietet (GPM 2?). Wenn nun eine (Maus-)Aktion mit einem Zeichen ausgelöst wird (z.B. D&D), kann dazu die Metainformation abgefragt werden.
- Wichtig fände ich, dass es trotzdem noch einfach bleibt und in die GNU-Tools nicht ein riesiges Framework reinkommt. Denn im Gegensatz zu den GUIs sind echte Unix-Programme meist absichtlich klein und beschränkt.
- muss man dabei über Sicherheit reden? Ein Programm kann ja schließlich ziemlich viel in die Metainfos reinschieben und evtl. auch etwas untergeschoben bekommen ...
- Pipes haben evtl. einfach nicht diese Schnittstelle, dass die Metainfo einfach in Ablage P (Edit: /dev/null) fällt
Im Übrigen: Ich hab grad keine Zeit und nicht genug Knoff Hoff :o)
Interessant wäre es aber schon, bevor da wieder ein so großer Druck entsteht, dass jemand großes Monster erschafft und nichts einfaches erschafft. Es wäre gut, wenn die Kommandozeile auf einfache Weise stetig verbessert würde. Dazu gehören evtl. auch ein paar Experimente. Das oben ist ein Vorschlag. Die Idee finde ich auch gut.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 07. Sep 2019 um 18:09.Ich würde das auch gar nicht unbedingt im großen Stil aufziehen.
Also jetzt hat man ja bei einer Kommandozeile innerhalb seiner Desktopumgebung im Wesentlichen die Shell als solches (bash or whatever) und eine Terminalemulation, die sozusagen das Interface zur Shell herstellt.
Das ich machen würde ist sozusagen die Terminalemulation eben nicht nur ein Frontend sein zu lassen, sondern Ausgaben zusätzlich mit Semantik hinterlegen. Sprich wenn irgendwo ein Dateiname ausgegeben wird das halt nicht nur textuell der Name der Datei ist, sondern verknüpft damit die Information, das dieser Text eine Datei (Pfad oder was auch immer) repräsentiert.
Da mir die "Terminalemulation" (die ja keine reine Terminalemulation mehr ist) gehört, kann ich halt auch auf Drag-Ereignisse selbst reagieren. Zieh ich also nen angeklickten Dateinamen irgendwo hin, gebe ich dann einfach dem Desktop-System die Information so mit wie es wäre wenn man es aus nem Dateimanager Drag-gen würde.
So hätte man zunächst ein mal nur eine Applikation und auch keinen Bedarf irgendetwas anderes anpassen zu müssen.
Das begrenzt sicherlich die Möglichkeiten, aber ich denke mal allein damit kommt man schon sehr weit.
Und der Aufwand ist überschaubar. Zumal man ja nicht alles auf einmal umsetzen muss, sondern es Schritt für Schritt machen kann. Was noch nicht umgesetzt ist, deklarierst Du halt als Text und es verhält sich erst mal noch so wie bisher gewohnt.
Überschaubarer Aufwand mit raschen einstellen von ersten sichtbaren Erfolgen sind schon mal gute Vorzeichen, damit so ein Projekt ans rollen kommt.
Ich empfinde übrigens die bisherige Shell nicht als simpel. Man hat sich dran gewöhnt und beherrscht sie und empfindet es deshalb als simpel. Aber umso mehr man drüber nachdenkt, umso mehr Dinge fallen einem auf die man besser lösen kann.
Das ist auch nicht als Negativ-Kritik gemeint. Wenn man guckt, wie sich das alles entwickelt hat, dann erklärt sich daraus warum bestimmte dinge so sind wie sie sind.
Was mich nur wundert ist, das innerhalb der Linux-Community da niemand ist der mal mutiger an die Sache ran geht und ruhig auch mal mit Ungewöhnlichen experimentiert.
Die Shell wird ja immer als wichtiges Werkzeug hochgehalten. Und trotzdem finden dort die wenigsten Innovationen statt. Grotesk.
Das halte ich für eine einigermaßen gewagte Aussage. Zudem kommt es ja auch nicht auf die bloße Menge an Innovationen an, sondern darauf, ob sie wesentliche Verbesserungen darstellen.
Ich habe da mal ein paar Dinge zusammengesucht:
Bereits 1989 erschien eine von Tom Duff für Plan 9 entwickelte Shell namens
rc(die zuerst allerdings einfach Plan 9 Shell hieß), die so Einiges an Innovationen zu bieten hatte. Zu den erklärten Zielen des Projekts gehörte es, eine „weniger idiosynkratische Syntax“ als die klassische Bourne-Shell zu verwenden. Eine von Duff verfasste Beschreibung vonrcgibt's unter https://9p.io/sys/doc/rc.html.Diese Shell wurde dann Anfang der 90er von Byron Rakitzis für Unix reimplementiert und später von anderen weiterentwickelt. Die aktuelle Version ist 1.7.4 und kann bspw. unter Debian einfach über die Paketverwaltung installiert werden. Den Quelltext gibt's unter https://github.com/rakitzis/rc. Soweit mir bekannt, hat
rcaber einen wesentlich geringeren Funktionsumfang als die weit verbreiteten Bourne-ähnlichen Shells wie Bash, Z Shell oder KornShell.Ein Folgeprojekt von Rakitzis' Unix-Port der Plan-9-Shell war schließlich die Entwicklung von Es, einer weiteren Shell, die von Rakitzis zusammen mit Paul Haahr geschrieben wurde. Ziel war dabei, durch eine grundlegend andere Konzeption der Shell-Sprache die Programmierbarkeit der Shell wesentlich zu verbessern. Orientiert wurde sich dabei an funktionalen Programmiersprachen, wie Scheme und ML, aber auch an Tcl. Den Standardtext zu Es gibt's unter: https://stuff.mit.edu/afs/sipb/user/yandros/doc/es-usenix-winter93.html.
Es wird schienbar auch noch mehr oder weniger weiter gepflegt. Auf Systemen aber, die musl libc verwenden, lässt sich der Quelltext aus dem verlinkten GitHub-Depot nicht übersetzen.
Eine ganz aktuelle Innovation, die mit all dem eher nichts zu tun zu haben scheint, ist im Übrigen Nu Shell. Da wurde auch kürzlich auf der Website des Linux-Magazins drüber berichtet.
Und das sind so Sachen die ich unbedingt drin haben will. Es ist echt nervig wenn irgendwelche Werte nur textuell sind und man die erst umständlich rausfischen und ggf. parsen muss um sie weiter zu verarbeiten.
Auch die Berücksichtigung des Inhalts von Dateien (sprich: den Dateityp) schwirrt auch schon länger in meinen Gedanken zu der Thematik herum.
Gut. Zugegeben. Es gibt ein paar nette Sachen.
Nichtsdestotrotz führt das Thema doch ein Nischendasein.
Wenn Du Linuxer fragst kommt i.d.R. Bash als Antwort. Manchmal auch so was wie zsh.
Und mich wundert, das da nicht mehr Diversität drin ist. Bei den Desktops mit KDE,GNOME,XFCE und wie sie alle heißen ists doch auch so.
Das stimmt schon. Ich habe diese paar Sachen ja sozusagen aus 30 Jahren Unix- und Linux-Geschichte zusammengekratzt, wobei ich allerdings z. B. fish gar nicht erwähnt habe.
Mir fallen da verschiedene mögliche Gründe ein.
Zum einen ist es so, dass POSIX eine erweiterte Bourne-Shell als Standard für alle Unix-Systeme spezifiziert und zumindest unter Linux und OpenBSD standardmäßig erweiterte – und in ihrem Erweiterungen weitgehend kompatible – POSIX-Shells zum Einsatz kommen. Solaris wird das schätzungsweise auch so machen. (FreeBSD fällt hier aus der Reihe, aber auch dort ist zumindest die Standard-Shell für normale Nutzer eine erweiterte POSIX-Shell, wenn auch deren Erweiterungen nicht so weit reichen wie bei Bash, KornShell oder Z Shell.)
Das heißt, es gibt neben dem explizit definierten Standard für die Kommandozeilensprache unter Unix auch noch eine Art De-facto-Standard an Erweiterungen. Und das ist, bei aller berechtigten Kritik an der idiosynkratischen Syntax und der Mangelhaftigkeit der Shell-Sprache, eine ziemlich komfortable Situation, denn die Unix-Kommandozeile kommt damit faktisch einer universellen Benutzerschnittstelle relativ nah.
Hinzu kommt, dass, im Gegensatz zu grafischen Desktop-Umgebungen, der Kommandozeileninterpreter offenbar viel eher in Aufgabenbereichen eingesetzt wird, in denen es wirklich drauf ankommt, dass Dinge stabil laufen. Die Shell ist schlicht das klassische Werkzeug von (professionellen) Systemadministratoren, deren Arbeitsbereich sich üblicherweise eher schlecht für Experimente eignen dürfte.
Und sind Skripte einmal in Bash oder KornShell geschrieben und wurden womöglich über Jahre hinweg vorsichtig verbessert, wird da sicherlich (und verständlicherweise) wenig Bereitschaft bestehen, daran grundlegend etwas zu ändern.
Das führt gleich zum nächsten Punkt: Bei Betriebssystemshells spielt Rückwärtskompatibilität eine große Rolle.
Desktopumgebungen unter Linux nimmt, wie mir scheint, ohnehin niemand wirklich ernst, was ich gut nachvollziehen kann. Daher ähnelt dieser Bereich, wohl oder übel, auch eher einer Spielwiese für Entwickler.
Mir wäre mehr Diversität bei Unix-Shells auch eher ein Graus. Gut wäre stattdessen, wenn einfach eine Shell wie Es den Status einer gängigen Alternative zu den Bourne-ähnlichen Shells erlangen würde.
Man hat sozusagen schon was davon, indem man sie einfach nur installiert.
Mir geht sie aber in manchen Dingen einfach nicht weit genug und macht Dinge anders als ich sie mir wünschen würde.
Dennoch ist es eine sehr empfehlenswerte Shell für Leute die da mal was anderes abseits von Bash probieren wollen.Ich sag ja auch nicht, das andere Shells dafür verschwinden sollen. Aber als Ergänzung? warum nicht?
Kann man ja so ein bisschen vielleichen mit dem vi. Den gibts auch "überall". Wenn Du also irgendwie unter nem "UNIX" ne Datei editieren willst, kannst Du sicher sein nen vi zu haben. Es ist praktisch, wenn man den zumindest halbwegs beherrscht.
Trotzdem würde ich nicht auf die Idee kommen ihn deshalb ständig einzusetzen.
Warum sollte ich das bei einer Shell nicht machen? Ich muss ja nicht mal meine Standardshell ändern. Ich kann ja meine Lieblingsshell jederzeit aufrufen, wenn ich meine ich möchte sie in dem Augenblick nutzen.
Genau dann ist aber die Shell eher wacklig. Gerade wenn Du Scripting-Sachen machst. Es gibt einfach so viele Stolperfallen. Klar kann man die umgehen. Aber besser ist natürlich, wenn es die gar nicht erst gibt.Hat ja auch niemand behauptet, das bestehende Skripte alle neu geschrieben werden sollen.Aber wo wir gerade beim Scripting sind:
Ne Shell erfüllt ja i.d.R. heutzutage zwei Aufgaben. Erstens das schon angesprochene Scripting, zweitens eine interaktive Benutzerstelle. Mal abgesehen davon, das es gegen "one Job one tool" verstößt ist es auch so, das es beides nicht optimal erfüllt und vielleicht auch nicht erfüllen kann.
Nicht umsonst gibt es ja immer mal wieder Bestrebungen den Scripting-Teil mit was anderem zu machen. Perl ist ja da das klassische Beispiel für. Die reellen Geschehnisse zeigen also schon, das es da eine gewisse Spannung in der Thematik gibt.
Fürs Bereich Skripting hat sich da ne Menge getan. Sei es nun Perl, Python, Ruby oder was auch immer, da gibt es reichlich Optionen die den Teil angehen und Alternativen bieten. POSIX-Shell-Scripte oder von mir aus auch noch Bash-Skripte haben natürlich weiterhin den Charme, das sie überall ohne großarige Voraussetzungen laufen. Aber damit hat es sich auch schon an Vorteilen.
Auf der Seite der Interaktion mit dem Nutzer hast Du das meines Erachtens nach weniger Bewegung drin. Es gibt sie, aber die sind eben (wie schon gesagt) nicht so präsent.
Wie gesagt. Es schätze es auch, wenn es einen Minimalstandard gibt der überall funktioniert. Für den täglichen Gebrauch wäre mir das aber dann doch zu rudimentär und unkomfortabel.
Zumindest teilweise gibt es das.
Ich für meinen Teil arbeite gerne mit dem Programm "Konsole" in der GUI.
Dort per Tastatur aufgerufen 'mc' (Aufruf könnte man auch komplett mit dem Desktop verbinden)
lässt sich einiges per Maus machen. Nur nicht Drag&Drop. Beim Mac (zertifiziertes UNIX mit Bash) geht was.
Unter Linux kenne ich nur Terminalprogramme, die damit zurechtkommen, mit Klick auf "Knöpfe" und Doppelklick auf andere Elemente inn mc. Ich benutze beides, Tastatur und Maus.
Man könnte sich aber weitergehendes selber machen. Nur nicht Drag&Drop, sondern über Kontext-Menü.
Es fehl also jemand, der Yoink äh ... ja nein Yoink für die Linux-Welt nachprogrammiert, wie damals Launchd nachprogrammiert wurde.
Grad bei KDE5 hat man das schön beobachten können.
Wenn man mal überlegt, das KDE sogar mal unter Windows anständig lief, dann sind solche Entwicklungen eher unerfreulich.
Zumal ja Viele aus der Linux-Community früher immer Microsoft vorgehalten haben das die eigene Standards durchdrücken und zu nichts kompatibel sind. Und jetzt macht mans nicht besser.
Ja. Wobei ich ungern Sachen machen würde, die nur auf einem Desktop funktionieren. Wenn dann würde ich wohl eher auf freedesktop.org-Standards zurückgreifen auch wenn ich dafür eingeschränkte Möglichkeiten in Kauf nehmen muss.Das kannte ich bisher noch gar nicht. Zeigt aber Ansätze wie ich sie mir auch vorstelle.Als Demo wie so was aussehen könnte ist die Seite jedenfalls primaNaja. Warum nur für Linux? Wenn, dann gleich plattformunabhängig.
Es ist ja sowieso immer wieder zu beobachten, dass MS eigentlich lieber ein abgeschlossenes Windows ala iOS/Android hätte, in dem ohne Tricksereien nur über den Store irgendwas installieren kann, und die Software dann auch nicht einfach per win32 api loslegt, sondern nur über "moderne" Schnittstellen, die überall verkappt sind. Wo solche Systeme die Normalität werden, ist auch Plattformunabhängigkeit nicht einfach. Schreib mal einen Webbrowser für iOS...
Das wid für Drag&Drop nicht gehen, weil die zugrunde liegenden Architekturen das nicht zulassen werden. Aber schön wär's.
Allein Yoink! ist doch eine fürchterliche Krücke. Aber interessant, dass das mit einer entsprechenden bash-Konfiguration möglich ist. Also müsste man das auch für Linux hinbekommen. Ich persönlich werde mich in nächster Zeit mal um die KDE-Konfiguration von Kontext-Menüs hermachen und meine eigenen Skripte durchgehen, was ich dahin übertragen kann.
Was ich halt nicht will ist so was wie:
Läuft nur auf Linux
Läuft nur auf KDE
Läuft nur bei Vollmond
:-)Ja. Klingt alles ja auch ganz interessant und relativ einfach umzusetzen. Von der her ist es schon eine Sache, die man "einfach mal machen kann".
Ja, das "oder" verstehe ich auch nicht. Es gibt Aufgaben, die man besser in der GUI erledigt und andere sind wieder besser in der Konsole aufgehoben.