31.10.2020, aktualisiert um 15:58:24 Uhr

7004

Eckige Klammern in Dateien und Powershell verweigert leider die Bearbeitung

Es gibt bereits zahlreiche Fragen und Antworten im Forum zu diesen Thema, aber ich möchte es gern nochmal aufgreifen:

Ich habe diese simple Zeile:

Rename-Item "[test]" -NewName "d"  

und möchte lediglich die Klammern richtig maskieren.
Die Dateiendungen spielen in diesen Beispielen keine Rolle.

Das funktioniert zwar:

Rename-Item -LiteralPath Z:\3\[test].txt -NewName Z:\3\d.txt

würde aber nicht meine Frage beantworten.

Dieser Versuch bringt leider auch nichts:

$maskieren = '[test]'  
$maskieren = $maskieren -replace [regex]::escape('\[');  
$maskieren = $maskieren -replace [regex]::escape(']\');  
-> Keine Funktion

auch diese nichts (hätte ja sein können):

Rename-Item "\[test\]" -NewName "d"  
Rename-Item "`[test`]" -NewName "d"  
Rename-Item "\[\test\]\" -NewName "d"  
Rename-Item `[`test`]` -NewName 'd'  
Rename-Item `[test`] -NewName 'd'  
Rename-Item '[test]' -NewName 'd'  

Die Datei ist natürlich vorhanden, und das richtige Verzeichnis wurde auch ausgewählt.
Ohne Klammern funktioniert das einwandfrei.

Weiß jemand bitte wie die richtige Maskierung aussehen muss, und kann das vielleicht
mitteilen?

Ich weiß das man Klammern möglichst vermeiden soll, aber das ist eine andere Sache.

Danke.

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

Content-ID: 618004

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

Ausgedruckt am: 22.11.2024 um 04:11 Uhr

10 Kommentare

Neuester Kommentar

In den meisten "-Path" Parametern wird sogenanntes Shell-Globbing vorgenommen und da gehören die eckigen Klammern unter anderem zu den Wildcard Patterns um z.B. einen Bereich von Ziffern/Buchstaben zu definieren [a-z] oder [0-9] usw..

Siehe dazu
https://en.m.wikipedia.org/wiki/Glob_(programming)

In deinem Fall bedeutet das [Test] das an der Position einer der Buchstaben aus der Liste T e s an dieser Stelle stehen darf.

Ein Escaping dieser (was man in der PS übrigens mit Backtick macht) geht auf der Konsole indem man doppelte Backticks verwendet

"``[Test``]"

Siehe https://docs.microsoft.com/en-us/powershell/scripting/developer/cmdlet/s ...

Handling Literal Characters in Wildcard Patterns
If the wildcard pattern you specify contains literal characters that should not be interpretted as wildcard characters, use the backtick character (`) as an escape character. When you specify literal characters int the PowerShell API, use a single backtick. When you specify literal characters at the PowerShell command prompt, use two backticks.

For example, the following pattern contains two brackets that must be taken literally.

When used in the PowerShell API use:

"John Smith `[*`]"  
When used from the PowerShell command prompt:

"John Smith ``[*``]"  
This pattern matches "John Smith [Marketing]" or "John Smith [Development]".   

Bei Verwendung von LiteralPath dagegen werden diese Sonderzeichen nicht vorher "geparsed" und der String so wie er ist übernommen, ohne irgendwelches Globbing.

Deswegen ist es auch guter Powershell Stil immer -LiteralPath zu verwenden sofern man vorher nicht weiß ob solche Zeichen im Pfad Verwendung finden!

Hth
Gruß w.

Zitat von @146189:

Danke für die ausführliche Erklärung!

Deswegen ist es auch guter Powershell Stil immer -LiteralPath zu verwenden sofern man vorher nicht weiß ob solche Zeichen im Pfad Verwendung finden!

Ja. Diese Meinung teile ich.

> "``[Test``]"  
Ich habe das getestet, und ich hätte auch wirklich gedacht das es nun funktioniert.
Aber dies ist nicht der Fall.
 

Ergebnis:

$PSVersionTable.PSVersion
Major  Minor  Build  Revision
-----  -----  -----  --------
5      1      19041  1


Rename-Item "``[Test.txt``]" -NewName "d.txt"  
Rename-Item : Das Umbenennen ist nicht möglich, da das Element unter "`[Test.txt`]" nicht vorhanden ist.  
In Zeile:1 Zeichen:1
+ Rename-Item "``[Test.txt``]" -NewName "d.txt"  
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [Rename-Item], PSInvalidOperationException
    + FullyQualifiedErrorId : InvalidOperation,Microsoft.PowerShell.Commands.RenameItemCommand


Rename-Item "`[Test.txt`]" -NewName "d.txt"  
Rename-Item : Das Umbenennen ist nicht möglich, da das Element unter "[Test.txt]" nicht vorhanden ist.  
In Zeile:1 Zeichen:1
+ Rename-Item "`[Test.txt`]" -NewName "d.txt"  
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [Rename-Item], PSInvalidOperationException
    + FullyQualifiedErrorId : InvalidOperation,Microsoft.PowerShell.Commands.RenameItemCommand

Seltsam. Das Problem ist nur bei den eckigen Klammern.
Verschiedene Schreibweisen der Dateien getestet, mit oder ohne Dateiendungen.
Funktioniert einfach nicht.

Geht doch, guckst du
https://tio.run/##K8gvTy0qzkjNyfn/vyS/NDlDQT26JLW4JFavpKJEnSunmEtJFwaUuI ...
Du hast wohl einen Tippfehler in deinem Datenamen oder befindest dich im falschen Verzeichnis ...

Zitat von @146189:

Geht doch, guckst du
Du hast wohl einen Tippfehler in deinem Datenamen oder befindest dich im falschen Verzeichnis ...

???? - Die Powershell wird in dem Verzeichnis aufgerufen, wo die Datei sich befindet.
Und das kommt dabei heraus:

rename-item "`[test`].txt" -NewName blablub.txt  
rename-item : Das Umbenennen ist nicht möglich, da das Element unter "[test].txt" nicht vorhanden ist.  
In Zeile:1 Zeichen:1
+ rename-item "`[test`].txt" -NewName blablub.txt  
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [Rename-Item], PSInvalidOperationException
    + FullyQualifiedErrorId : InvalidOperation,Microsoft.PowerShell.Commands.RenameItemCommand

Warum funktioniert das mit Linux und nicht mit Windows?

Zitat von @AN34Mem:
Warum funktioniert das mit Linux und nicht mit Windows?

Geht auch unter Windows, hier getestet ...
Du zeigst uns ja gar nicht was tatsächlich in deinem Ordner so liegt, da kannst du uns also viel erzählen wenn der Tag lang ist 😜.
Aber wie schon gesagt bei unbekannten Variableninhalten
und den Filesystem CMDLets immer -LiteralPath verwenden! Dann brauchst du das hier erst gar nicht und fang bloß nicht mit irgendwelchen Replacements an das ist Bullshit.
Die Erklärungen dazu findest du ausführlich oben.

Zitat von @146189:

Zitat von @AN34Mem:
Warum funktioniert das mit Linux und nicht mit Windows?

Geht auch unter Windows, hier getestet ...

Unter Windows 3.1?
Ich kann nur sagen, dass die Meldungen unter Win 10, 20H2 (clean - scheint aber betrunken zu sein) auftreten.
Vielleicht fehlt einfach H²O.

Du zeigst uns ja gar nicht was tatsächlich in deinem Ordner so liegt, da kannst du uns also viel erzählen wenn der Tag lang ist 😜.

Da haben schon ganz andere Leute einen Blick drauf 😜, aber die Hüllen sich in Schweigen.

Aber wie schon gesagt bei unbekannten Variableninhalten
und den Filesystem CMDLets immer -LiteralPath verwenden! Dann brauchst du das hier erst gar nicht und fang bloß nicht mit irgendwelchen Replacements an das ist Bullshit.
Die Erklärungen dazu findest du ausführlich oben.

Vielleicht kommt mir die Lösung im Traum, und Bill erzählt mir was.

Danke für dein Test!

PowerShell 5.1 (aka Windows PowerShell) vs. PowerShell 7.1 (aka PowerShell Core)?
Mit v5 funktioniert das bei mir auch nicht

Steffen

Zitat von @rubberman:

Mit v5 funktioniert das bei mir auch nicht

Danke für deine Rückmeldung.

Ich habe das heute nochmals mehrfach getestet.
Es geht unter v5 (zumindest auch bei mir definitiv) nicht.

Ich habe etwas mehr Hoffnung in v7.1 gesetzt, jedoch treten dann an andere Stelle zusätzliche Fehler auf,
die zumindest nicht unter v5 aufgetreten sind. Auch damit hat es nicht geklappt.
Ganz TOLLES - [POWER] [SHELL] Flickwerk!

Habe das o.g.n. Thema jetzt abgeschlossen.

Hallo,

habe unter PS 5.1.19041.546 unter Win10 auch keine Möglichkeit gefunden, die Datei "[foo].txt" über Rename-Item <Dateiname> umzubennen. Workaround nur über LiteralPath.
Böse.

Grüße

Filipp

Zitat von @filippg:

Workaround nur über LiteralPath.

Da ist kein Workaround sondern wir oben schon mehrfach erwähnt guter Powershell Stil und sollte man immer verwenden sofern der Parameter vorhanden ist weiß anscheinend nur kaum einer, steht aber überall ...

Böse.

Nö, gut so, die Verwendung von LiteralPath sollte eigentlich Standard sein.

Und falls Ihr immer noch nicht glaubt das es auch mit der PS 5.1 geht hier bitte der Beweis das es auch ohne LiteralPath geht