Welche Shell(s) benutzt ihr (am liebsten)?

rüdiger schrieb:

Bash. Ganz einfach, weil die zsh kein UTF8 kann (wobei sich das ja geändert haben soll) und weil die bash fast überall schon vorhanden ist.

Ach funktioniert das endlich?
Shellscripte in UTF-8 mit BOM vorne dran?

Shell-User schrieb:

Nervt dich die Shell-Scripting-Syntax nicht?

Ich finde sie furchtbar und würde eher ein Perl-Skript schreiben, bevor ich ein SH-Skript schreibe. Mit Bash lässt es sich recht angenehm programmieren, auch wenn (( )) und [[ ]] anfangs etwas gewöhnungsbedürftig aussehen.
Aber wer schonmal ein Lisp-Programm gesehen hat, lässt sich von sowas kaum abschrecken.

Also ich finde die Programmierung in Shell Scripting Syntax generell grauenhaft, auch bei der Bash.

Und richtig übel wird es erst, wenn man Dinge braucht die die Shell von haus aus nicht kann und man dann auf awk und so übles Zeug zurückgreifen muß.
Dann wird aus einem leserlichen Code schnell mal so ein undurchschaubares Gewurschtel: )§(DMK§/36D§="djDF das keine Sau versteht.

Ich rate daher jedem seine Scipte lieber in Python zu schreiben, das ist sauber, sicher, elegant und leistungsfähig.

Benutzt jemand von euch irb (interactive ruby shell) oder etwas vergleichbares für seinen täglichen Aufgaben anstelle einer der "normalen" Shells?

rüdiger

Python rulez schrieb:

Ich rate daher jedem seine Scipte lieber in Python zu schreiben, das ist sauber, sicher, elegant und leistungsfähig.

Shellskripte sind doch idr nur Write-only Sachen oder eben Dinge, die sich am besten mit Shellskripten realisieren lassen (Irgend welche Anwendungswrapper oder eben portable Skripten oä). Warum sollte man sich da also um Sauberkeit, Sicherheit oder Eleganz gedanken machen?

Ganze Anwendungen würde ich damit auch nicht schreiben wollen.

nman

Dass der UTF8-Support von zsh nicht so toll ist (War das Problem nicht nur der ZLE?), stört mich nicht, zsh und aterm sind für mich grund genug, kein UTF8-Locale zu verwenden. (Wobei ich aterm notfalls noch eher entbehren könnte.)

supertux schrieb:

Hab die shell auch in eine sehr guten LiveCD gesehen (weiß den Namen nicht mehr ), die gut als Reparatur-LiveCD benutzt werden kann.

Könnte grml gewesen sein, mika bastelt recht gerne am tollen ZSH-Support: http://grml.org/zsh/

Was sollte der Vorteil von IRB sein? Das ist doch als Alltagsshell für den Allgemeineinsatz nur mühsam.

Sagt mal was für ein Locale habt ihr? Ich benutze bash mit aterm und Umlaute funktionieren, aber statt dem Euro-Symbol sehe ich nur eine Art Stern.
Locales hab ich wie folgt:

$ locale
LANG=en_US
LC_CTYPE=de_DE@euro
LC_NUMERIC="en_US"
LC_TIME="en_US"
LC_COLLATE="en_US"
LC_MONETARY="en_US"
LC_MESSAGES="en_US"
LC_PAPER="en_US"
LC_NAME="en_US"
LC_ADDRESS="en_US"
LC_TELEPHONE="en_US"
LC_MEASUREMENT="en_US"
LC_IDENTIFICATION="en_US"
LC_ALL=

Danke für den Hinweis nman und ich wunderte mich damals, warum mit UTF-8 so große Probleme vorhanden waren

supertux

Python rulez schrieb:

Ich rate daher jedem seine Scipte lieber in Python zu schreiben, das ist sauber, sicher, elegant und leistungsfähig.

bash-skripte sind nicht dazu gedacht, Programme zu schreiben oder so. Wenn du mal schnell Milch holen willst, nimmst du auch dein Fahrrad und nicht einen Mostertruck; mit dem Monstertruck bist du auch leistungsfähiger Scherz beiseite, eine shell (sagen wir mal zumindest sh) ist in jedem Unix-artigen OS drauf, python nicht, und gerade wenn ich sowas wie ein tinyLinux bauen will, werde ich bestimmt kein python/perl/großes ding installieren. Das ist der Vorteil von sh, es ist einfach immer da und ist klein und schlank.

nman schrieb:

supertux schrieb:

Hab die shell auch in eine sehr guten LiveCD gesehen (weiß den Namen nicht mehr ), die gut als Reparatur-LiveCD benutzt werden kann.

Könnte grml gewesen sein, mika bastelt recht gerne am tollen ZSH-Support: http://grml.org/zsh/

genau die meinte dich

rüdiger schrieb:

Shellskripte sind doch idr nur Write-only Sachen oder eben Dinge, die sich am besten mit Shellskripten realisieren lassen (Irgend welche Anwendungswrapper oder eben portable Skripten oä). Warum sollte man sich da also um Sauberkeit, Sicherheit oder Eleganz gedanken machen?

Weil ein Code in Python der z.b. Werte aus einer Textdatei ausliest deutlich übersichtlicher und sauberer ist als ein AWK oder ED Pendant.
Das meinte ich mit Sauber.

Außerdem kann man dann mit den Daten auch noch mehr machen, z.b. in eine XML Datei Speichern.

supertux schrieb:

Scherz beiseite, eine shell (sagen wir mal zumindest sh) ist in jedem Unix-artigen OS drauf, python nicht, und gerade wenn ich sowas wie ein tinyLinux bauen will, werde ich bestimmt kein python/perl/großes ding installieren. Das ist der Vorteil von sh, es ist einfach immer da und ist klein und schlank.

Es mag ja sein das sh immer da ist, es gehört ja auch sogar zum POSIX Standard (bei der BASH ist das zumindest die Untermnge die die POSIX Shell abbildet), aber mangelnder Speicher für Python ist heutzutage kein Thema mehr.
Jeder USB Stick bietet mehr als 1 GB RAM, das ist genug Speicherplatz um neben der tinyLinux Distribution noch Problemlos Python draufzupacken und 3.5" Disketten nutzt heute wirklich kein Mensch mehr für ein Linux System.
Wer wirklich nicht von einem USB Stick booten kann, der hat zumindest ein CD-ROM Laufwerk mit dem er eine Linux Distribution starten kann, auf der auch noch Python draufpaßt.

Und wegen den Unixartigen OS.
Für nahezu jedes Unix artige OS, von FreeBSD, OpenBSD, Solaris bis hin zu MacOS X gibt es eine Version von Python, es ist also kein problem darauf Python zu installieren.

Und seien wir doch mal ehrlich.
Einfache Skripte hat man in Python sehr schnell geschrieben.
Aufgrund der leichteren Lesbarkeit und Mächtigkeit von Python würde ich sogar sagen, daß man damit schneller ist, als mit SH in Kombination mit AWK, ED und Co.

nman

Ach, wenn ich ein funktionierendes, gut gewartetes und lesbares Stück Bash-Skript habe, dann habe ich überhaupt kein Problem, das mit Awk oder sed oä zu erweitern.

Python ist zwar nett, aber auch nicht die Lösung aller Probleme, die ich für jeden trivialen kleinen Hack aus der Trickkiste hole. Shellskripte haben immer noch ein riesengroßes Anwendungsfeld, nämlich all das, wofür man noch kein Python einsetzen würde.

Und Verfügbarkeit ist nach wie vor ein Thema: Wenn ich mit vergleichbarem Aufwand Shell oder Python verwenden kann, nehme ich Shell. Natürlich ist für nahezu jedes moderne Unix irgendwo ein Python verfügbar, aber es gibt auf _jedem_ Unix eine Bourne Shell fix und fertig installiert.

rüdiger

Python rulez schrieb:

Weil ein Code in Python der z.b. Werte aus einer Textdatei ausliest deutlich übersichtlicher und sauberer ist als ein AWK oder ED Pendant.
Das meinte ich mit Sauber.

Ja und? Das ändert ja nichts an dem was ich gesagt habe. Wobei gerade mit AWK ist das bearbeiten von Textdateien doch wirklich sehr übersichtlich. Kennst du dich vielleicht nur nicht mit AWK gut aus und dafür mit Python?

Außerdem kann man dann mit den Daten auch noch mehr machen, z.b. in eine XML Datei Speichern.

Kann man mit sh auch

echo "<foo><bar /></foo>" > toll.xml

Python rulez schrieb:

Und wegen den Unixartigen OS.
Für nahezu jedes Unix artige OS, von FreeBSD, OpenBSD, Solaris bis hin zu MacOS X gibt es eine Version von Python, es ist also kein problem darauf Python zu installieren.

Man kann... _Man_ kann... Aber es ist nicht unbedingt vorinstalliert und wenn dann vielleicht in einer uralten Version. Neulich musste ich damit kämpfen, dass ich ein Pythonprogramm hatte und /usr/bin/python bei mit pythhon2.3 ist und irgend wo anders ein python2.4.

Und seien wir doch mal ehrlich.
Einfache Skripte hat man in Python sehr schnell geschrieben.
Aufgrund der leichteren Lesbarkeit und Mächtigkeit von Python würde ich sogar sagen, daß man damit schneller ist, als mit SH in Kombination mit AWK, ED und Co.

Du bist damit vielleicht schneller, weil du dich mit Python besser auskennst, als mit AWK.

Aber das ist sowieso eine Schwachsinnsdiskussion...

---
Die meisten "Skripte" die ich erstelle sind ohnehin für den laufenden Betrieb. Warum sollte ich einen Editor öffnen, die Python-Dokumentation suchen, das Programm runter schreiben, debuggen und dann ausführen, wenn ich es innerhalb von 2 Minuten mit sh und sed gebastelt habe. Das "Skript" ist dann eben nur in meiner History. Schaut sich ja kein Schwein mehr an...

Also ich schreibe auch größere Sachen in Bash. Hab mir ein Skript geschrieben das im Hintergrund läuft und meinen Akkustand überwacht und bei Bedarf eine Nachricht per xmessage anzeigt und eine benutzerdefinierte Funktion ausführt.
Könnte man natürlich auch in Python schreiben, oder einer anderen Sprache, aber warum sollte ich?
Awk habe ich an 4Stellen benutzt um aus einer Datei die entsprechenden Werte rauszufiltern.

Ich finde hier wird ein sehr vorbildliches Shell-Skript entwickelt.

mastercpp

Frage zu Shell+UTF-8 schrieb:

rüdiger schrieb:

Bash. Ganz einfach, weil die zsh kein UTF8 kann (wobei sich das ja geändert haben soll) und weil die bash fast überall schon vorhanden ist.

Ach funktioniert das endlich?
Shellscripte in UTF-8 mit BOM vorne dran?

Jap, ab Version 4.3.2 ist zsh voll Unicode-fähig. Zusammen mit rxvt-unicode einfach unschlagbar.

supertux

Python rulez schrieb:

es gehört ja auch sogar zum POSIX Standard (bei der BASH ist das zumindest die Untermnge die die POSIX Shell abbildet),

und genau deswegen verwendet man sh, wenn es um Verfügbarkeit und Portablität geht.

Python rulez schrieb:

aber mangelnder Speicher für Python ist heutzutage kein Thema mehr.
Jeder USB Stick bietet mehr als 1 GB RAM, das ist genug Speicherplatz um neben der tinyLinux Distribution noch Problemlos Python draufzupacken und 3.5" Disketten nutzt heute wirklich kein Mensch mehr für ein Linux System.
Wer wirklich nicht von einem USB Stick booten kann, der hat zumindest ein CD-ROM Laufwerk mit dem er eine Linux Distribution starten kann, auf der auch noch Python draufpaßt.

Bei Desktop PCs ja, aber die Welt besteht nicht nur aus Desktop PCs. Soll ich auf Microcontroller oder Embedded System, wo ich begrenzte Speicherkapazität hab, python installieren? Ich denke nicht. Selbst wenn ich ein initrd am Desktop benutze: am besten sh für die Skripte, dann ist das initrd auch klein.

Python rulez schrieb:

Und wegen den Unixartigen OS.
Für nahezu jedes Unix artige OS, von FreeBSD, OpenBSD, Solaris bis hin zu MacOS X gibt es eine Version von Python, es ist also kein problem darauf Python zu installieren.

siehe oben, es gibt in der Welt auch andere Computer Typen als Desktop PC

Python rulez schrieb:

Und seien wir doch mal ehrlich.
Einfache Skripte hat man in Python sehr schnell geschrieben.
Aufgrund der leichteren Lesbarkeit und Mächtigkeit von Python würde ich sogar sagen, daß man damit schneller ist, als mit SH in Kombination mit AWK, ED und Co.

nein, ich kenne gute übersichtliche bash Skripte, die eindeutiger und lesbarer sind als Python. Ich will nicht sagen, dass python schlecht ist (als gentoo evangelist/fan/benutzer muss ich das quasi "mögen") aber ich finde es nicht, das python auf anhieb verständlich ist. Die Syntax von sh Skripten ist deutlich intuitiver als von python/perl/usw.

python ist nicht schlecht, beruflich wird bei uns viel in python geschrieben (ich bin der C Entwickler), also weiß ich, dass python gut ist. Aber python ist nicht die Lösung für alle Probleme. Wenn du das nicht einsiehst, dann lebst du in einer Seifenblase. rüdiger, nman und ich haben dir genug gute Gründe gegeben, wann sh sinvoller ist und wann python sinvoller ist.

supertux

mastercpp schrieb:

Frage zu Shell+UTF-8 schrieb:

rüdiger schrieb:

Bash. Ganz einfach, weil die zsh kein UTF8 kann (wobei sich das ja geändert haben soll) und weil die bash fast überall schon vorhanden ist.

Ach funktioniert das endlich?
Shellscripte in UTF-8 mit BOM vorne dran?

Jap, ab Version 4.3.2 ist zsh voll Unicode-fähig. Zusammen mit rxvt-unicode einfach unschlagbar.

ich hab gestern app-shells/zsh-4.3.4-r1 installiert und konnte UTF-8 problemlos benutzen (mit dem gnome-terminal). Hiragana Zeichen, äöüß, das war alles kein Problem.

Gehen bei euch Shellscripte mit BOM vorne dran?
Ich glaube nämlich nicht.

Und wenn ihr nicht wißt, was ein BOM ist, dann könnt ihr auch nicht mitreden.

nman

UTF-8 schrieb:

Gehen bei euch Shellscripte mit BOM vorne dran?

Wozu? Speichere eben ohne BOM.

.filmor

Abgesehen davon ist ein BOM bei UTF-8 unglaublich sinnfrei …

Es geht darum das UTF-8 Dateien mit BOM schlichtweg existieren und die meisten Editoren bei UTF-8 Dateien ohne BOM Probleme beim erkennen von UTF-8 bekommen,
was zur Folge hat, das UTF-8 mit BOM bei denen die Voreinstellung ist.

Was ist denn BOM?