Как отмечают некоторые другие ответы / комментарии, идея о том, что после команды должен быть пробел, неверна. Хорошо известным примером является то, что вы можете вводить косую черту после команды, не используя пробел.
Тем не менее, есть другое поведение, которое немного менее понятно, и допускает " cd..", о котором вы спрашиваете. Такое поведение также позволяет " cd\" работать.
Поведение, которое вы описываете, является совместимым для всех команд, встроенных в интерпретатор командной строки. Если у вас есть определенные символы, включая точку, косую черту или обратную косую черту, то проверяются предыдущие символы, чтобы определить, являются ли они командой, которая является внутренней для оболочки «интерпретатора командной строки» (CMD.EXE или его предшественника COMMAND.COM ).
Это может быть сделано перед проверкой, может ли слово относиться к файлу или подкаталогу. Это верно для cdкоманды. К сожалению, при создании образца я обнаружил, что с copyкомандой этого не происходит , поэтому результаты не всегда совпадают: они не обязательно совпадают со всеми внутренними командами. Я не продолжил свой поиск, чтобы также сравнить (много) другие командные строки, delи dirпоэтому я просто предлагаю быть предельно осторожным, если вы пытаетесь полагаться на то, что происходит без пробела.
Теперь также задан вопрос о команде echo : это необычное исключение, которое, я думаю echo., довольно хорошо известно специалистам DOS. Это, вероятно, было задокументировано. Поведение, по крайней мере, в CMD Win7 , заключается в том, что если команда начинается с " echo.", то первый период игнорируется. Таким образом, " echo..hi" превращается в вывод " .hi". Причина этого в том, что « echo.» можно использовать для печати пустой строки. В отличие от Unix, вы можете сделать это, просто запустив команду " echo". Тем не менее, в DOS, выполнение команды " echo" само по себе выведет текущую настройку " эхо ". Точно так же DOS рассматривает " Echo *Off*" и "Echo *On*"как специальные значения, которые изменяют текущую настройку эха. Если вы действительно хотите напечатать слово" Off", то" Echo.Off"добьется цели (по крайней мере, с достаточно недавними версиями интерпретатора командной строки CMD от Microsoft .)
Так что, по крайней мере, у echoкоманды есть полуразумное объяснение. Что касается остальных команд, я привык думать, что внутренние команды имеют приоритет. Однако, когда я попытался сделать несколько тестов, я обнаружил, что это довольно противоречиво. Я демонстрирую это на нескольких примерах, которые я задокументировал здесь.
Вот несколько примеров. Я использовал командную строку с повышенными правами, чтобы UAC не обращал на меня внимание при записи в корневой каталог. Это было сделано с помощью Microsoft Windows 7 CMD.EXE. Я подозреваю, что поведение может отличаться в других версиях, таких как COMMAND.COM из более старых версий MS-DOS или программного обеспечения, выпущенного другими компаниями (DR-DOS's COMMAND.COM).
(Этот ответ уже довольно длинный, поэтому я не включаю команды, чтобы очистить весь беспорядок, который я сделал в моей файловой системе. Есть небольшая часть очистки, но не очень.)
Вот пример, который доказывает, что внутренняя команда создает приоритет. (Я также демонстрирую довольно малоизвестную способность использовать двойное двоеточие, чтобы эффективно быть комментарием, который также хорошо работает в пакетных файлах. Технически, в пакетных файлах, он обрабатывается как метка, которая не может быть достигнута GOTO, и заканчивается быть быстрее, чем команда REM.)
C: \ something> md cd
C: \ something> echo echo subdir >> cd \ a.bat
C: \thing > md \ a
C: \ something> . \ Cd \ a.bat
subdir
C: \ something> :: Это бежало из подкаталога
C: \ something> cd \ a
C: \ a> :: Это изменило мой текущий каталог, поэтому cd имел приоритет
Обновление. После дальнейших экспериментов я обнаружил, что внутренняя команда cd имеет приоритет над файловой системой, только если указанный каталог не содержит точку. Так что если у вас есть каталог с именем « a.bat », то вы можете запустить « **cd\a.bat**» и пакетный файл запустится.
Это исследование менее распространенного поведения (так как большинство каталогов, вероятно, не содержат периодов) привело меня к обновлению моих выводов. Оказывается, что команда cd на самом деле ведет себя более похоже на команду copy, чем я изначально думал.
Хотя я сначала думал, что команды cd и copy ведут себя по-разному, теперь я понял, что это из-за структуры имен, которые я предоставлял. Тем не менее, я просмотрел свои предыдущие результаты и определил, что мои ранее задокументированные тесты помогают показать некоторые различия между тем, что происходит, когда имя включает точку и расширение, и когда это не так. Итак, я все еще включаю свои старые выводы ниже (в основном без изменений, но с некоторыми очень незначительными обновлениями, поэтому то, что я говорю, является точным).
Вот пример, демонстрирующий, что копия с полным путем не использует тот же приоритет (в пользу внутренней команды), что и cd, когда расширение не используется:
C: \ thing > эхо-корень эха >> \ try.bat
C: \ что-то> копия md
C: \thing > подкаталог эхо-эха >> копия \ try.bat
C: \ что-то> . \ Copy \ try.bat запускается из подкаталог
подкаталог
C: \ что - то> скопировать \ try.bat
подкаталоге
C: \ что - то> :: А? Почему это не переопределить и не запустить из корня?
C: \ something> :: Очевидно, что внутренняя команда копирования не имеет приоритета над проверкой подкаталога и полного имени файла (даже если внутренняя команда cd имела приоритет, когда каталог не имеет расширения)
C: \ кое-что> ::
C: \ что-то>:: Еще один тест: я могу добавить бесполезные периоды в конце
C: \ something> . \ Copy .. \ try.bat
подкаталог
C: \ something> :: Хорошо, отлично. Но тогда это не проверит подкаталог:
C: \thing > copy .. \ try.bat
1 файл (ов) скопирован.
C: \ что-то> :: Это запустило команду внутреннего копирования
Мои ранние результаты показали, что эти результаты показывают, что командная строка дает приоритет:
- в файловую систему (вместо внутренней команды копирования ) при указании обратной косой черты сразу после имени внутренней команды
- к внутренней команде cd (вместо файловой системы) при указании обратной косой черты сразу после имени внутренней команды.
- к внутренней команде копирования (вместо файловой системы) при указании периода сразу после имени внутренней команды.
Это ясно демонстрирует, что поведение не согласовано между командой copy (с полным именем файла, включая расширение) и командой cd (без расширения как части имени каталога). При использовании обратной косой черты команда copy (с полным расширением имени файла) сначала проверит файловую систему, а команда cd - нет (если каталог не содержит расширения).
(Обновление: сначала я думал, что несоответствие было основано на различном поведении между программами. Позже я обнаружил, что несоответствие действительно существовало, но было вызвано больше из предоставленных параметров.)
На самом деле, даже эти пункты не совсем точны, хотя я, кажется, только что продемонстрировал каждую отдельную вещь, которую я только что сказал. Проблема в том, что список пунктов не достаточно точен, чтобы быть полностью точным. (Я оставил вещи неточными, чтобы можно было сравнительно легко сравнивать эти пункты и проверять их относительно легко.)
Тем не менее, чтобы быть более точным, первый пункт должен указать, что оболочка командной строки дает приоритет:
- к файловой системе (вместо внутренней команды копирования ) при указании обратной косой черты, а затем оставшейся части полного пути сразу после имени внутренней команды
Следующее покажет, почему я делаю это различие:
C: \ elsewhere> эхо- повышение UAC, необходимое для этой строки >> \ needext
C: \ elsewhere> эхо- повышение UAC, необходимое для этой строки >> \ needext.bat
C: \ elsewhere> md. \ Copy
C: \ elsewhere> echo @ Echo subdir >> copy \ needext.bat
C: \ elsewhere> . \ Copy \ needext
subdir
C: \ elsewhere> copy \ needext.bat
subdir
C: \ elsewhere> copy \ needext
1 файл (ов) скопирован.
C: \ elsewhere> :: UAC также необходим для следующих строк
C: \ elsewhere> del \ needext
C: \ elsewhere> del \ needext.bat
(Обратите внимание, что последняя команда копирования искала файл с именем \ needext , поскольку использовалась внутренняя команда копирования . Файл \ needext.bat был создан только для того, чтобы легко показать, что он никогда не использовался командными строками, включающими слово copy .)
На этом этапе я установил некоторую несогласованность (с поведением команды копирования ), когда используется обратный слеш ...
Далее я продемонстрирую, что между этими командами есть некоторая согласованность. (Итак, есть последовательность ... хм ... иногда. У нас может быть только непротиворечивость, непоследовательность.) Далее я покажу, что команда cd ведет себя скорее как команда копирования, когда используется точка. Команда copy использует внутреннюю команду, как и команда cd .
C: \ something> md. \ Yetmore
C: \ Some > CD. \ Yetmore
C: \thing \ Yetmore> md . \ Md C: \thing
\ Yetmore> эхо- эхо subdir >> md \ test.bat
C: \ что-то \ Yetmore> . \ md. \ test
subdir
C: \ что-то \ Yetmore> md. \ test
C: \thing \ Yetmore> md. \ test Подкаталог
или файл. \ test уже существует.
C: \ something \ Yetmore> :: Эта ошибка показывает, что мы выполнили внутреннюю команду.
C: \ something \ Yetmore> md .. \ test
C: \ Чем-то \ butmore> md. \ Cd
C: \thing \ Yetmore> copy. \ Md cd
. \ Md \ test.bat
1 файл (ов) скопирован.
C: \ Чем-то \ whatmore> . \ Cd. \ Test
subdir
C: \ something \ Yetmore> cd. \ Test
C: \thing \ Yetmore \ test> :: внутренняя команда работала с одним периодом
C: \ something \ Yetmore \ test> cd ..
C: \ что-то \ butmore> . \ cd .. \ test
subdir
C: \thing \ Yetmore> cd .. \ test
C: \ Чем- то \ test> :: internal команда также имеет приоритет, когда два периода используемый
Итак, во время начального сеанса тестирования, который в основном был сосредоточен на командах cd и copy (с некоторым дополнительным использованием md и немного del ), единственный раз, когда у нас действительно была приоритетность файловой системы, была команда copy , а затем файловая система имела приоритет только при использовании полного пути.
После последующего просмотра я обнаружил, что команда cd также отдает приоритет файловой системе при использовании расширения. По крайней мере, это означает, что внутренние команды обрабатываются немного более согласованно друг с другом. Однако это также означает, что мы получаем другое поведение в зависимости от имен объектов файловой системы (файлов или каталогов). Кажется, что в поведении используется какая-то действительно очень непонятная внутренняя логика. Поэтому, полагаясь на такое поведение для работы в разных операционных системах, я бы посчитал это небезопасным .
