Menü
Avatar von ZüriseeKraken
  • ZüriseeKraken

23 Beiträge seit 28.05.2018

Re: Wazu braucht man das für Linux ?

Hört sich gut an soweit. Vielleicht gibt es diese Features ja auch in künftigen Versionen der Shell(s).

Es scheint in der Tat Bemühungen in diese Richtung zu geben. Bekannt ist mir, dass einige Linux-Tools JSON auf STDOUT ausgeben können. Damit hat man auch unter einer Unix-Shell sowas wie strukturierte Daten. Mit einem JSON-Parser, ebenfalls ein Shell-Tool, können Werte bequem aus dem JSON rausgeholt werden. Habe damit aber keine persönliche Erfahrung. Die Untertstützung dafür ist wohl auch noch alles andere als vollständig und noch bei Weitem nicht breit etabliert.

Bei PS hat man das natürlich mit dabei, weil es zu den Grundkonzepten dieser Shell gehört. Und die Typisierung kann eine Unix-Shell so natürlich nicht. In PS sind z.B. Zahlen auch echte Zahlen mit denen man (direkt) rechnen kann.

Will man aber plain Linuxshell mit Windows vergleichen, muss man fairerweise mit plain CMD vergleichen. Und da sieht es ganz finster aus - in jeder Hinsicht.

Ich habe auch schon Batchscripting gemacht - gegen diese Schmerzen hilft kein Aspirin der Welt. Die Windows-CMD-Tools sind großteils einfach nur grottig, allein eine halbwegs brauchbare Kopierfunktion gab es erst mit "robocopy". Und Dateipfade kann man eigentlich auch nur in Anführungszeichen gesetzt sicher verwenden. Die "-? / \h" Hilfefunktionen sind nur sehr begrenzt hilfreich (wie man es unter Windows ja gewohnt ist).

Warum ist es unfair PS nicht mit andern Shells zu vergleichen? Alle sind als Shell konzipiert, die sich sowohl für Scripting als auch interaktiv nutzen lassen. Wobei mein Eindruck ist, dass PS etwas mehr für Scripting optimiert ist, während klassische Unix-Shells sehr stark auf die interaktive Nutzung optimiert sind und für diesen Anwendungsfall durchaus Stärken gegenüber PS haben.

Trotzdem, Powershell ist primär eine Shell die auch interaktiv genutzt werden kann und will. Damit finde ich den Vergleich zu Unix-Shells schon berechtigt.

Betreffend CMD, brauchen wir uns nicht streiten. Die ist einfach abartig schlecht ;-D. Allgemeine Empfehlung ist deshalb auch, dass die CMD nur noch für Rückwärtskompatibilität da ist. Für alles Neue nimmt man unter Windows PS.

Zudem kann man bei komplexeren Aufgaben in Linux auch gleich auf Perl, Python, Node-JS oder Go umschwenken - die sind wie die PS als Erweiterung zu betrachten, ebenfalls mit eigener Syntax - und ggf. sicherlich sowohl der Shell als auch der PS weit überlegen, außer u. U. in der Performance. Bash Buil-Ins, Shellexpansion, Globbing und Substitution sind superschnell.

Wie performant ist die PS denn im Vergleich zum nativen Batchscript?

Absolut einverstanden. Unter Unix hat man noch weitere Alternativen. Wobei sich PS auch doch noch ein paar Vorteile erhalten kann. Dazu gleich mehr.

Python ist meine bevorzugte Sprache für Skripting unter Unix. Gerne mit sh.py, womit externe Commands sehr elegant aufgerufen werden können. Python ist viel besser lesbar und wartbar als Bash-Skripte. Von der Sprache/Syntax her finde ich Python auch besser als PS.

Bloss zwei Nachteile gegenüber PS hat es:

1. Aufrufe von externen Commands, wie beim Skripting üblich, schreiben immer noch Strings auf STDOUT raus. Den muss ich dann trotz Python immer noch parsen. Wenigstens kann man in Python die Parse-Logik in einem wiederverwendbaren Modul ablegen.

2. Und Python ist nicht wirklich für interaktive Nutzung geeignet. Ist eben eine Programmiersprache und keine Shell. Obwohl es ja Leute geben soll, die Python interaktiv nutzen.

Vor allem wegen Punkt 1 finde ich PS gegenüber Python interessant. Trotzdem würde ich jetzt nicht hingehen, und allein deswegen PS auf einem Unix installieren. Das finde ich nur sinnvoll, wenn man eine gemischte Windows- & Unix-Umgebung hat und Teile seiner PS-Module auch unter Unix verwenden will.

Zur Performance kann ich nicht viel sagen. Ich nutze Shells und Skriptspachen nur, wenn Performance vernachlässigbar ist. Denn wirklich schnell sind die alle nicht. Go zähle ich nicht zu den Skriptsprachen, da der Code compiliert wird. Dürfte daher von den erwähnten am schnellsten sein. Von den interpretierten Sprachen erwarte ich, dass Python und Perl generel schneller sind als Shells, solange man sich an natives Python/Perl hält und nicht zu viele externe Programme aufruft.

Das Starten eines Prozesses ist relativ teuer und damit haben eigentlich alle Shells Performance-Probleme.

Bewerten
- +
Anzeige