Dlaczego powłoka cmd.exe w systemie Windows kończy się niepowodzeniem ze ścieżkami za pomocą separatora ścieżek typu „ukośnik w przód” („/”)?
Kiedy pomyślałem, że widziałem to wszystko w przypadku problemów ze ścieżką systemu Windows, natknąłem się na przypadek, który kończy się niepowodzeniem tylko wtedy, gdy jako separator ścieżki używany jest znak „/” (ukośnik):
<code>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. </code>
Szczególnie interesujące jest to, że wydaje się być specyficzne dla powłoki cmd.exe i nie występuje w PowerShell (ani prawdopodobnie w API win32):
<code>PS C:\temp\tcbugs> type 'dir1 with spaces/foo.txt' hi </code>
Innym interesującym aspektem jest to, że zmiana katalogów za pomocą „cd” i użycie „/” jako separatora ścieżek w cmd.exe działa:
<code>C:\temp\tcbugs>mkdir dir2_no_spaces C:\temp\tcbugs>cd ./dir2_no_spaces C:\temp\tcbugs\dir2_no_spaces>cd .. </code>
Jednak nie mogę znaleźć żadnego odniesienia do tego konkretnego problemu w Internecie ani w powszechnie cytowanej dokumentacji MSDN:
Nazwy plików, ścieżki, przestrzenie nazw
Co prowadzi mnie do pytania: dlaczego tak się dzieje i czy istnieje ostateczne źródło, które dokumentuje to dziwactwo?
AKTUALIZACJA:
dbenham wskazuje, że problem występuje niezależnie od tego, czy spacje są w nazwie katalogu, więc usunięto odniesienie do niego w treści tytułu i treści pytania. Dodano także przykład „cd ./”, który działa, podczas gdy inne nie.