Pfade mit Leerzeichen und Sonderzeichen in bash, zsh, PowerShell und cmd

Worum es geht

Ein Dateiname mit Leerzeichen, einem Glob-Zeichen (*, ?, [), einem führenden Bindestrich oder einem Shell-Metazeichen (&, ;, Backtick) ist auf jedem Dateisystem, das diese Serie behandelt, normal und zulässig. Jede Skriptumgebung verarbeitet ihn jedoch auf ihre eigene, fehleranfällige Weise.

Warum es wichtig ist

• bash und zsh: In bash unterliegen ein nicht gequotetes $var und eine nicht gequotete Befehlssubstitution der Wortaufspaltung (Word Splitting) und der Dateinamenexpansion. Das Kapitel „Quoting“ im GNU-Bash-Handbuch definiert Quoting als den Mechanismus, der diese Sonderbedeutung aufhebt. rm $file wird stillschweigend zu mehreren Argumenten, wenn $file ein Leerzeichen enthält; "$file" dagegen nicht. zsh spaltet ein nicht gequotetes $var standardmässig nicht auf, spaltet aber nicht gequotetes $(...) weiterhin auf und verwirft leere, nicht gequotete Werte. Auch dort ist daher Quoting nötig. Bash-Arrays ("${arr[@]}") sind der richtige Weg, eine Argumentliste aufzubauen, ohne auf einen einzelnen String zurückzufallen.
• PowerShell: -Path-Parameter akzeptieren Wildcards, sodass ein literaler Dateiname mit [ oder ] fälschlich als Muster gelesen werden kann. Get-ChildItem dokumentiert -LiteralPath als Parameter, dessen Wert "is used exactly as it's typed" und bei dem "no characters are interpreted as wildcards". Er ist immer dann zu verwenden, wenn der Pfad aus Daten stammt und nicht aus einem Muster, das der Aufrufer beabsichtigt hat. about_Quoting_Rules beschreibt, wann einfache oder doppelte Anführungszeichen für die Variablenexpansion innerhalb des Pfad-Strings selbst relevant sind.
• cmd.exe: Argumente mit Leerzeichen müssen in doppelte Anführungszeichen gesetzt werden, und ein Pfad, der mit / oder - beginnt, kann von manchen Tools als Schalter missverstanden werden. Nicht gequotete, zusammengesetzte Pfade in Batch-Code reproduzieren den Fehler der nicht gequoteten Variable.
• find und xargs: Dateinamen dürfen Zeilenumbrüche enthalten, was die standardmässige zeilenbasierte Übergabe zwischen den beiden Tools bricht. find(1) dokumentiert -print0 so, dass der vollständige Pfad gefolgt von einem Null-Zeichen statt eines Zeilenumbruchs ausgegeben wird; xargs(1) dokumentiert seinen Null-getrennten Eingabemodus (-0/--null) so, dass ein Null-Zeichen statt beliebigen Leerraums als Trenner zwischen den Elementen gelesen wird. Die Kombination find ... -print0 | xargs -0 ... übersteht wie find ... -exec cmd {} + jeden zulässigen Dateinamen, auch solche mit eingebetteten Zeilenumbrüchen.

So wird es angewendet

• In bash/zsh jede Variablenexpansion und jede Befehlssubstitution quoten ("$var", "$(cmd)"), Arrays der String-Verkettung vorziehen und vor Dateioperanden -- setzen (rm -- "$f") oder ./ voranstellen, damit ein führender Bindestrich nicht als Option gelesen wird.
• In PowerShell-Cmdlets -LiteralPath verwenden, sobald der Pfadwert aus einer Variable, einer Dateiliste oder einer Benutzer- bzw. Agenteneingabe stammt und nicht aus einem selbst geschriebenen Muster.
• Jeden in einer Batch-Datei zusammengesetzten Pfad quoten und für Skripte, die unvorhersehbare Dateinamen unter Windows verarbeiten müssen, PowerShell bevorzugen.
• Wenn die Dateimenge nicht vollständig kontrolliert ist, standardmässig find ... -print0 | xargs -0 (oder find ... -exec cmd {} +) statt einer zeilenbasierten find | xargs-Pipeline verwenden.

Stolpersteine

• Nur mit Dateinamen ohne Leerzeichen testen und den Quoting-Fehler erst später an echten Daten bemerken.
• -LiteralPath in einem Cmdlet einer Pipeline und -Path im nächsten verwenden, sodass die Wildcard-Auswertung weiter unten wieder auftritt.
• Annehmen, dass -print0/-0 überall vorhanden sind: GNU, die BSDs und macOS kennen sie seit langem, in POSIX kamen sie aber erst mit der Ausgabe von 2024 hinzu. Auf älteren oder minimalen Systemen ist daher -exec ... {} + zu verwenden.