13.08.2022, aktualisiert am 15.08.2022

10115

Warum PowerShell und nicht Batch?

Ich gehöre der Generation an, für die Batch noch die Sprache der Wahl war. Grund ist, dass (nach alter Shellscript Manier) eine ganze Reihe von kleinen Kommandozeilenprogrammen existieren, die jeweils für spezielle Aufgaben erstellt wurden. Aufgaben, für die andere seinerzeit gängige Scriptsprachen (wie VBScript) zum Teil keine Möglichkeit geboten haben. Seit Jahren wird aber hier im Forum immer wieder darauf hingewiesen, dass man Batch besser links liegen lässt. Leider oft genug ohne eine wirkliche Erklärung zu geben. Seit vielen Jahren bin ich in einem Windows-Batch Forum als Moderator und Helfer unterwegs. Ich kenne die ganzen Unzulänglichkeiten, Eigenheiten und Fallstricke von Batch in- und auswendig. Vielleicht qualifiziert mich das ausreichend, um beurteilen zu können, warum man für administrative Aufgaben bei denen es auf Verlässlichkeit ankommt, die PowerShell vorziehen sollte.

Ich fange aber erst einmal umgekehrt an, da ich das Folgende so oder ähnlich immer wieder hier lese. (Soll so etwas wirklich überzeugen, von Batch auf eine andere Sprache umzusteigen? Hmmm...)

"Batch ist aus dem vorigen Jahrtausend". Die meisten heute noch in großem Stil verwendeten Programmiersprachen sind auch aus dem vorigen Jahrtausend. Was also soll das aussagen? Mit dem Nachsatz "... und seitdem wurden bekannte Bugs nie gefixt." wäre es ein Argument geworden, aber dazu habe ich unten noch etwas geschrieben.
"Das geht mit PowerShell auch kürzer" ist eher ein Gegenargument. Die Pipe-Syntax von PowerShell verleitet dazu, möglichst alles in eine Codezeile zu quetschen und erzeugt somit eher strukturlosen, schwer lesbaren Code.
"Batch ist viel zu langsam" taugt nur bedingt als Argument. Scripte sollen oft einfach nur stupide Aufgaben automatisieren. Dazu sollen sie, einmal angestoßen, möglichst unüberwacht laufen. Somit ist es in vielen Fällen auch egal ob die Laufzeit nun 5 oder 50 Sekunden beträgt. Einfach parallel seiner Arbeit nachgehen, und gut Wer trotzdem Wert auf Performance legt, sollte bedenken, dass es ein Break-Even gibt. Bei einfachen "Miniaufgaben" kann allein das Startup von PowerShell mit seinen ganzen Abhängigkeiten auch schnell mal länger dauern, als dieselbe Aufgabe mit Batch abzufackeln. (Warnung: Daraus abzuleiten, dass ein Mix unterschiedlicher Scriptsprachen für eine Aufgabe zu einer besseren Performance führen könnte, "verschlimmbessert" die Situation in den allermeisten Fällen.)

Echte Argumente, die gegen Batch sprechen, sind (IMHO):

Batch ist eine der eingeschränktesten Sprachen überhaupt. Seinen Ursprung hat Batch als einfacher "Stapel" von einzelnen Kommandozeilen. Diesen Charakter hat es nie ganz verloren. Batch ist somit nur eine rudimentäre, nie ausgereifte Scriptsprache. Aufgaben für die es kein separates Kommandozeilentool gibt, sind oft unlösbar. Es gibt keine Möglichkeit direkt auf .NET Klassen oder die Win32 API (oder die API von Drittanbieter-Bibliotheken) zuzugreifen.
Batch ist eine der schwersten Scriptsprachen überhaupt. Das wird anfangs oft unterschätzt, weil man schnell Erfolge für vermeintlich komplizierte Aufgaben erzielen kann. Aber: Die Definition und Verwendung von Variablen kann Seiteneffekte haben. Die Reihenfolge, in der Anweisungen innerhalb von Kommandozeilen geschrieben werden, kann Seiteneffekte haben. Die Verwendung oder das Weglassen von Leerzeichen in Kommandozeilen kann Seiteneffekte haben. Abgesehen von UTF-8 (in einem eingeschränkten Umfang) gibt es keinen Unicode Support; dagegen interpretiert die CMD üblicherweise in einem anderen Charset als Editoren in denen der Scriptcode geschrieben wird, was Seiteneffekte haben kann. Variablen sind Umgebungsvariablen, somit werden Änderungen der Umgebung unmittelbar an Child-Prozesse weiter vererbt. All diese Eigenheiten (die detaillierter zu beschreiben, hier den Rahmen sprengen würden und die oft keinen bestimmten Regeln folgen), muss man kennen und im Hinterkopf behalten, wenn man Batchcode schreibt, was es fast unmöglich macht Scripte ohne Bugs zu schreiben.
Das Verhalten von Kommandozeilen, die in einem Batchscript ausgeführt werden, kann sich vom Verhalten von Kommandozeilen die in einem CMD-Prompt ausgeführt werden unterscheiden.
Arithmetik ist ein Alptraum. Grundrechenarten und bitweise Operationen werden unterstützt. Mehr nicht. Nicht einmal Fließkommazahlen, nur 32 Bit breite vorzeichenbehaftete ganze Zahlen. Somit ist 2 / 3 = 0.
Viele Datentypen, bspw. Array- und DateTime-Typen, die in anderen Sprachen gang und gäbe sind, gibt es in Batch schlichtweg nicht.
Batch unterstützt keine asynchrone Ausführung von Code in Threads/Jobs.
Fehlerbehandlung ist schwierig. Man ist darauf angewiesen, dass Rückgabewerte vernünftig gesetzt werden und man muss diese theoretisch für jedes Kommando separat checken. Exceptions und Exception Handling gibt es nicht.
Batch erlaubt aus Kompatibilitätsgründen und wegen des Fehlens bestimmter Schleifentypen (wie bspw. WHILE) das Anspringen von Labels mittels GOTO, was zum Schreiben von unlesbarem und unwartbarem "Spaghetticode" verleitet (obwohl seit NT die Ausführung von Subroutinen möglich ist).
Die Beschränktheit der Sprache führt dazu, dass jeder Bug und jedes undefinierte Verhalten ausgenutzt wird (Hyrum's Law in seiner Extremform, da über die Jahrzehnte gezielt nach verwertbaren Exploits gesucht wurde). So etwas ist keine vernünftige Basis für Produktivcode.
Die Tatsache, dass bereits alle möglichen Bugs gezielt in Scripts ausgenutzt werden, verhindert, dass Microsoft überhaupt noch in der Lage war/ist, Bugs zu fixen. Das würde viel zu viele Scripte weltweit von heute auf morgen unbrauchbar machen (siehe Anmerkung des Console/Terminal Kernteams zur CMD die sich ebenso auf die üblicherweise in Batchscripts verwendeten Systemtools übertragen lässt). Batch bleibt somit eine fehlerbehaftete Sprache mit unzähligen Bugs, die oft nur schwer erkennbar sind wenn sie sich nur unter bestimmten Bedingungen zeigen.

Kurz und knapp ein paar der Argumente, die für PowerShell sprechen (ohne jeglichen Anspruch auf Vollständigkeit):

Auch hier gibt es für spezielle Aufgaben vorgefertigte CmdLets, damit das Rad nicht ständig neu erfunden werden muss. Aber darüber hinaus ist alles was mit .NET möglich ist, auch in der PowerShell möglich. Das beinhaltet den Zugriff auf die Plattform API, wenn nötig.
Threading in Form von asynchronen Jobs wird unterstützt.
Skripte lassen sich signieren.
Unicode wird unterstützt. (BTW: Die Entwicklungen bei PowerShell, Windows Terminal und selbst Notepad deuten darauf hin, dass wir wohl mittelfristig auch auf Windows mit UTF-8 als Quasi-Standard für textbasierte Interfaces rechnen dürfen.)
PowerShell wird aktiv weiterentwickelt. PowerShell Core ist ein Open Source Projekt und nicht nur für Windows, sondern bspw. auch für Linux Distros und macOS verfügbar. Scripte können also ggf. auch über Plattformgrenzen hinaus genutzt werden.

Steffen

/EDIT: Argumente aus dem Feedback ergänzt.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-Key: 3637667605

Url: https://administrator.de/contentid/3637667605

Ausgedruckt am: 23.04.2024 um 20:04 Uhr

21 Kommentare

Neuester Kommentar

Tach @rubbermann,

gute Argumentation, welche Du lieferst. Ich komme ja auch noch von der alten DOS(en) Welt, wo man niXX anders hatte. Später bin ich dann Zu REXX gekommen, welches im Mainframebereich genutzt wird. Was ich dann auch bei OS/2 und auch heute noch bei Windows nutze. Zwischendrin habe ich mich an VBScript versucht, was ich aber aufgrund der Inkonsistenz abgebrochen habe. Perl hat auch seine Vorteile, wie auch Nachteile. Klar wer, obfuscated Skripte schreibt braucht sich nicht zu wundern, wenn man dann seinen eigenen Code nicht mehr versteht.

Das ist aber auch bei PowerShell so.

Bei PowerShell vermisse ich etwas die Konsistenz, weil die Eigenschaften und Methoden von Objekten sich einem nicht gleich erschließen. In einem Workshop hat ein Kursleiter angefangen mit Get-Member um die Eigenschaften und Methoden von Objekten zu erläutern. Das ist für mich das Pferd von hinten aufziehen.

Bei den Skriptsprachen REXX und Perl, wie auch bei den klassischen Programmiersprachen ist die Herangehensweise anders. Man lernt erst was Variablen sind wie diese definiert werden. Dann kommt die Syntax, usw.

Bei PowerShell geht man meiner Meinung nach anders vor. Und deshalb tun sich einige, wie auch ich sich damit schwer.

Ein weiterer Pluspunkt für PowerShell ist, man kann diese Skripte signieren, was bei Batches nicht geht. Das ist ein Sicherheitsaspekt.

Und trotzdem, finde ich eine Batchdatei hat auch heute noch seine Daseinsberechtigung.

Gruss Penny.

Servus.

[...]* "Das geht mit PowerShell auch kürzer" ist eher ein Gegenargument. Die Pipe-Syntax von PowerShell verleitet dazu, möglichst alles in eine Codezeile zu quetschen und erzeugt somit eher strukturlosen, schwer lesbaren Code.

Nur, wenn man PowerShell nicht beherrscht.

Ich blicke auf >25 Jahre in der IT zurück und auch bei mir haben sich viele Batch- und VBS-Skripte angehäuft. Ca. 90% davon habe ich mittlerweile durch PowerShell ersetzt, schlicht weil es da eben ein One-Liner tut, der nicht mal dokumentiert werden muss.

Cheers,
jsysde

@Penny.Cilin
Klar gibt es andere Alternativen zu Batch. Windows hat die PowerShell halt an Bord, was bequem ist und was dazu führt das Scripte auf jeder Maschine laufen, ohne was nachinstallieren zu müssen.

Ich höre auch nicht auf Batchcode zu schreiben und Fragen zu Batch zu beantworten. Das hat eine ganze Reihe von Gründen:

Bin damit groß geworden und kenne die Bugs und Workarounds.
Ich brauche Scripting quasi gar nicht mehr. Ich mach mir einen Jux draus immer noch weitere Bugs von Batch und mögliche Exploits dafür zu finden. Neue Scripts die aber noch wirklich was Sinnvolles tun sollen, sind bei mir auch schon PowerShell und nicht mehr Batch.
Es gibt noch genügend alten Batch Code auf der Welt der seine Arbeit problemlos erledigt. Den zu warten, statt komplett in eine neue Sprache zu übertragen, ist oft eine Frage von (nicht vorhandenen) Kapazitäten. Time is Money. Bei uns laufen auch noch Logon Batch Scripts, die im Wesentlichen nichts anderes tun als Netzlaufwerke zu trennen und neu zu verbinden. Niemand sieht eine Veranlassung die zu ersetzen. Stellen ja auch kein Risiko dar.

Ich denke aus letzterem Grund ist es auch heute noch sinnvoll wenn IT-ler zumindest in der Lage sind, Batch Code zu lesen und zu verstehen. Aber ich habe wenig Verständnis, wenn jemand heute noch Batch als Maß der Dinge sieht und darauf baut. Das ist nicht State of the Art. Und ich hoffe ich habe das mit meinen Argumenten im Beitrag oben entsprechend rüber gebracht

@jsysde

Nur, wenn man PowerShell nicht beherrscht.

Das gilt für jede Sprache.

Früher, und damit meine ich vor der Jahrtausendwende, war Speicher kostbar. Kostbar, weil er extrem begrenzt war und weil jedes Byte teuer war. Wenn du heute irgendwo Multimedia (z.B. ein Video) auf deiner Platte gespeichert hast, dann mach mal die Rechnung auf wie viele tausend Male eine Plaintextdatei wie ein Script dort hinein passen würde und was ein paar Extrabytes für eine lesbare Struktur mit Codeeinrückungen da noch ausmachen. Nein, glaub mir, dann fängt man am falschen Ende an zu sparen. Der Vorteil der Lesbarkeit überwiegt. Wenn du in einem halben Jahr mal in den Code schaust und eine halbe Stunde länger brauchst um ihn wieder zu verstehen, nur weil du ein paar Bytes eingespart hast und Code "kürzer" ist, dann hast du eine halbe Stunde Lebenszeit vergeudet. Und die ist unbezahlbar ...

Steffen

N'Abend.

@rubberman:
Du hast mich falsch verstanden - mir geht es nicht um das Einsparen von 2kb, sondern darum, dass ein PowerShell One-Liner keinerlei Dokumentation benötigt. Es ist schlicht beim draufschauen klar, was der tut.

Ich skripte seit einiger Zeit fast ausschließlich in PowerShell und selbstverständlich beginnen all meine Skripts mit einer "Synopsis", in der Autor, Version/Changelog und Verwendung erläutert werden.

Cheers,
jsysde

Moin,

Besten Dank @rubberman.

Ich bin da (ebenfalls) recht hybrid unterwegs. Aus vielerlei Gründen.

Wer in der Industrie unterwegs ist, trifft auch schonmal auf Systeme, die die Powershell nicht mal in der Kristallkugel sehen können. Daher bleibt nur Batch.
Ferner nutze ich für kleinere Dinge ebenfalls gerne die Batch. Stupide CopyJobs sind da in der Batch genauso schnell geschrieben, wie in der PS. Nur dass zur Laufzeit die PS nicht geladen werden muss.

Wenn es „komplexer“ wird, weil halt aus CSV-Files Daten in eine DB geschrieben werden sollen, Bieter sich die PS einfach eher an. Früher hab ich dazu noch VBS genutzt. Das ist nativ auf Windows verfügbar und mich nicht separat ins Patchmanagement aufgenommen werden (anders als Pearl/ Python/ …).
Durch den Schwenk von VBS auf PS lies sich somit einiges an Code sparen (Code != Codezeilen), da es schlicht einfacher ist, Informationen in eine Datei zu schreiben.

Und ich stimme dir zu: nur weil OneLiner „bis zum erbrechen“ möglich sind, muss man diese nicht zwingend nutzen. Solange ich/ jemand anderes den Code ohne tagelanges Studium versteht, ist es IMHO wurscht, ob als OnLiner oder Multiliner (und ich meine nicht den Einsatz von Backticks)

Fazit: alle Sprachen haben ihre Vor- und Nachteile und der Einsatz jener ist von der Situation als auch den eigenen Kenntnissen abhängig. Ein Batch-Gott kann hier mitunter Probleme effizienter lösen, als ein PS-Laie, wenngleich der PS-Code sich sicherlich intuitiver lesen lässt.

Gruß
em-pie

Hallo

bei PowerShell kann man davon ausgehen, dass es ein oder mehrere Windows Updates überlebt
und dann auch noch funktioniert ohne angepasst werden zu müssen.

Dobby

Ich hab bestimmt Batch Scripts die mehr als 100 Windows Updates überlebt haben ohne angepasst werden zu müssen

Das war jetzt aber kein Argument für Batch, denn die ganzen Bugs von Batch haben dieselben 100 Windows Updates überlebt ohne gefixt zu werden ¯\_(ツ)_/¯

Steffen

Moin,

Und deswegen nimmt man bash oder tcsh.

lks

Moin Steffen,

Zitat von @rubberman:
Seit Jahren wird aber hier im Forum immer wieder darauf hingewiesen, dass man Batch besser links liegen lässt.

imho muss man hier strickt trennen (so mache ich es zumindest), zwischen Usern, die gerade erst neu anfangen Batch zu erlernen - und Usern, die Batch bereits beherrschen und wirklich nur nach einer Lösung für ein akutes Problem suchen.
Für Erstere macht es natürlich keinen Sinn mehr, Batch jetzt noch zu erlernen - da Powershell eben nicht nur weitaus mächtiger ist, sondern vorallem auch deutlich leichter zu erlernen ist. Letztere dürfen aber natürlich ruhig gerne weiter auf Batch zurückgreifen.

Leider oft genug ohne eine wirkliche Erklärung zu geben.

Das ist den Threads unterzubringen ist leider auch kaum möglich. Wenn man erst auf 2 DIN-A4 Seiten erläutert, welche Nachteile die Nutzung von Batch mitbringt, bevor man sich dann noch der eigentlichen Problemlösung widmet, artet das Ganze einfach zu sehr aus. Hier müssen Neulinge dann auch einfach mal auf den Rat der erfahreneren vertrauen.
Aber jetzt können wir ja auch einfach mal auf den Thread hier verweisen, danke dafür 👍

* "Das geht mit PowerShell auch kürzer" ist eher ein Gegenargument. Die Pipe-Syntax von PowerShell verleitet dazu, möglichst alles in eine Codezeile zu quetschen und erzeugt somit eher strukturlosen, schwer lesbaren Code.

Hier bin ich etwas geteilter Meinung. Ich stimme dir in dem Punkt voll und ganz zu, dass gepipte Einzeiler hier oftmals fehl am Platz sind, da sie für den TO, der sich mit der Sprache kaum auskennt, nicht nachzuvollziehen sind und somit auch keinen Lerneffekt erzielen.
Aus diesem Grund versuche ich oft auch so gut es geht, unnötiges Pipen und Aliase zu vermeiden und stattdessen ausführlicher zu arbeiten.
Dennoch sind allerdings oftmals bei Problemen in Powershell nur noch 2-3 Codezeilen (ohne Pipes) nötig, um Dinge zu tun, für die man in Batch einen ellenlangen Code brauchte.

Echte Argumente, die gegen Batch sprechen, sind (IMHO):
...

Hier wäre imho vorallem noch anzufügen, dass es mit Batch kaum bis gar nicht möglich ist, Fehler anständig abzufangen und/oder darauf zu reagieren.

Unicode wird unterstützt.

Hier muss ich entgegnen: Batch kann auch längst Unicode

. Imho ist auch bei Batch längst best Practice:

Skript speichern als UTF-8 (hier halt nur wichtig: ohne BOM!)
chcp 65001

mit dieser Konfiguration sind Umlaute, ß, Sonderzeichen usw. kein Problem mehr.

Gruß Thomas

Hallo Thomas.

Wenn man erst auf 2 DIN-A4 Seiten erläutert ...

Nein, natürlich nicht. Aber mit sinnvollen Argumenten.
In der Art erst kürzlich hier gelesen:
"Nutze die PowerShell! Schließlich fahre ich auch nicht mehr mit der Dampflok zur Arbeit."

Jemand könnte dann in gleicher Weise kontern:
"Nutze Batch! Schließlich dreht sich die Erde schon fast 5 Milliarden Jahre um die Sonne und es ist gut und richtig, wenn sie das auch noch die nächsten paar Milliarden Jahre tut."

Ich will hier nicht den Moralapostel spielen. Mir ist schon klar, dass das eher als Belustigung gemeint ist. Aber tatsächlich ist diese Art der Argumentation der Grund, warum ich es irgendwie als überfällig empfunden habe, diesen Beitrag zu schreiben. Dass sie sich auf einen völlig anderen Kontext beziehen, macht die beiden obigen Beispiele eher spaßig. Oft haben solche Argumente aber einen gemeinsamen Kontext, bloß keinen kausalen Zusammenhang. Und da wird's kritisch, weil etwas logisch klingt, was keinen logischen Zusammenhang hat.

Hier muss ich entgegnen: Batch kann auch längst Unicode

Jein. Die CMD kann das schon recht gut, im Zusammenspiel mit üblichen Kommandozeilentools klappt das aber zum Teil nicht.
Beispiel: Im Arbeitsverzeichnis liegt eine Datei mit Namen "€'´` ,; @ü# Я^-§!$%&(){}=.txt" (nur damit Unicode auch einen Sinn macht

).
Batch Code UTF-8 ohne BOM:

@echo off
>nul chcp 65001
echo 1 ~~~~~~~~~~~~~~~~~~~~~
dir /b *.txt|find "€"  
echo 2 ~~~~~~~~~~~~~~~~~~~~~
dir /b *.txt|findstr "€"  
echo 3 ~~~~~~~~~~~~~~~~~~~~~
dir /b *.txt|findstr "@"  
pause

Ausgabe:

1 ~~~~~~~~~~~~~~~~~~~~~
€'´` ,; @ü# Я^-§!$%&(){}=.txt  
2 ~~~~~~~~~~~~~~~~~~~~~
3 ~~~~~~~~~~~~~~~~~~~~~
€'´` ,; @ü# Я^-§!$%&(){}=.txt  
Drücken Sie eine beliebige Taste . . .

Find.exe kann, was Findstr.exe nicht kann, obwohl auch Findstr in der Lage ist die Multibyte Zeichen von UTF-8 durchzuschleusen. Und schon sind wir wieder bei inkonsistentem Mist.

Steffen

Moin Zusammen,

man muss nicht zwangsweise zwischen links und rechts entscheiden, sämtliche CMD Befehle gehen auch in Power-Shell. 😉

Grüsse aus BaWü
Alex

Zitat von @MysticFoxDE:

Moin Zusammen,

man muss nicht zwangsweise zwischen links und rechts entscheiden, sämtliche CMD Befehle gehen auch in Power-Shell. 😉

Und man kann powershell-Kommandos und -Skripten auch in der Command-Shell aufrufen.

lks

Wie oben schon geschrieben:

(Warnung: Daraus abzuleiten, dass ein Mix unterschiedlicher Scriptsprachen für eine Aufgabe zu einer besseren Performance führen könnte, "verschlimmbessert" die Situation in den allermeisten Fällen.)

PowerShell Code in der CMD auszuführen kann man machen. Aber die PowerShell braucht wirklich verhältnismäßig lang für das Startup. Macht man so etwas häufiger in einem Batchscript, muss man sich nicht wundern warum die Laufzeit in die Höhe geht. Dieses Startup Delay hat man zwar auch wenn man eine .ps1 ausführt, dann aber nur einmal.
Im umgekehrten Fall: CMD Befehl ist nicht gleich CMD Befehl. Ein Teil davon sind interne Funktionen der cmd.exe. Die PowerShell hat oft gleichnamige Aliase für CmdLets. Die zu verwenden ist in Ordnung. Daneben gibt es die externen Tools. Die in der PowerShell zu nutzen bedeutet immer, dass das OS einen neuen Prozess eintakten und erzeugen muss. Passiert so etwas in einer Schleife, wirst du einen deutlichen Performance Drop feststellen.

Hier mal ein Stückchen Code das lediglich die Befehle betrachtet, die HELP listet. Die Windows Hilfe gibt nämlich keinen Hinweis darauf, was davon externe Kommandozeilentools sind.

@echo off &setlocal EnableDelayedExpansion
set /a "int=0,ext=0"  
for /f %%i in ('help^|findstr /rbc:"[A-Z][ABCDEFGHIJKLMNOPQRSTUVWXYZ]"') do (  
  for /f "tokens=1,2 delims=?" %%j in ("%%i.exe?%%i.com") do (  
    if "%%~$PATH:j%%~$PATH:k"=="" (  
      set /a "int+=1"  
      set "line=%%i                                                  "  
      echo !line:~,50! - internal
    ) else (
      set /a "ext+=1"  
      echo %%i "%%~$PATH:j%%~$PATH:k"  
    )
  )
)

echo(
echo internal %int%
echo external %ext%
pause

Ausgabe auf meinem Win11 Laptop derzeit:

ASSOC                                              - internal
ATTRIB "C:\Windows\System32\attrib.exe"  
BREAK                                              - internal
BOOTCFG                                            - internal
CACLS "C:\Windows\System32\cacls.exe"  
CALL                                               - internal
CD                                                 - internal
CHCP "C:\Windows\System32\chcp.com"  
CHDIR                                              - internal
CHKDSK "C:\Windows\System32\chkdsk.exe"  
CHKNTFS "C:\Windows\System32\chkntfs.exe"  
CLS                                                - internal
CMD "C:\Windows\System32\cmd.exe"  
COLOR                                              - internal
COMP "C:\Windows\System32\comp.exe"  
COMPACT "C:\Windows\System32\compact.exe"  
CONVERT "C:\Windows\System32\convert.exe"  
COPY                                               - internal
DATE                                               - internal
DEL                                                - internal
DIR                                                - internal
DISKPART "C:\Windows\System32\diskpart.exe"  
DOSKEY "C:\Windows\System32\doskey.exe"  
DRIVERQUERY "C:\Windows\System32\driverquery.exe"  
ECHO                                               - internal
ENDLOCAL                                           - internal
ERASE                                              - internal
EXIT                                               - internal
FC "C:\Windows\System32\fc.exe"  
FIND "C:\Windows\System32\find.exe"  
FINDSTR "C:\Windows\System32\findstr.exe"  
FOR                                                - internal
FORMAT "C:\Windows\System32\format.com"  
FSUTIL "C:\Windows\System32\fsutil.exe"  
FTYPE                                              - internal
GOTO                                               - internal
GPRESULT "C:\Windows\System32\gpresult.exe"  
GRAFTABL                                           - internal
HELP "C:\Windows\System32\help.exe"  
ICACLS "C:\Windows\System32\icacls.exe"  
IF                                                 - internal
LABEL "C:\Windows\System32\label.exe"  
MD                                                 - internal
MKDIR                                              - internal
MKLINK                                             - internal
MODE "C:\Windows\System32\mode.com"  
MORE "C:\Windows\System32\more.com"  
MOVE                                               - internal
OPENFILES "C:\Windows\System32\openfiles.exe"  
PATH                                               - internal
PAUSE                                              - internal
POPD                                               - internal
PRINT "C:\Windows\System32\print.exe"  
PROMPT                                             - internal
PUSHD                                              - internal
RD                                                 - internal
RECOVER "C:\Windows\System32\recover.exe"  
REM                                                - internal
REN                                                - internal
RENAME                                             - internal
REPLACE "C:\Windows\System32\replace.exe"  
RMDIR                                              - internal
ROBOCOPY "C:\Windows\System32\Robocopy.exe"  
SET                                                - internal
SETLOCAL                                           - internal
SC "C:\Windows\System32\sc.exe"  
SCHTASKS "C:\Windows\System32\schtasks.exe"  
SHIFT                                              - internal
SHUTDOWN "C:\Windows\System32\shutdown.exe"  
SORT "C:\Windows\System32\sort.exe"  
START                                              - internal
SUBST "C:\Windows\System32\subst.exe"  
SYSTEMINFO "C:\Windows\System32\systeminfo.exe"  
TASKLIST "C:\Windows\System32\tasklist.exe"  
TASKKILL "C:\Windows\System32\taskkill.exe"  
TIME                                               - internal
TITLE                                              - internal
TREE "C:\Windows\System32\tree.com"  
TYPE                                               - internal
VER                                                - internal
VERIFY                                             - internal
VOL                                                - internal
XCOPY "C:\Windows\System32\xcopy.exe"  
WMIC "C:\Windows\System32\wbem\WMIC.exe"  

internal 45
external 39
Drücken Sie eine beliebige Taste . . .

Steffen

Nicht jedes Wort auf die Goldwaage legen. Das war ironisch gemeint.

lks

Joa, macht ja nix wenn ich da und dort noch mal etwas konkreter werde

Und wenn noch jemandem Fragen im Kopf rum schwirren, à la "Wie isser denn zu der Erkenntnis gekommen?" oder "Gibt's da auch mal ein Beispiel?", dann immer raus damit.

Steffen

Moin Steffen,

* PowerShell Code in der CMD auszuführen kann man machen. Aber die PowerShell braucht wirklich verhältnismäßig lang für das Startup. Macht man so etwas häufiger in einem Batchscript, muss man sich nicht wundern warum die Laufzeit in die Höhe geht. Dieses Startup Delay hat man zwar auch wenn man eine .ps1 ausführt, dann aber nur einmal.

Im umgekehrten Fall: CMD Befehl ist nicht gleich CMD Befehl. Ein Teil davon sind interne Funktionen der cmd.exe. Die PowerShell hat oft gleichnamige Aliase für CmdLets. Die zu verwenden ist in Ordnung. Daneben gibt es die externen Tools. Die in der PowerShell zu nutzen bedeutet immer, dass das OS einen neuen Prozess eintakten und erzeugen muss. Passiert so etwas in einer Schleife, wirst du einen deutlichen Performance Drop feststellen.

nicht bei jedem Script geht es um Performance, manche müssen auch nur einmalig Ihren Zweck erfüllen. 😉
Aber stimmt schon, CMD's in Power-Shell zu benutzen ist etwas zäh ... aber es geht.

Beste Grüsse aus BaWü
Alex

Hallo,

man braucht auch kein Visual Studio. VS Code reicht. Damit lassen sich einfach DLLs ebinden und den PS Fuktionsumfang unbegrenzt erweitern: Barcode Leser etc.

using namespace System.Drawing;
Add-Type -AssemblyName System.Drawing;

[void] [Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms")  

$testBild = "C:\temp\code_ls4.png-2.png"  
$src=[System.Drawing.Image]::FromFile($testBild)

$rect = New-Object System.Drawing.Rectangle(740,1500,400,250) # top, left, width, height of slice
$slice = $src.Clone($rect, $src.PixelFormat);
#$slice.Save("c:\temp\test_slice.png", "png"); 

$src = $slice;

[void] [System.Reflection.Assembly]::LoadFrom("c:\temp\BarcodeImaging.dll");      
$barcodes = @{}
[BarcodeImaging]::FullScanPage([ref] $barcodes, $src, 150)

$barcodes

Hier wäre also nur folgende Zeile:

[void] [System.Reflection.Assembly]::LoadFrom("c:\temp\BarcodeImaging.dll");

Und wo wir bei VScode schon sind: Powershell Debuggon. Statt "print", "echo" etc. einfach Breakpoint setzen. Auch ein Pluspunkt für die PS.

mfg Crusher

Moinsens,

und was mir grade auffällt. Microsoft PowerShell (v5.1.19041.1682) und PowerShell Core (v7.2.5) sind nicht ganz kompatibel zueinander. Oder übersehe ich etwas?

Starte man MS PowerShell, welche beim Betriebssystem mitgeliefert wird, erscheint der Hinweis man möge das neue plattformübergreifende PowerShell kennenlernen.

Okay. Zum einen ist die neue Version mittlerweile v7.2.6.

Das Cmdlet "Get-EventLog" existiert aber in der PowerShell v7.2.6 nicht. Warum nicht? Sind evtl. weitere Cmdlets, die NICHT im PowerShell Core vorhanden sind? heißt das im Endeffekt, daß man PowerShell v5,1 verwendet soll und nicht v7.2?

Das ist wieder etwas was mich stört ober besser gesagt aufregt. Das ist wieder Inskonstistenz.

Gruss Penny.

Zitat von @Penny.Cilin:

Das Cmdlet "Get-EventLog" existiert aber in der PowerShell v7.2.6 nicht. Warum nicht? Sind evtl. weitere Cmdlets, die NICHT im PowerShell Core vorhanden sind? heißt das im Endeffekt, daß man PowerShell v5,1 verwendet soll und nicht v7.2?

Das ist wieder etwas was mich stört ober besser gesagt aufregt. Das ist wieder Inskonstistenz.

Da merkt man, dass es sich von der Plattform an sich gelöst hat. Die eine Hand weiß nicht was die andere tut.

https://docs.microsoft.com/de-de/powershell/scripting/whats-new/differen ...

Wegen den OpenSource Ansatz ist die 7.2 zu bevorzugen.

https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell. ...

Vermutlich weil Linux auch "Events" hat. Ka. Nervig auf jedenfall.

@Crusher79

Zitat von @Crusher79:
man braucht auch kein Visual Studio. VS Code reicht.

Du hast mich da gerade etwas abgehängt, denn
1. In welcher Weise spricht das für oder gegen Batch/PowerShell?
2. Um Code zu schreiben, braucht man lediglich irgendeinen Texteditor. Egal für welche Sprache, das ist nicht einmal auf Scriptsprachen beschränkt. Natürlich hilft zumindest ein Syntaxhighlighting. Und da und dort ist auch ein Intellisense recht hilfreich. Aber nötig ist das für keine Sprache. Und die Tatsache, dass man Plattform- oder 3rd Party Bibliotheken einbinden kann, hat nun rein gar nichts mit dem verwendeten Editor zu tun.

Steffen

bei PowerShell kann man davon ausgehen, dass es ein oder mehrere Windows Updates überlebt und dann auch noch funktioniert ohne angepasst werden zu müssen.
panoramacharter.ltd
19216811.bid

Tipp Batch, Shell Entwicklung

Mehr von rubberman

CodeBlocks Portable mit MinGW 32 und 64 Bit unter Windowsrubberman - 1 Kommentar

Nicht alle Threads unter Schwerpunkt Hashtags?rubberman - 6 Kommentare

Code-Einrückungen werden geschlucktrubberman - 4 Kommentare

Wo isser eigentlich abgeblieben?rubberman - 17 Kommentare

Heiß diskutiert

WINDOWS 11 - Grottige PerformanceMysticFoxDE - 40 Kommentare