Welche Shell(s) benutzt ihr (am liebsten)?
-
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.
-
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.
-
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.
-
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.
-
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.
-
UTF-8 schrieb:
Gehen bei euch Shellscripte mit BOM vorne dran?
Wozu? Speichere eben ohne BOM.
-
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?
-
Quite a lot of Windows software (including Windows Notepad) adds one to UTF-8 files. However in Unix-like systems (which make heavy use of text files for file formats as well as for inter-process communication) this practice is not recommended, as it will interfere with correct processing of important codes such as the hash-bang at the start of an interpreted script. It may also interfere with source for programming languages that don't recognise it. For example, gcc reports stray characters at the beginning of a source file, and in PHP, if output buffering is disabled, it has the subtle effect of causing the page to start being sent to the browser, preventing custom headers from being specified by the PHP script.
-
UTF-8 schrieb:
Es geht darum das UTF-8 Dateien mit BOM schlichtweg existieren
Aber mir Sicherheit keine Shell-Skripte, denn jede Shell hat Probleme mit der BOM. Ich hab das mit bash, sh, zsh und csh ausprobiert. Mit jeder Shell der selbe Fehler:
./test.sh: line 1: #!/bin/sh: No such file or directoryUTF-8 schrieb:
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.Dann benutzt du seltsame Editoren. Alle Editoren, die ich kenne haben keine Probleme mit UTF-8 Texten ohne BOM.
-
utf8'lerin schrieb:
UTF-8 schrieb:
Es geht darum das UTF-8 Dateien mit BOM schlichtweg existieren
Aber mir Sicherheit keine Shell-Skripte, denn jede Shell hat Probleme mit der BOM. Ich hab das mit bash, sh, zsh und csh ausprobiert. Mit jeder Shell der selbe Fehler:
Und genau darum ging es mir ja.
Die Shells sind einfach alle nicht UTF-8 fähig.Eine Shell die das wäre, würden den BOM erkennen und ignorieren und das Script ausführen.
Dann benutzt du seltsame Editoren. Alle Editoren, die ich kenne haben keine Probleme mit UTF-8 Texten ohne BOM.
Dann hast du nicht richtig geschaut.
Nahezu alle Windows Editoren wie Programmers Editor, Crimson Editor, Notepad+, Notepad++, PSPad usw. machen Probleme beim erkennen von UTF-8 Dateien wenn diese kein BOM haben.
Alle Editoren können sie zwar bearbeiten und auch entsprechend speichern, aber nur dann, wenn man manuell wieder die richige Codierung einstellt.Lediglich Gedit und Geany meisten UTF-8 Dateien in allen Varianten mit oder ohne BOM.
Ich habe das bei einem Softwareprojekt in PHP gemerkt, die anderen haben obige Windows Editoren genommen und jedesmal haben die die UTF-8 Dateien die ich ihnen zugeschickt habe, vergurkt oder wieder in einer falschen Codierung abgespeichert (da offensichtlich die Editoren das darin enthaltene UTF-8 nicht erkannt haben oder es erkannt haben aber dann doch wieder in Latin-1 gespeichert haben) und wieder vergurkt.
Probier es mit den obigen Editoren und echten UTF-8 Dateien einfach mal aus.
Nahezu alle machen hier oder da Fehler, bei den einen fällt es sofort auf, bei den anderen muß man genauer hinschauen z.b. passiert es bei manchen erst nachdem man die Datei bearbeitet und gespeichert hat.
-
Hu? Beschwerst Du Dich gerade über Shells, weil Windows-Editoren Unix-Shellskripte kaputten? Wie bereits geschrieben: UTF-8 beherrschen sie ja, lediglich (unnötige) BOMs mögen sie nicht.
Lass Dir einfach diffs zurückschicken, wenn Du mit Windowsentwicklern zusammen arbeitest und die Sache ist erledigt.