Mal 'ne Frage an die Nicht-Power(Shell)-User: Apple hat ja dieses Jahr mit Catalina von der bash auf die zsh umgestellt. Da ich aus der Vor-Linux-Zeit stamme und früher mal auf csh und tcsh gelernt hatte, habe ich mich mit der bash auch nie anfreunden koennen - und nutze nun schon einige Jahre die zsh. Allerdings gibt es ja auch inzwischen interessante Alternativen, wie z.B. fish Was sehen denn Eure Präferenzen bezgl. der Shell aus?
> [..] habe ich mich mit der bash auch nie anfreunden koennen - und nutze > nun schon einige Jahre die zsh. Weißt aber schon dass die zsh im Wesentlichen eine Erweiterung der bash ist, oder? > Was sehen denn Eure Präferenzen bezgl. der Shell aus? bash, natürlich.
Ich nutze zwar Linux aber selten die shell. Wozu auch? Skripte laufen in Python und den Desktop bediene ich graphisch.
Kein produktives Linux-Systeme, mit dem ich zu habe, hat einen Desktop.
Ich nutze zsh, welche entgegen g457 schrieb: > Weißt aber schon dass die zsh im Wesentlichen eine Erweiterung der bash > ist, oder? keine Erweiterung der bash ist. Weder historisch (da wird die ksh als Referenz angegeben), noch funktional (wenngleich einige™ bash-Konstrukte umgesetzt werden können, und so Standardfunktionalität, welche auch die bash bietet, natürlich vorhanden ist).
Karl schrieb: > Ich nutze zwar Linux aber selten die shell. Wozu auch? Skripte laufen in > Python und den Desktop bediene ich graphisch. was hat das jetzt mit dem Thema zu tun? Übrigens, wenn Du auf einer fremden Maschine arbeiten musst, installierst Du dann erstmal Python3 und alles was dazu gehört - das stelle ich mir besonders witzig auf Maschinen vor, die keinen Internetzugang haben - oder deren LAN Karte zickt.
Ich nutze AutoIt. Zur Automatisierung und zusätzlichen "Sicherheit" von Exceldateien und Excelinstanzen (auch wenn das nur Standardanwender schützt, aber das genügt mir).
:
Bearbeitet durch User
René H. schrieb: > Ich nutze AutoIt. Zur Automatisierung und zusätzlichen > "Sicherheit" > von Exceldateien und Excelinstanzen (auch wenn das nur Standardanwender > schützt, aber das genügt mir). Windows <-> Linux
Walter K. schrieb: > Übrigens, wenn Du auf einer fremden Maschine arbeiten musst, > installierst Du dann erstmal Python3 Das ist der Hauptgrund, warum ich (noch) Bash und nicht Zsh benutze. Bash ist auf praktisch jedem Fremdrechner, den ich nutze, installiert, Zsh nicht. Wenn ich mich an die Zsh gewöhnen würde, dann würde ich mich auf diesen Fremdrechnern ziemlich unwohl fühlen. Auch wenn Zsh einige Dinge mehr kann als Bash, machen diese zusätzlichen Features alleine den Umstieg für mich noch nicht attraktiv. Das kann sich in Zukunft aber ändern, wenn - Zsh verbreiteter wird und - Das Delta von Zsh gegenüber Bash deutlich zunimmt.
Walter K. schrieb: > Übrigens, wenn Du auf einer fremden Maschine arbeiten musst, > installierst Du dann erstmal Python3 und alles was dazu gehört - das > stelle ich mir besonders witzig auf Maschinen vor, die keinen > Internetzugang haben - oder deren LAN Karte zickt. Wie soll man denn dann die shell der Wahl installieren, wenn man python nicht installieren kann?
mh schrieb: > Wie soll man denn dann die shell der Wahl installieren, wenn man python > nicht installieren kann? Die Antwort hast du vermutlich überlesen: Yalu X. schrieb: > Bash ist auf praktisch jedem Fremdrechner, den ich nutze, installiert, > Zsh nicht.
hugo schrieb: > mh schrieb: >> Wie soll man denn dann die shell der Wahl installieren, wenn man python >> nicht installieren kann? > > Die Antwort hast du vermutlich überlesen: > > Yalu X. schrieb: >> Bash ist auf praktisch jedem Fremdrechner, den ich nutze, installiert, >> Zsh nicht. Das ist nur eine Antwort auf meine Frage, wenn bash die shell der Wahl ist. Das trifft aber nicht auf jeden zu. Und "praktisch jedem" bedeutet nicht "jedem".
Ich denke, wer ’n Linuxsystem bedienen kann, wird die grundlegenden Sachen auch mit ›sh‹ (heute meist bereitgestellt von der dash) hinbekommen. Ich meine, wenn ich bevorzugt die zsh nutze, heißt das ja nun nicht, dass ich an Rechnern, auf denen diese Shell nicht verfügbar ist, nichts machen könnte.
Walter K. schrieb: > Welche Shell nutzt ihr denn so? Diese hier: http://db-service.toubiz.de/var/plain_site/storage/images/orte/immenstaad/shell-tankstelle/shell_logo/1082782-1-ger-DE/Shell_logo_front_large.jpg
Habe in der Vergangenheit hauptsächlich die ksh verwendet, aber heute ist eigentlich die bash die "mainstream shell" geworden die ich mittlerweile auch hauptsächlich verwende weil sie einfach da ist. Dadurch das alle anderen Unix-Derivate zusehends aussterben ist die Kompatibilität auch nicht mehr so wichtig. Zumal es da auch bei der ksh so Probleme zwischen der freien (pdksh) und der AT&T ksh gab. Aber meistens sind meine Shellskripte eher nicht so komplex, dass es grossartige Abhängigkeiten gibt. Ein paar Befehle aufrufen, Ausgaben auswerten, einfache(!) Schleifen. Alles größere siehe unten. Ab einer gewissen Komplexität wird Shell auch sehr unhandlich und frickelig. Klar kann man ein bisschen awk oder perl einstreuen, aber das macht es auch nicht einfacher. Gut, dass es Python gibt :)
:
Bearbeitet durch User
mh schrieb: >> Yalu X. schrieb: >>> Bash ist auf praktisch jedem Fremdrechner, den ich nutze, installiert, >>> Zsh nicht. > > Das ist nur eine Antwort auf meine Frage, wenn bash die shell der Wahl > ist. Er hat doch auch geschrieben, dass gerade das der Grund ist, warum bash die Shell seiner Wahl ist.
Ich kannte mal einen der sich fuer einen Guru hielt, aber nicht mal "hash -r" kannte. Da hat er nur ein dummes Gesicht gemacht. Unbezahlbar
Rolf M. schrieb: > mh schrieb: >>> Yalu X. schrieb: >>>> Bash ist auf praktisch jedem Fremdrechner, den ich nutze, installiert, >>>> Zsh nicht. >> >> Das ist nur eine Antwort auf meine Frage, wenn bash die shell der Wahl >> ist. > > Er hat doch auch geschrieben, dass gerade das der Grund ist, warum bash > die Shell seiner Wahl ist. Das passiert, wenn nicht vollständig zitiert wird. Ich habe nicht auf Yalu geantwortet, sondern auf Walter K. Ich habe Walter K. zitiert und ihm eine Frage gestellt. Dies Frage hat er, oder jemand anderes, bis jetzt nicht beantwortet.
mh schrieb: > Walter K. schrieb: >> Übrigens, wenn Du auf einer fremden Maschine arbeiten musst, >> installierst Du dann erstmal Python3 und alles was dazu gehört - das >> stelle ich mir besonders witzig auf Maschinen vor, die keinen >> Internetzugang haben - oder deren LAN Karte zickt. > > Wie soll man denn dann die shell der Wahl installieren, wenn man python > nicht installieren kann? Gar nicht - indem man einfach mit der shell arbeitet, die man vorfindet. Das schafft auch jemand der z.b. die bash kennt und auf ner FreeBSD Maschine mit tcsh was machen muss oder auf ner OpenBSD Kiste, auf der die ksh default ist. Jemand der erst Python installieren muss, kommt u.U. auch ans Ziel ... zumindest irgendwann mal
Walter K. schrieb: > Gar nicht - indem man einfach mit der shell arbeitet, die man vorfindet. > Das schafft auch jemand der z.b. die bash kennt und auf ner FreeBSD > Maschine mit tcsh was machen muss oder auf ner OpenBSD Kiste, auf der > die ksh default ist. > > Jemand der erst Python installieren muss, kommt u.U. auch ans Ziel ... > zumindest irgendwann mal Aber warum fragst du dann nach unseren Präferenzen, wenn wir eh nur benutzen dürfen was auf irgend einem System installiert ist?
Walter K. schrieb: > Jemand der erst Python installieren muss, kommt u.U. auch ans Ziel ... > zumindest irgendwann mal Auf welchem der genannten Systeme ist denn Python nicht eh normalerweise schon drauf?
> ist denn Python nicht
Auf allen Systemen wo es bei einer Minimalinstallation nicht dabei ist,
und der Benutzer eine Nachinstallation nicht fuer noetig befunden hat.
Diese Logik scheint dir nicht bekannt zu sein.
Python dürfte aber auf wesentlich mehr Rechnern vorzufinden sein als Zsh. Aber natürlich ist Python kein vollwertiger Ersatz für eine Shell und umgekehrt.
Man kann viel Scripting wahlweise in einer der besseren Shells machen, oder in Python/Perl/Sonstwas Ich beschloss vor einigen Jahrzehnten, dafür einheitlich Perl zu verwenden. Weil es das unter DOS, OS/2 16/32, WinNT+, AIX, Linux, etc verfügbar war, ggf. auch selbst portiert. Infolgedessen bin ich bei der Shell ziemlich flexibel, denn ich programmiere darin kaum.
:
Bearbeitet durch User
Mich würde mal so interessieren, was ihr "auf fremden Rechner" so arbeitet und warum kein "produktives Linux-System" einen Desktop hat. Nach meinem Verständnis kann man mit der Shell auch nur Befehle ausführen und ein paar Dateien umherschubsen. Oder sind hier im Forum tausende Administratoren unterwegs, die Webserver und HPC administrieren?
Karl schrieb: > warum kein "produktives Linux-System" einen Desktop hat. Bei Linux Servern ist eine GUI eher selten anzutreffen. Und war oben halt meine vorrangige Sicht als Sysadmin. Immerhin gibt sich auch Microsoft mittlerweile etwas Mühe, für Windows Server eine GUI überflüssig zu machen. > tausende Administratoren unterwegs, die Webserver und HPC > administrieren? Im Nachbarstreit über die beste Distri findest du mehr. ;-)
:
Bearbeitet durch User
A. K. schrieb: > Kein produktives Linux-Systeme, mit dem ich zu habe, hat einen Desktop. Worauf entwickelst Du, wo browst Du das www?
Bernd K. schrieb: > Worauf entwickelst Du, Nicht jeder hier im Forum wickelt beruflich Enten. Dafür habe ich aber schon mal einen alten vertrockneten Entwickler hinter dem Schrank hervorgezogen und entsorgt. > wo browst Du das www? Jetzt grad? Windows auf einem Netbook, auf dem m.W. kein Linux vernünftig läuft. Linux war früher auch schon dabei. Aber was ich vorhin schrieb, bezog sich auf meine berufliche Tätigkeit, und da ist es Windows.
:
Bearbeitet durch User
Karl schrieb: > Mich würde mal so interessieren, was ihr "auf fremden Rechner" so > arbeitet und warum kein "produktives Linux-System" einen Desktop hat. Fremde Rechner auf der Arbeit sind bei mir Oracle Datenbanken auf Solaris, Oracle Application Server unter Linux, APEX Listener in Tomcat Servern unter Linux, diverse selbst programmierte Webservices (JSP's für PDF Bearbeitung, Barcodeerstellung, XSL-FO Transformation, Axis2 Endpoints mit WS-Security), und virtualisierte periphere Systeme… SSL-Proxies, Apache Filterproxies, Fileserver, Mediawiki zur Dokumentation, CVS Server und Git Repository. Und noch ein paar Sachen mit denen ich nichts zu tun habe, Abbyy Dokumentenverwaltung/Scanstation/Dokumentenerkennung zum Beispiel. Die meißten Server brauchen keine grafische Oberfläche - das Frisst nur Speicher und CPU Zyklen und ist für nichts gut, weil… > Nach meinem Verständnis kann man mit der Shell auch nur Befehle > ausführen und ein paar Dateien umherschubsen. …die Shell echt mächtig ist. > Oder sind hier im Forum > tausende Administratoren unterwegs, die Webserver und HPC > administrieren? Tausende sicher nicht, aber sicher ein paar - so wie ich :) Wobei ich eigentlich offiziell keine Administration mehr mache, sondern Java Entwicklung.
>Welche Shell nutzt ihr denn so?
Die in der Bismarck-Str. ist ganz gut. Gegen Abend ist da das V-Power
billigsten.
Bernd K. schrieb: > A. K. schrieb: >> Kein produktives Linux-Systeme, mit dem ich zu habe, hat einen Desktop. > > Worauf entwickelst Du, wo browst Du das www? Er sagte doch ausdrücklich "produktives System". Wenn man browsen kann, kann man nicht mehr produktiv sein ;) Aber im Ernst: Produktivsysteme sind Server mit irgendwelchen Diensten (zB. FS, DB, Web, ...), die die "Produktion" am Laufen halten. Normale Benutzer-PCs fallen nicht darunter, egal wie produktiv man daran arbeitet...
> einheitlich Perl zu verwenden
Blos gut das ich mit UNIX angefangen habe, als noch ein C-Compiler
zur Grundausstattung gehoerte. Perl war da noch nichtmal gedacht.
Wenn man etwas brauchte, was mit Bourneshell, Csh und dem Rest des
Systems nicht ging, dann schrieb man sich das. In C. Fertig.
Das lief dann einigermassen portabel auch unter MS-DOS oder
dem Rest der (BS-)Welt.
Man kann mit Perl nicht vernuenftig vernuenftige Software entwickeln.
Die die heute noch mit Perl herumhantieren, haben regelmaessig auch
den Anschluss an den Rest der Enwicklung mit ihrem seligen Perl
verschlafen. Zumindest die ich so kenne...
diepoetteringdie schrieb: > Man kann mit Perl nicht vernuenftig vernuenftige Software entwickeln. Völlig richtig. In diesem Thread geht es aber m.E. um Shells und Scripting, nicht um Anwendungsentwicklung.
Georg A. schrieb: > Bernd K. schrieb: > A. K. schrieb: > Kein produktives Linux-Systeme, mit dem ich zu habe, hat einen Desktop. > > Worauf entwickelst Du, wo browst Du das www? > > Er sagte doch ausdrücklich "produktives System". Wenn man browsen kann, > kann man nicht mehr produktiv sein ;) > Aber im Ernst: Produktivsysteme sind Server mit irgendwelchen Diensten > (zB. FS, DB, Web, ...), die die "Produktion" am Laufen halten. Normale > Benutzer-PCs fallen nicht darunter, egal wie produktiv man daran > arbeitet... Was ist mit Systemen die Automaten steuern oder irgendwelche Hardware in der Produktion und wo Bildschirme oder gar Eingabegeräte dran sind, oder Terminals für spezielle Zwecke, gelten die wenigstens als produktiv? Wenn ja dann ist auch der Arbeitsplatz an dem meine Schaffenskraft in die Maschine gesaugt und dort verwendet wird produktiv. Und ich bin der Behälter mit dem Verbrauchsmaterial.
:
Bearbeitet durch User
diepoetteringdie schrieb: >> ist denn Python nicht > > Auf allen Systemen wo es bei einer Minimalinstallation nicht dabei ist, > und der Benutzer eine Nachinstallation nicht fuer noetig befunden hat. > > Diese Logik scheint dir nicht bekannt zu sein. Die Trivialität, dass Python auf Systemen nicht installiert ist, auf denen es nicht installiert ist, schon als Logik zu bezeichnen, halte ich für übertrieben. Ich hab aber danach auch nicht gefragt, sondern danach, wie oft das in der Praxis vorkommt. Wenn du schon so einen Ton anschlägst, lerne erst mal das sinnerfassende Lesen. Georg A. schrieb: > Aber im Ernst: Produktivsysteme sind Server mit irgendwelchen Diensten > (zB. FS, DB, Web, ...), die die "Produktion" am Laufen halten. Normale > Benutzer-PCs fallen nicht darunter, egal wie produktiv man daran > arbeitet... Wo kommt diese Definition her? Ich kenne Produktivsystem nur in dieser Bedeutung: https://www.computerwissen-online.de/?page=lexika&action=view&content=2618 Dabei ist ganz egal, ob das jetzt ein Desktop-System oder ein Server ist, oder ein Verbund aus beidem.
Walter K. schrieb: > Was sehen denn Eure Präferenzen bezgl. der Shell aus? Üblicherweise sollte man mit der Shell zurechtkommen, die auf dem System VERFÜGBAR ist und mit der man sich etwas auskennt. Man sollte wachsam bleiben. Nicht jede Option ist überall gleich.
Walter K. schrieb: > Was sehen denn Eure Präferenzen bezgl. der Shell aus? Ich nutze auf meinen privaten Rechner sowie in der Arbeit 'Oh My Zsh'. Also die Zsh mit ein paar Erweiterungen. Meine Shell-Scripte rufen die Shell bzw. Bash auf. Wobei diese nicht kompliziert sind. Bin ja kein Sys-Admin.
Für Shellskripte kann man sich auch auf das POSIX-Subset beschränken, wenn's portabel sein soll. So eine Shell sollte man als /bin/sh eigentlich auf so ziemlich jedem unixoiden System vorfinden.
Beitrag #6067278 wurde von einem Moderator gelöscht.
Bin aktuell bei der Fish, will wegen der eigenartigen Syntax aber wieder zu einer konventionellen Shell zurück.
Rolf M. schrieb: > Für Shellskripte kann man sich auch auf das POSIX-Subset beschränken, > wenn's portabel sein soll. So eine Shell sollte man als /bin/sh > eigentlich auf so ziemlich jedem unixoiden System vorfinden. Das ist nur nicht ganz so einfach, wenn man nicht bei jedem einzelnen in einem Skript genutzten Feature im POSIX-Standard nachschlagen möchte, ob es auch wirklich POSIX-konform ist. Oder gibt es vielleicht so etwas wie eine POSIX-Referenz-Shell, die exakt den POSIX-Standard ohne jegliche Erweiterungen implementiert, und mit der man ein Skript auf POSIX-Konformität prüfen kann? Dash und Posh kommen diesem Ideal wohl recht nahe, aber auch diese Shells unterscheiden sich in ein paar Punkten vom Standard.
Georg A. schrieb: > Wenn man browsen kann, kann man nicht mehr produktiv sein ;) Und was ist mit Filesystem-Browsern?
Uhu U. schrieb: > Und was ist mit Filesystem-Browsern? cd, ls, find, grep. Mehr brauchts nicht. Ok, pushd/pop ist noch ganz hilfreich.
Aktueller Artikel: https://www.dev-insider.de/welche-linux-shell-darf-es-sein-a-860645/ Wobei mir als 'Windowsianer' die ganzen Shells nie ganz geheuer waren, wozu braucht es dutzende von Shells? Erinnert mich immer an 4DOS und DR DOS - kurz installiert und angeschaut, um es dann wieder ganz schnell loszuwerden.
Markus schrieb: > Wobei mir als 'Windowsianer' die ganzen Shells nie ganz geheuer waren, > wozu braucht es dutzende von Shells? Windows: Wenn jemandem etwas nicht passt, frisst er gezwungenermassen was ihm vorgesetzt wird und schimpft wie ein Rohrspatz auf Bill Gates. Linux: Wenn jemandem etwas nicht passt, programmiert er sich eine Lösung und stellt die dem Rest der Welt zur Verfügung. Wo es mehr Lösungen gibt liegt dann auf der Hand.
Markus schrieb: > Wobei mir als 'Windowsianer' die ganzen Shells nie ganz geheuer waren, > wozu braucht es dutzende von Shells? Erinnert mich immer an 4DOS und DR > DOS - kurz installiert und angeschaut, um es dann wieder ganz schnell > loszuwerden. Man braucht nicht Dutzende! Es genügen rudimentäre Kenntnisse einer Shell, ein paar basics der regular expressions und Grundverstaendnis vom vi! Irgendwann will man mehr, dann macht man sich Gedanken welche Shell sich besser eignet und kommt dann zu Ergebnissen wie zsh, bash oder fish... und lernt die Genialität vom vi erkennen und arbeitet dann mit vim oder neovim. Aber das sind Dinge, die 'Windowsianer' sicher ganz anders sehen und die wohl auch etwas verstören - was ja auch o.k. ist, wenn sie persönlich mit dem Windowskram auskommen.
Yalu X. schrieb: > Oder gibt es vielleicht so etwas wie eine POSIX-Referenz-Shell Die ksh (ksh88) kommt wohl der Posix-Referenz am nächsten, da sie die Grundlage für die Beschreibung des Command Interpreters im POSIX-Standard bildete und im Wesentlichen mit dieser identisch ist. Siehe auch: https://de.wikipedia.org/wiki/Kornshell
Yalu X. schrieb: > Oder gibt es vielleicht so etwas wie eine POSIX-Referenz-Shell, die > exakt den POSIX-Standard ohne jegliche Erweiterungen implementiert, und > mit der man ein Skript auf POSIX-Konformität prüfen kann? Das ist in der Praxis in der Tat schwierig. Mir wäre auch keine Shell bekannt, die man so einstellen kann, dass sie wirklich nur das kann, was POSIX definiert und nichts anders. Dazu kommt dann noch, dass es mit der Shell ja nicht getan ist. Shellskripte brauchen ja in der Regel noch einen ganzen Stall voll anderer Tools. Auch von denen müsste man dann nur die POSIX-Subfunktionalität nutzen.
Wenn man POSIX Kompatiebel bleiben will, muss man um sehr viel GNU/bashismus herumarbeiten. Echo z.B. kann man komplett vergessen (sh) "echo 'te\nst'" = (bash) "echo -e 'te\nst'", keine Veriante, die bei beiden gleich ist. printf hingegen verhält sich auf beiden grössten teils gleich.
Rolf M. schrieb: > Mir wäre auch keine Shell bekannt, die man so einstellen kann, dass sie > wirklich nur das kann, was POSIX definiert und nichts anders.
1 | $ bash --posix |
2 | $ echo $POSIXLY_CORRECT |
3 | y |
4 | $ exit |
Auszug aus https://www.gnu.org/software/bash/manual/html_node/Bash-POSIX-Mode.html : Starting Bash with the --posix command-line option or executing ‘set -o posix’ while Bash is running will cause Bash to conform more closely to the POSIX standard by changing the behavior to match that specified by POSIX in areas where the Bash default differs. P.S. Ich persönlich verwende nur Bourne-Shell-Konstrukte in Shell-Scripts. Dann ist man auf der sicheren Seite. Man kommt damit ganz gut aus, auch wenn es nicht immer so komfortabel ist. Das fängt schon bei der Verwendung von Backticks statt $(...) an.
:
Bearbeitet durch Moderator
Frank M. schrieb: > $ bash --posix Damit wird zwar POSIX-konformer Code korrekt ausgeführt, evtl. genutzte Bash-Erweiterungen werden aber dennoch nicht abgelehnt. Frank M. schrieb: > Die ksh (ksh88) kommt wohl der Posix-Referenz am nächsten Danke. Leider scheint die ksh88 nicht Open-Source zu sein (das wurde die ksh erst mit ksh93). Von ksh88-Nachbauten wie pdksh und mksh heißt es, sie unterschieden sich in einigen wichtigen Punkten vom Original, so dass sie nicht als Referenz herhalten können. Das mit der POSIX-Referenz-Shell ist aber auch nicht so wichtig. Ich dachte nur, wenn es so etwas gäbe, könnte ich meine Skript zukünftig streng POSIX-konform schreiben. Sonst schreibe ich sie eben streng Bash-konform, was ja mittlerweile auch ein De-facto-Standard ist.
Zum bedienen meiner Kiste im täglichen Gebrauch benutze ich fish. Bei meinen ganzen Embedded Boards / scripten benutze ich bash. Und ganz selten auch sh
:
Bearbeitet durch User
Was sind denn die herausragenden Features der genannten "anderen" shells die einem im normalen Gebrauch am meisten nützen? Beim Scripten ist es klar, da gits in einigen Shells nette Konstrukte die es anderswo nicht gibt, die manche Sachen einfacher oder schöner machen, aber was davon (sofern man sich die Syntax merken kann) kommt einem bei der Interaktion direkt am Prompt zugute? Könnte es einen normalen Benutzer der am Bash-Prompt bestenfalls mal ne kleine Pipe zusammenbaut und alles kompliziertere immer googeln muss und dann ein Script draus macht dazu bewegen oder es ihm erleichtern direkt am Prompt auch mal komplexere oder nützlichere Dinge zu tun und dadurch produktiver zu werden? Was sind da erfahrungsgemäß bei interaktiver Nutzung die Killerfeatures der einen oder anderen alternativen Shell?
:
Bearbeitet durch User
Bernd K. schrieb: > Was sind denn die herausragenden Features der genannten "anderen" shells > die einem im normalen Gebrauch am meisten nützen? [...] > Was sind da erfahrungsgemäß bei interaktiver > Nutzung die Killerfeatures der einen oder anderen alternativen Shell? Für mich waren damals (ist schon einige Jährchen her ...) für den Umstieg auf die zsh Features wie Tab-Completion, Menu-Completion, Commandline-Editing inkl. History über Cursortasten die wichtigsten. Auch die Syntax war IMHO für die üblichen One-Liner ein wenig bequemer. Im täglichen Gebrauch sind es auch solche Kleinigkeiten wie "|&" um STDOUT und STDERR gleichzeitig umzuleiten - klar, geht auch anders, aber interaktiv auf der Commandline ist halt Bequemlichkeit Trumpf. Und heutzutage hast du auch nicht mehr nur einfache Command-Completion, sondern kannst da verschiedene nutzen, je nach Befehl kommen dann bei den Argumenten z.B. nur PDF-Files oder Debian-Packages oder was auch immer da am besten passt. Halt ein wenig näher am DWIM-Interface. ;-)
Bernd K. schrieb: > Was sind denn die herausragenden Features der genannten "anderen" shells > die einem im normalen Gebrauch am meisten nützen? Ich nutze Oh My Zsh, also die Zsh mit ein paar Erweiterungen. Was mir daran gefällt bzw. ich nutze: - Suche in der History: Ich tippe z.B. ‚mv‘ ein und mittels Pfeiltaste-oben gehe ich durch die History der letzen Befehle, die mit ‚mv‘ beginnen. - Theme: Bei meinem Terminal-Theme wird der aktuelle Pfad über der Eingabeauforderung angezeigt. Außerdem steh der Git Branch immer dabei (Theme avit: https://github.com/ohmyzsh/ohmyzsh/wiki/Themes) - Da gibt es für manche Befehle Abkürzungen. Z.B. ‚rs‘ ist ein Alias für ‚rails server‘. Haben quasi schon andere für einen angelegt. - Auf ‚cd‘ kann man verzichten. Einfach los tippen und mit Tabulator ergänzen... Alles keine Killerfeatures, aber ganz nett. Wobei das mit ‚History Suche‘ schon praktischer ist als ‚Strg-r‘.
Naja, also History search mit den Pfeiltasten kann man in Bash auch haben, muss man nur in der inputrc aktivieren. Promptverzierungen mitsamt git status hab ich auch in der Bash, ebenso gibt's da natürlich auch Aliase und Tab completion.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.