Warum hat die cmd.exe -shell auf einem Windows-Fehler mit Pfade mit einem Schrägstrich ('/") Pfad-separator?

Nur, wenn ich dachte, ich hätte alles gesehen, mit Windows-Pfad-Probleme, ich habe mir heute begegnet einem Fall, nur nicht, wenn '/' (Schrägstrich) als Pfad-Trennzeichen verwendet wird:

C:\temp\tcbugs>mkdir "dir1 with spaces"

C:\temp\tcbugs>echo hi > "dir1 with spaces"\foo.txt

C:\temp\tcbugs>type "dir1 with spaces\foo.txt"
hi

C:\temp\tcbugs>type "dir1 with spaces/foo.txt"
The system cannot find the file specified.

Was ist besonders interessant daran ist, dass es scheint, die speziell für die cmd.exe shell und kommt nicht in PowerShell (noch vermutlich in der win32-API):

PS C:\temp\tcbugs> type 'dir1 with spaces/foo.txt'
hi

Weiterer Punkt von Interesse ist, dass Verzeichniswechsel mit 'cd' und mit '/' als Pfadtrenner mit cmd.exe funktioniert:

C:\temp\tcbugs>mkdir dir2_no_spaces

C:\temp\tcbugs>cd ./dir2_no_spaces

C:\temp\tcbugs\dir2_no_spaces>cd ..

Doch, ich kann nicht finden jede Bezugnahme auf dieses problem überall online, noch in der MSDN die häufigsten zitierte Dokumentation:

Naming Files, Paths, Namespaces

Das führt mich zu der Frage: warum passiert das, und gibt es eine eindeutige Quelle, die Dokumente, die diese Marotte?

UPDATE:

dbenham weist darauf hin, dass das problem vorhanden ist, unabhängig davon, ob Leerzeichen im Verzeichnis-Namen, so entfernt Verweis auf das in Titel und Frage Körper. Auch Hinzugefügt ein Beispiel für 'cd ./' das funktioniert, während andere Befehle nicht.

/ können verwendet werden als Pfad-separator auf API-Ebene, aber Sie sind nicht Aufruf der API direkt. Sie sind mit cmd.exe und cmd.exe analysiert die / als Kommandozeilen-option.
Ich vermutete, so viel, aber auch erwartet, etwas über diesen Fall würde irgendwo dokumentiert sein speziell. Die Unterlagen, die ich gefunden habe, Abdeckung Pfad-Separatoren-auch im Rahmen der cmd-shell--nicht erwähnen, dieses Besondere Problem, so weit ich erzählen kann.
Wo ist die Dokumentation, die sagt slash kann verwendet werden als Pfad-Trennzeichen in cmd.exe?
Die Räume haben nichts mit dem problem zu tun. Auch wenn die Ordner keine Leerzeichen im Namen, der Schrägstrich funktioniert immer noch nicht.
Raymond-Wenn ich jetzt gerade nicht wirklich etwas sehen, erwähnt cmd.exe ausdrücklich zu.

InformationsquelleAutor Garen | 2012-05-09

  1. 9

    Bearbeitet zu entfernen Stellungnahme

    Ob oder ob nicht Windows CMD.EXE unterstützen soll, Schrägstriche in den Pfaden, die Tatsache ist, manchmal funktioniert es, manchmal nicht, und manchmal scheint es zu funktionieren, aber gibt das falsche Ergebnis - AKA einen Fehler.

    Ist es Zeit für einige Experimente 🙂

    Waren alle tests laufen auf Vista

    C:\>md "c:/temp/"

C:\>REM The forward slash works with MD!

C:\>echo hello world 1>>"c:/temp/test.txt"

C:\>REM Redirection works with forward slashes!

C:\>type "c:\temp\test.txt"
hello world

C:\>REM Of course TYPE works with back slashes

C:\>type "c:/temp/test.txt"
The system cannot find the file specified.

C:\>REM But forward slash version fails

C:\>type "c:/temp\test.txt"
hello world

C:\>REM But TYPE works with forward slash as long as last slash is back slash

C:\>dir "c:/temp/test.txt"
 Volume in drive C is OS
 Volume Serial Number is EE2C-5A11

 Directory of c:\temp

File Not Found

C:\>REM Note how DIR lists the directory with a \, yet fails to find any files

C:\>dir "c:/temp/*"
 Volume in drive C is OS
 Volume Serial Number is EE2C-5A11

 Directory of c:\temp

File Not Found

C:\>REM DIR Still fails with forward slashes

C:\>dir "c:/temp/"
 Volume in drive C is OS
 Volume Serial Number is EE2C-5A11

 Directory of c:\temp

05/09/2012  09:58 PM    <DIR>          .
05/09/2012  09:58 PM    <DIR>          ..
05/09/2012  09:58 PM                13 test.txt
               1 File(s)             13 bytes
               2 Dir(s)  337,001,615,360 bytes free

C:\>REM But forward slash works if no file is specified!

C:\>dir "c:/temp\test.txt"
 Volume in drive C is OS
 Volume Serial Number is EE2C-5A11

 Directory of c:\temp

05/09/2012  09:58 PM                13 test.txt
               1 File(s)             13 bytes
               0 Dir(s)  337,001,615,360 bytes free

C:\>REM And DIR works with forward slash as long as last slash is back slash


C:\>REM Now add another folder to the path hierarchy

C:\>md "c:/temp/temp/"

C:\>REM Still can create folder using forward slashes

C:\>copy "c:/temp/test.txt" "c:/temp/temp/"
The system cannot find the file specified.
        0 file(s) copied.

C:\>REM Failed to copy with forward slashes

C:\>copy "c:/temp\test.txt" "c:/temp/temp/"
        1 file(s) copied.

C:\>REM But forward slash works if last slash before file name is back slash


C:\>REM Rerun some past tests

C:\>type "c:/temp/test.txt"
The system cannot find the file specified.

C:\>REM Good - it still fails

C:\>dir "c:/temp/test.txt"
 Volume in drive C is OS
 Volume Serial Number is EE2C-5A11

 Directory of c:\temp

05/09/2012  09:58 PM                13 test.txt
               1 File(s)             13 bytes
               0 Dir(s)  337,001,615,360 bytes free

C:\>REM What is going on?! :( Why did that seem to work now?
C:\>REM More on that later.


C:\>REM Now test the new folder

C:\>type "c:/temp/temp/test.txt"
The system cannot find the file specified.

C:\>REM Forward slashes still fail with TYPE

C:\>type "c:/temp/temp\test.txt"
hello world

C:\>REM But forward slash still works as long as last slash is back slash

C:\>dir "c:/temp/temp/*"
 Volume in drive C is OS
 Volume Serial Number is EE2C-5A11

 Directory of c:\temp\temp

File Not Found

C:\>REM Again, forward slashes fail, but directory path is listed properly

C:\>dir "c:/temp/temp/"
 Volume in drive C is OS
 Volume Serial Number is EE2C-5A11

 Directory of c:\temp\temp

05/09/2012  09:58 PM    <DIR>          .
05/09/2012  09:58 PM    <DIR>          ..
05/09/2012  09:58 PM                13 test.txt
               1 File(s)             13 bytes
               2 Dir(s)  337,001,615,360 bytes free

C:\>REM And again it works if no file is specified

C:\>dir "c:/temp/temp\test.txt"
 Volume in drive C is OS
 Volume Serial Number is EE2C-5A11

 Directory of c:\temp\temp

05/09/2012  09:58 PM                13 test.txt
               1 File(s)             13 bytes
               0 Dir(s)  337,001,615,360 bytes free

C:\>REM Again forward slashes work as long as last slash is back slash

    Hier ist ein Fall, der deutlich zeigt, ein Fehler.

    c:\>dir /s /a-d temp
 Volume in drive C is OS
 Volume Serial Number is EE2C-5A11

 Directory of c:\temp

05/10/2012  08:01 AM                13 test.txt
               1 File(s)             13 bytes

 Directory of c:\temp\temp

05/10/2012  07:57 AM                10 test.txt
               1 File(s)             10 bytes

     Total Files Listed:
               2 File(s)             23 bytes
               0 Dir(s)  337,325,191,168 bytes free

c:\>REM Note the different file sizes found in each directory

c:\>dir "c:/temp/test.txt"
 Volume in drive C is OS
 Volume Serial Number is EE2C-5A11

 Directory of c:\temp

05/10/2012  07:57 AM                10 test.txt
               1 File(s)             10 bytes
               0 Dir(s)  337,325,191,168 bytes free

c:\>REM It is listing the wrong file!

    Kann man darüber diskutieren, ob die Windows-CMD ist "angeblich" zu unterstützen Schrägstriche. Aber das Letzte Ergebnis ist ein bug! Auch wenn es ist operator Fehler mit einem Schrägstrich, sollte Windows nicht geben, das Ergebnis.

    +1 für das interessante experiment!
    Was ist Ihre Grundlage für die Beschreibung das Verhalten als bug? (Raymond Chen gebeten, die oben, wo ist die Dokumentation, die besagt, dass cmd annehmen sollte, Schrägstriche als Trennzeichen für Pfade?) Und als Larry Osterman erwähnt, die Herkunft der Verwendung der Schrägstrich als die option Trennzeichen möglicherweise nicht sogar sein, dass Microsoft da tut. Würden Sie beschreiben, wie ein "bug" das Verhalten der Unix-tradition-Befehle, die nicht umgehen können mit dem Datei-Namen beginnen mit - ohne Besondere Anordnung?
    Ich halte es für einen bug (oder Designfehler), wenn ein system gibt inkonsistente Ergebnisse. Ich wäre vollkommen glücklich, wenn CMD arbeitete mit Schrägstrich im Wege oder nicht, aber manchmal funktioniert und manchmal nicht ist ein Fehler in meinem Buch. Und zu meinem letzten Beispiel in der bearbeiteten Antwort zeigt deutlich ein Problem, durch jede vernünftige definition von "Fehler" ist, dass ich mir denken kann. Ich habe entfernt die Stellungnahme der Antwort und hielt sich an die Fakten. Aber in diesem Kommentar werde ich sagen: "ich glaube, dass MS versucht, Unterstützung forward-slashes in Pfaden und endete mit einem buggy undokumentierte Funktion".
    Ich bin fast sicher, MS hat nicht versucht zu unterstützen Schrägstriche in cmd. Sie (absichtlich) unterstützen Sie in der API, aber in cmd es passiert einfach zu arbeiten, wenn der text nur an, um API und nicht, wenn es geparst wird. Der Unterschied zwischen md und type sowohl als built-in-Kommandos, ist wirklich neugierig.
    Ich nehme an, dass die Entwickler von cmd gewesen sein könnte naiv an die API ' s interpretation von /, aber ich bezweifle es. So oder so, Sie sollte bekannt war und entsprechend gestaltet. Es sollte eine bewusste Entscheidung, um entweder unterstützen / als Pfad-Trennzeichen in allen internen Kommando-Situationen, oder aber deaktivieren Sie es in allen Fällen. Das ist meine Meinung trotzdem. 🙂 Oder zumindest dokumentieren, dass / ist unzuverlässig als Pfad-Trennzeichen und sollte daher vermieden werden.

    InformationsquelleAutor dbenham

  2. -1

    Wie hatten ein seltsames Verhalten mit slash und wir verfolgt es, bis auf die Tatsache, dass ein Pfad mit einem führenden Schrägstrich gesehen ist nicht als ein absoluter Pfad, also 

    C:\>cd /temp

C:\temp>rem works we are in the root directory

C:\temp>cd /temp
Das System kann den angegebenen Pfad nicht finden.

C:\temp>rem does't work but

C:\temp>cd \temp

C:\temp>rem \ indicates absolute path

C:\temp>cd ..

C:\>cd /temp

C:\temp> cd /ca

C:\temp\CA>rem qed

    Vielleicht erklärt auch die Fehler, die oben angeführt - ich bin nicht klar, auf welches Verzeichnis die Befehle ausgeführt werden.

    Nette Theorie, aber auf meinem Windows 7-Maschine, die ich ein anderes Verhalten. cd /temp funktioniert gut für mich, behandeln Sie es als root-Ordner. Aber die anderen Fehler, die ich Liste in meinem post sind immer noch gültig.
    Dies sind interessante Beispiele, aber Sie nicht einmal ansatzweise die Frage des "warum".

    InformationsquelleAutor Martin Althaus

  3. -6

    Ich bin nicht sicher, warum das '/' ist die Arbeit in PS. Zurück zu der Geschichte, DOS-basiert auf UNIX und es ist eine kleine Gruppe von UNIX. In der UNIX-Pfadtrenner '/', während in DOS ist es '\'. Ich arbeitete auf einigen Windows-und DOS-apps vor. Um zu konvertieren, einige UNIX-Muster wie Befehle oder Pfad und stellen Sie sicher, dass Sie gültige DOS-Befehl oder Pfad, schrieb ich einen kleinen Konverter zu verwandeln,'/', ' \ " wie diese:

    string fileNameFromWeb;
...
string windowsFile = fileNameFromWeb.repleace("/", @"\");

    Können Sie dieses feature hinzufügen zu tolerant '/' in Ihrem app-im Fall der Zugriff auf Dateien in Windows. Ich denke, PS kann diese Art Konverter zu ermöglichen Befehl oder der Pfad mit '/' oder '\', oder Windows wird mit einem '/' im Dateinamen.

    Danke, aber was ursprünglich führte mich zu diesem problem war ein bug in einige Drittanbieter-software-so dass, die option ist nicht verfügbar für mich. Natürlich wäre es meine software, die ich würde haben Sie einfach so gemacht, und nicht die Mühe gemacht, diese Frage zu stellen.
    Wenn Sie verwenden .NET oder Mono, die Sie verwenden können, Weg.DirectorySeparator statt hart zu codieren. msdn.microsoft.com/en-us/library/...
    -1 tut mir Leid, aber "DOS-basiert auf UNIX und es ist eine kleine Gruppe von UNIX.", das hat die die größte Gotteslästerung überhaupt!!! Tatsächlich, DOS war etwas basierend auf CP/M.
    Es funktioniert in PS, weil Sie die parsing-Regeln sind anders, und wenn der string wird unverändert an die API, es funktioniert.
    Wenn Sie verwenden .NET oder Mono-oder C++ oder nichts, können Sie immer verwenden /. cmd.exe ist die nur (oder zumindest habe ich nie header von allen anderen) Teil von Windows, wo die Schrägstriche nicht funktionieren.

    InformationsquelleAutor David.Chu.ca

Schreibe einen Kommentar