Почему «cd ..» работает в командной строке Windows?

При вводе cd.. без пробела между cd и .. командная строка Windows с радостью переключится на родительскую папку. Есть ли объяснение этому поведению? Команда не соответствует стандартным форматам command<space>arguments

Работаете, но не должны?

Кроме того, почему это не создает согласованных результатов?

эхо ..

  • Chrome. Как восстановить текст в текстовых полях?
  • Почему Internet Explorer не относится к любым таблицам стилей?
  • Настройка CNTLM для прокси-сервера, требующего базовой аутентификации
  • Как извлечь переменные среды из точки восстановления системы, 64-разрядная версия Windows 7
  • Остановить Cisco AnyConnect от блокировки сетевого адаптера
  • Установить значок пользовательской папки для сетевой папки в Проводнике Windows
  • Попытка двойной загрузки Windows 8.1 и Debian Jessie
  • Планировщик запуска триггеров в Windows 7, когда компьютер просыпается от сна / спящего режима
  • 4 Solutions collect form web for “Почему «cd ..» работает в командной строке Windows?”

    Как отмечают некоторые другие ответы / комментарии, идея о том, что пространство после команды неверно. Известным примером является то, что вы можете ввести косую черту после команды, не требуя сначала пробела.

    Тем не менее, есть другое поведение, которое немного менее понято и позволяет « cd.. », о котором вы спрашиваете. Это поведение также позволяет работать с « cd\ ».

    Поведение, которое вы описываете, является согласованным для всех команд, внутренних для интерпретатора командной строки. Если у вас есть определенные символы, включая период, косую черту или обратную косую черту, тогда будут проверены предыдущие символы, чтобы увидеть, является ли это командой, которая является внутренней для оболочки интерпретатора командной строки (CMD.EXE или ее предшественника COMMAND.COM ).

    Это можно сделать, прежде чем проверять, может ли это слово ссылаться на файл или подкаталог. Это верно для команды cd . К сожалению, при создании образца я обнаружил, что этого не происходит с командой copy , поэтому результаты несовместимы: они не обязательно одинаковы со всеми внутренними командами. Я не продолжал поиск, чтобы сравнить (многое) другие команды line 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 не собирался писать мне в корневой каталог. Это было сделано с CMD.EXE Microsoft Windows 7. Я подозреваю, что поведение может отличаться от других версий, таких как COMMAND.COM от старых версий MS-DOS, или программного обеспечения, выпущенного другими компаниями (COMMAND.COM DR-DOS).

    (Этот ответ довольно длинный, поэтому я не включаю команды, чтобы очистить весь беспорядок, который я сделал в своей файловой системе. Есть небольшая часть очистки, но не так много.)

    Вот пример, который доказывает, что внутренняя команда создает приоритет. (Я также демонстрирую довольно малоизвестную способность использовать двойной двоеточие, чтобы эффективно быть комментарием, который также хорошо работает в пакетных файлах. Технически, в пакетных файлах он обрабатывается как метка, недоступная GOTO, и заканчивается Быстрее, чем команда REM.)

    C: \ something> md cd
    C: \ something> echo echo subdir >> cd \ a.bat
    C: \ something> md \ a
    C: \ something> . \ Cd \ a.bat
    подкаталог

    C: \ something> :: Это пробег из поддира
    C: \ something> cd \ a
    C: \ a> :: Это изменило мой текущий каталог, поэтому cd имел приоритет

    Обновление: после дальнейших экспериментов я обнаружил, что внутренняя команда cd имеет приоритет перед файловой системой, если указанный каталог не включает период. Поэтому, если у вас есть каталог с именем « a.bat », вы можете запустить « **cd\a.bat** » и запустить командный файл.

    Это исследование менее распространенного поведения (поскольку большинство каталогов, вероятно, не имеют периодов в них) привело меня к обновлению моих результатов. Оказывается, команда cd фактически ведет себя больше похоже на команду копирования, чем я изначально думал.

    Хотя изначально я думал, что команды cd и copy ведут себя по-другому, я теперь понял, что это связано с шаблоном имен, которые я предоставлял. Тем не менее, я рассмотрел мои предыдущие результаты и определил, что мои ранее документированные тесты помогают показать некоторую разницу между тем, что происходит, когда имя включает период и расширение, а когда нет. Итак, я все еще включаю в себя мои более ранние результаты ниже (в основном без изменений, но с некоторыми очень незначительными обновлениями, так что я говорю точно).

    Вот пример демонстрации копии с полным путем, не использует тот же приоритет (в пользу внутренней команды) как cd, когда не используется расширение:

    C: \ something> echo echo root >> \ try.bat
    C: \ something> md copy
    C: \ something> echo echo подкаталог >> copy \ try.bat
    C: \ something> . \ Copy \ try.bat выполняется из подкаталога
    подкаталог

    C: \ something> copy \ try.bat
    подкаталог

    C: \ something> :: А? Почему это не отменяет и не запускается из корня?
    C: \ something> :: По-видимому, внутренняя команда копирования не имела приоритета над проверкой подкаталога и полного имени файла (хотя внутренняя команда cd имела приоритет, когда каталог не имел расширения)
    C: \ something> ::
    C: \ something> :: Еще одно испытание: я могу добавить бесполезные периоды в конце
    C: \ something> . \ Copy .. \ try.bat
    подкаталог

    C: \ something> :: Хорошо, отлично. Но тогда это не будет проверять подкаталог:
    C: \ something> copy .. \ try.bat
    1 файл (ы) скопирован.

    C: \ something> :: Выполняется команда внутренней копии

    Мои ранние результаты показали, что эти результаты показывают, что оболочка командной строки дает приоритет:

    • К файловой системе (вместо внутренней команды копирования ) при указании обратной косой черты сразу после имени внутренней команды
    • К внутренней команде cd (вместо файловой системы) при указании обратной косой черты сразу после имени внутренней команды.
    • К команде внутренней копии (вместо файловой системы) при указании периода сразу после имени внутренней команды.

    Это наглядно демонстрирует, что поведение несовместимо между командой копирования (с полным именем файла, включая расширение), и командой cd (без расширения как части имени каталога). При использовании обратной косой черты команда копирования (с полным расширением имени файла) сначала проверяет файловую систему, но команда cd не будет (если каталог не содержит расширение).

    (Обновление: сначала я подумал, что несогласованность была основана на различном поведении между программами. Позже я обнаружил, что несогласованность действительно существует, но была вызвана больше из предоставленных параметров.)

    На самом деле, даже те пулевые точки не совсем точны, хотя я просто продемонстрировал каждую отдельную вещь, о которой я только что сказал. Проблема заключается в том, что список точек пули недостаточно точен, чтобы быть полностью точным. (Я оставил вещи неточными, так что эти пулевые точки можно было сравнительно легко сравнить и проверить относительно легко).

    Однако, чтобы быть более точным, первая точка маркера должна указывать на то, что оболочка командной строки дает приоритет:

    • К файловой системе (вместо внутренней команды копирования ) при указании обратного слэша, а затем остальной части полного пути сразу после имени внутренней команды

    Ниже показано, почему я делаю это различие:

    C: \ в другом месте> эхо-выравнивание UAC, необходимое для этой строки >> \ needext
    C: \ в другом месте> эхо-выравнивание UAC, необходимое для этой строки >> \ needext.bat
    C: \ в другом месте> md. \ Copy
    C: \ в другом месте> echo @Echo subdir >> copy \ needext.bat
    C: \ в другом месте> . \ Copy \ needext
    подкаталог

    C: \ в другом месте> copy \ needext.bat
    подкаталог

    C: \ в другом месте> copy \ needext
    1 файл (ы) скопирован.

    C: \ в другом месте> :: UAC также необходим для следующих строк
    C: \ в другом месте> del \ needext
    C: \ в другом месте> del \ needext.bat

    (Обратите внимание, что последняя команда копирования искала файл с именем \ needext , потому что была использована внутренняя команда копирования . Файл \ needext.bat был создан только для того, чтобы легко показать, что он никогда не использовался командами, которые включали слово copy .)

    На этом этапе я установил некоторую несогласованность (с поведением команды копирования ), когда используется обратная косая черта …

    Затем я продемонстрирую, что между этими командами существует некоторая согласованность. (Итак, существует согласованность … мм … иногда. У нас может быть только согласованность, непоследовательно.) Далее я покажу, что команда cd ведет себя скорее как команда копирования, когда используется период. Команда copy использует внутреннюю команду, а также команду cd .

    C: \ something> md. \ Yetmore

    C: \ something> cd. \ Yetmore

    C: \ something \ yetmore> md. \ Md
    C: \ something \ yetmore> echo echo subdir >> md \ test.bat
    C: \ something \ yetmore> . \ Md . \ Test
    подкаталог

    C: \ something \ yetmore> md. \ Test

    C: \ something \ yetmore> md. \ Test
    Подкаталог или файл. \ Test уже существует.

    C: \ something \ yetmore> :: Эта ошибка показывает, что мы выполнили внутреннюю команду.
    C: \ something \ yetmore> md .. \ test
    C: \ something \ yetmore> md. \ Cd
    C: \ something \ yetmore> копия. \ Md cd
    . \ мкр \ test.bat
    1 файл (ы) скопирован.

    C: \ something \ yetmore> . \ Cd. \ Test
    подкаталог

    C: \ something \ yetmore> cd. \ Test
    C: \ something \ yetmore \ test> :: внутренняя команда, работающая с одним периодом
    C: \ something \ yetmore \ test> cd ..
    C: \ something \ yetmore> . \ Cd .. \ test
    подкаталог

    C: \ something \ yetmore> cd .. \ test
    C: \ something \ test> :: внутренняя команда также имеет приоритет, когда используются два периода

    Таким образом, во время начальной тестовой сессии, которая в основном была сосредоточена на командах cd и copy (с некоторым дополнительным использованием md и бит del ), единственный раз, когда мы действительно имели файловую систему, был приоритет, был с командой копирования , а затем При использовании полного пути файловая система имела приоритет.

    После последующего обзора я обнаружил, что команда cd также давала приоритет файловой системы при использовании расширения. По крайней мере, это означает, что внутренние команды обрабатываются несколько более согласованными друг с другом. Однако это также означает, что мы получаем другое поведение, основанное на именах объектов файловой системы (файлов или каталогов). Похоже, что поведение использует какую-то действительно, действительно неясную внутреннюю логику. Поэтому, полагаясь на это поведение для работы в разных операционных системах, я считаю, что это небезопасно .

    Вы предполагаете, что имя команды и ее аргументы должны быть разделены пробелом, в частности, но это неверно. Пока вызов может быть однозначно интерпретирован, вызов действителен.

    В этом случае начинается первый аргумент . И. Не может быть частью имени команды, поэтому cd и .. просто анализируются как два отдельных токена.

    Обычно ваш первый аргумент начинается с алфавитного символа (например, начало пути), поэтому он «истекает» в ваше имя команды и выдает ошибку … но это не проблема синтаксиса. Это семантический.

    Вы можете видеть тот же эффект при работе с другими командами, включая echo :

     echo... .. 

    В этом случае мы получаем только два периода, потому что команда echo сама имеет специальное правило , так что следующее:

     echo . 

    Или, в дополнение, это:

     echo. 

    Выводит только пустую строку. Это удобство. По-видимому, это было реализовано путем игнорирования ведущего периода в аргументе.

    Эй, это DOS / Batch. Вы хотите здравомыслия? : D

    Команда cd.. правильная, и она была определена так же, как в исходном командном интерпретаторе command.com который позже был назван cmd.exe .

    Командный интерпретатор знает, как обрабатывать cd.. , потому что . Это особый символ, как \ .

    Это обратная совместимость.

    Интерпретатор командной строки предназначен для обратной совместимости с командами из исходного интерпретатора команд MSDOS, который был разработан для обратной совместимости с командным интерпретатором CP / M. Ни CP / M, ни MSDOS не разрешили a . В имени файла (он был интерпретирован как разделитель между двумя частями имени файла, базовым именем и расширением). Это означало, что (по крайней мере, для ранних версий DOS) командный интерпретатор мог идентифицировать это, если он достиг «.». (Или даже любой другой символ, который был незаконным в имени файла), он передал конец имени команды и попал в аргументы команды. Это довольно часто используется как в DOS, так и в CP / M – например, dir/w была очень распространенной командой, эквивалентной dir /w означает список файлов в горизонтальном формате.

    В наше время, '.' Могут появляться в именах файлов. Это вызывает некоторые сложности при анализе команд, но оболочка по- прежнему идентифицирует a . Который не является частью точного имени файла, как начало аргументов. Это необходимо во многом потому, что миллионы пользователей привыкли печатать cd.. или иметь большое количество пакетных файлов, содержащих это или echo. Или любое количество других подобных команд.

    Давайте будем гением компьютера.