Интерфейс ос windows командный да или нет

Интерфейс командной строки

Интерфейс командной строки (англ. Command line interface, CLI ) — разновидность текстового интерфейса (CUI) между человеком и компьютером, в котором инструкции компьютеру даются в основном путём ввода с клавиатуры текстовых строк (команд), в UNIX-системах возможно применение мыши [1] . Также известен под названием консоль.

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

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

Содержание

Назначение

На устройстве-консоли, которое печатало текст на бумаге, интерфейс командной строки был единственным возможным. На видеотерминалах интерфейс командной строки применяется по таким причинам:

• Небольшой расход памяти по сравнению с системой меню.
• В современном программном обеспечении имеется большое число команд, многие из которых нужны крайне редко. Поэтому даже в некоторых программах с графическим интерфейсом применяется командная строка: набор команды (при условии, что пользователь знает эту команду) осуществляется гораздо быстрее, чем, например, навигация по меню.
• Естественное расширение интерфейса командной строки — пакетный интерфейс. Его суть в том, что в файл обычного текстового формата записывается последовательность команд, после чего этот файл можно выполнить в программе, что приведет к такому же (в большинстве случаев) эффекту, как если бы эти команды были по очереди введены в командную строку. Примеры — .bat-файлы в DOS и Windows, shell-скрипты в Unix-системах.

Если программа полностью или почти полностью может управляться командами интерфейса командной строки и поддерживает пакетный интерфейс, умелое сочетание интерфейса командной строки с графическим предоставляет пользователю очень мощные возможности.

Формат команды

Наиболее общий формат команд (в квадратные скобки помещены необязательные части):

[символ_начала_команды]имя_команды [параметр_1 [параметр_2 […]]]

Символ начала команды может быть самым разным, однако чаще всего для этой цели используется косая черта ( / ). Если строка вводится без этого символа, выполняется некоторая базовая команда: например, строка «Привет» в IRC эквивалентна вводу « /msg Привет ». Если же такой базовой команды нет, символ начала команды отсутствует вообще (как, например, в DOS).

Параметры команд могут иметь самый разный формат. В основном применяются следующие правила:

• параметры разделяются пробелами (и отделяются от названия команды пробелом)
• параметры, содержащие пробелы, обрамляются кавычками-апострофами ( ‘ ) или двойными кавычками ( » )
• если параметр используется для обозначения включения какой-либо опции, выключенной по умолчанию, он начинается с косой черты ( / ) или дефиса ( — )
• если параметр используется для включения/выключения какой-либо опции, он начинается (или заканчивается) знаком плюс или минус (для включения и выключения соответственно)
• если параметр указывает действие из группы действий, назначенных команде, он не начинается со специальных символов
• если параметр указывает объект, к которому применяется действие команды, он не начинается со специальных символов
• если параметр указывает дополнительный параметр какой-либо опции, то он имеет формат /опция:дополнительный_параметр (вместо косой черты также может употребляться дефис)

Например, в некоей абстрактной игре может быть такая команда:

/map dm1 /skill:2

• / — символ начала команды
• map — название команды (переход на другой уровень)
• dm1 — обязательный параметр (название уровня)
• /skill:2 — дополнительный параметр (задание уровня сложности)

Применение

Основные сферы применения интерфейса командной строки:

В операционных системах

Основное применение интерфейса командной строки — интерфейс операционной системы. В Windows язык командной строки не имеет чёткой стандартизации, однако существует стандарт командной строки POSIX и его модификация в рамках GNU.

В компьютерных играх

Изначально консоль в играх использовалась для отладки.

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

Наиболее ярким примером игр, использующих интерфейс командной строки, могут быть названы текстовые квесты, а также сетевые многопользовательские ролевые игры — MUD. Команды в таких играх вводятся на так называемом псевдоестественном языке.

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

(тильда); реже ↵ Enter ‘, ещё реже ⇧ Shift + D . Консоль позволяет вносить изменения в настройки игры оперативнее, чем меню — например, набрать name Terminator быстрее, чем найти то меню, в котором вводится имя игрока, и ввести Terminator. Консоль позволяет в числе прочего вводить чит-коды.

Также консоль предоставляет возможность изменять настройки назначения горячих клавиш, что может использоваться для обмана соперника в многопользовательских играх, например, предложением ввести команду unbindall , отменяющую все горячие клавиши, в том числе и отвечающие за движение игрока.

Интерфейс, который предоставляется моддерам, не всегда позволяет менять меню; но он всегда позволяет добавлять свои консольные команды. Например, в DotA (карте для игры Warcraft III) режим игры задаёт участник, играющий синими, через консоль.

Командный интерфейс ОС Windows

1. Оболочка командной строки Windows. Интерпретатор Cmd.exe

В операционной системе Windows, как и в других операционных системах, интерактивные (набираемые с клавиатуры и сразу же выполняемые) команды выполняются с помощью так называемого командного интерпретатора, иначе называемого командным процессором или оболочкой командной строки (command shell). Командный интерпретатор или оболочка командной строки — это программа, которая, находясь в оперативной памяти, считывает набираемые вами команды и обрабатывает их.

Для запуска командного интерпретатора (открытия нового сеанса командной строки) можно выбрать пункт Выполнить… (Run) в меню Пуск (Start), ввести имя файла Cmd.exe и нажать кнопку OK.

1.1 Синтаксис командной строки, перенаправление ввода – вывода

Файловая система имеет древовидную структуру и имена файлов задаются в формате [диск:] [путь]имя_файла. Если путь начинается с символа «», то маршрут вычисляется от корневого каталога – иначе от текущего.

Например, c:123.txt задает файл 123.txt в текущем каталоге, c:123.txt – в корневом, а DOC123.txt – в подкаталоге DOC текущего каталога.

Существуют особые обозначения для текущего каталога (точка «.») и трех его верхних уровней (две точки «..» — родительский, три «…» — второго уровня и, наконец, четыре «….» — третьего уровня).

Например, для текущего каталога C:WindowsMediaOffice97 путь к файлу autoexec.bat в корневом каталоге диска C: может быть записан в виде ….autoexec.bat.

В именах файлов (но не дисков или каталогов) можно применять так называемые групповые символы или шаблоны: ? (вопросительный знак) и * (звездочка). Символ * в имени файла означает произвольное количество любых допустимых символов, символ ? — один произвольный символ или его отсутствие. Скажем, под шаблон text??1.txt подходят, например, имена text121.txt и text11.txt, под шаблон text*.txt — имена text.txt, textab12.txt, а под шаблон text.* — все файлы с именем text и произвольным расширением.

Например, DIR /? > helpdir.txt выведет справку по команде DIR в файл. Символ «>>» позволяет не создавать файл заново, а дописать в него. По аналогии символ « ) вводите имя этой команды (регистр не важен), ее параметры и ключи (если они необходимы) и нажимаете клавишу . Например:

Имя команды здесь — COPY, параметры — C:myfile.txt и A:, а ключом является /V. Отметим, что в некоторых командах ключи могут начинаться не с символа /, а с символа – (минус), например, -V.

Многие команды Windows имеют большое количество дополнительных параметров и ключей, запомнить которые зачастую бывает трудно. Большинство команд снабжено встроенной справкой, в которой кратко описываются назначение и синтаксис данной команды. Получить доступ к такой справке можно путем ввода команды с ключом /?.

1.4 Условное выполнение и группировка команд

В командной строке Windows NT/2000/XP можно использовать специальные символы, которые позволяют вводить несколько команд одновременно и управлять работой команд в зависимости от результатов их выполнения. С помощью таких символов условной обработки можно содержание небольшого пакетного файла записать в одной строке и выполнить полученную составную команду.

Используя символ амперсанта &, можно разделить несколько утилит в одной командной строке, при этом они будут выполняться друг за другом. Например, если набрать команду DIR & PAUSE & COPY /? и нажать клавишу , то вначале на экран будет выведено содержимое текущего каталога, а после нажатия любой клавиши — встроенная справка команды COPY.

Символ ^ позволяет использовать командные символы как текст, то есть при этом происходит игнорирование значения специальных символов. Например, если ввести в командной строке

и нажать клавишу , то произойдет выполнение подряд двух команд: ECHO Абв и COPY /? (команда ECHO выводит на экран символы, указанные в командной строке после нее). Если же выполнить команду

то на экран будет выведено

В этом случае просто выполняется одна команда ECHO с соответствующими параметрами.

Условная обработка команд в Windows осуществляется с помощью символов && и || следующим образом. Двойной амперсант && запускает команду, стоящую за ним в командной строке, только в том случае, если команда, стоящая перед амперсантами была выполнена успешно. Например, если в корневом каталоге диска C: есть файл plan.txt, то выполнение строки TYPE C:plan.txt && DIR приведет к выводу на экран этого файла и содержимого текущего каталога. Если же файл C:plan.txt не существует, то команда DIR выполняться не будет.

Два символа || осуществляют в командной строке обратное действие, т.е. запускают команду, стоящую за этими символами, только в том случае, если команда, идущая перед ними, не была успешно выполнена. Таким образом, если в предыдущем примере файл C:plan.txt будет отсутствовать, то в результате выполнения строки TYPE C:plan.txt || DIR на экран выведется содержимое текущего каталога.

Отметим, что условная обработка действует только на ближайшую команду, то есть в строке

команда COPY /? запустится в любом случае, независимо от результата выполнения команды TYPE C:plan.txt.

Несколько утилит можно сгруппировать в командной строке с помощью скобок. Рассмотрим, например, две строки:

В первой из них символ условной обработки && действует только на команду DIR, во второй — одновременно на две команды: DIR и COPY.

Изучаем командную строку Windows

До того момента, когда операционные системы научились «общаться» с пользователями при помощи привычных для нас графических изображений, ввод и вывод информации в компьютер осуществлялся исключительно при помощи текста.

Эта статья содержит общую ознакомительную информацию для разных версий Windows. После прочтения вы можете пополнить свои знания по конкретной разновидности ОС: 7-ка, 8 версия или узнать о множестве улучшений программы в 10 версии Windows.

Конечно, до сих пор существуют такие ОС, которые используют для общения с пользователями, так называемый, интерфейс командной строки. Но ими обычно пользуются профессиональные программисты, системные администраторы и прочие работники IT-индустрии. Для обычных пользователей производители операционных систем создали удобный графический интерфейс, который позволяет «общаться» с компьютером или, допустим, смартфоном при помощи мышки или нажатий по кнопкам на экране.

Несмотря на это, каждая операционная система (включая Windows XP, 7, 8 и так далее) всё же, как и раньше, поддерживает ввод и вывод информации посредством текстовых команд. Командная строка Windows — явный тому пример. Разберёмся, что это такое.

Что такое командная строка

В первую очередь — это программа cmd.exe, находящаяся в директории system32 папки операционной системы. Вариант ее месторасположения: C:Windowssystem32cmd.exe. Путь может и отличаться, в зависимости от версии Windows и места ее установки.

В общих чертах, командная строка — это инструмент операционной системы, состоящий, как правило, из оболочки ОС и текстового интерфейса. Оболочка обеспечивает пользователя инструментарием для «общения» с операционной системой, которыми, в данном случае, выступают текстовые команды.

Командная строка операционных систем Windows, начиная с XP, призвана обеспечить пользователей возможностью применения MS-DOS и множества других компьютерных команд. Важная её особенность заключается в том, что она способна выполнять пользовательские команды без помощи графического интерфейса. Необходимость в понимании и знании всех этих команд делает затруднительным использование командной строки для управления операционной системой рядовыми пользователями. Однако, это не так уж и сложно, как кажется на первый взгляд.

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

В каких ситуациях командная строка может оказаться полезной

Существует ряд причин использования командной строки. Бывают и такие ситуации, в которых без её использования просто невозможно обойтись. А в некоторых случаях выполнение определённых функций Windows, а также настройка операционной системы через командную строку происходит удобней и быстрей.

Возьмём ситуацию с вирусами. Существуют такие вирусные программы, которые полностью блокируют графический интерфейс пользователя (так называемые, смс-баннеры). Как правило, эти вирусы выводят на экран компьютера окно, в котором написано сообщение, типа «Ваш компьютер блокирован управлением МВД» или «Ваши данные под угрозой» и так далее. Такие смс-баннеры невозможно закрыть никакими обычными способами — ни при помощи мышки, ни при помощи горячих клавиш на клавиатуре.

В таких ситуациях на помощь как раз и приходит командная строка. Конечно, чтобы её вызвать, необходимо проделать определённые действия с компьютером, но сейчас не об этом.

Ещё одна ситуация. Допустим, Windows XP (или любая другая версия) просто перестала работать, а на жёстком диске остались важные данные, которые срочно необходимо скопировать на флешку. Если под рукой имеется хотя бы установочный диск с Windows, то на определённом моменте установки операционной системы (без ожидания окончания установки) можно вызвать командную строку и скопировать эти данные. Эта возможность часто приходится весьма кстати в случае с повреждённым диском, когда к примеру, установка Windows прекращается во время копирования установочных файлов на жёсткий диск.

Командная строка также способна быстро вызывать различные стандартные мастера-настройщики операционной системы (например, мастер настройки сети) или такие системные инструменты, как редактор реестра, службы компонентов и остальные. С её помощью также можно производить непосредственные настройки различных параметров Windows, осуществлять управление файлами, запускать программы и выполнять многие другие действия.

Как пользоваться командной строкой

На различных компьютерных форумах и сайтах можно найти сотни руководств по использованию тех или программ, выполнению каких-то системных настроек и массу других статей, в которых авторы призывают к использованию командной строки. Многие неопытные пользователи сразу теряются, видя фразу «Запустите командную строку…». Если вы также входите в их число, вам будет очень полезно ознакомиться с работой этого полезного инструмента. Начнём с того, как её вызвать.

Как вызвать командную строку

Начиная с Windows XP и до последней версии этого семейства операционных систем, командная строка вызывается посредством диалога «Выполнить» («Run»), в который необходимо ввести команду — «cmd». Запуск этого диалога осуществляется с помощью одновременного нажатия клавиш Win + R :

В Windows XP (в отличие от последующих версий) в меню «Пуск» имеется специальный ярлык, который так и называется «Выполнить…». Если нажать на него, то диалог также запустится.

Вызвать командную строку можно и другими способами. Вот они:

Выполнение одного из приведённых выше действий приведёт к запуску окна чёрного цвета с мигающим курсором — это и есть командная строка. Давайте, рассмотрим, как с ней работать.

В версии Windows 8 есть другие способы запуска cmd. Также как и в 10-ке, про особенности которой можно узнать здесь подробнее.

Работа в командной строке

Чтобы «cmd» выполнил ту или иную команду, достаточно ввести её в окно, после чего нажать клавишу Enter . Для проверки можете ввести «help» — эта команда отобразит список всех имеющихся стандартных команд.

Как вы могли заметить, их множество. Однако, это далеко не все команды, которые могут быть выполнены при помощи командной строки. Существует множество различных программ, которые также могут управляться через эту консоль. В принципе, «cmd» является расширяемой оболочкой, что говорит о возможности внесения в список выполняемых ею действий всё новых и новых команд.

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

Попробуем перейти с одного локального диска на другой, просмотрим его содержимое, затем создадим папку, перейдём в неё, а в ней создадим ещё одну папку и удалим её. Интересная задачка? Главное, что для выполнения каждого отдельного действия потребуется задействовать разные команды. Начнём.

После запуска командной строки, вы могли заметить перед мигающим курсором адрес: «C:/Users/Имя пользователя» (в нашем случае — тут «Reptile»). Имя последней папки означает ваше текущее местоположение (то же самое, как если бы вы зашли в эту папку через Проводник). А «С:» — это локальный диск, на котором вы находитесь. Чтобы сменить текущий локальный диск, достаточно ввести его букву и двоеточие сразу после неё — например, «D:».

Так вы попадёте на диск «D:» (или любой другой). Чтобы просмотреть содержимое диска (или вообще любой папки) используется команда «dir». Введите её прямо здесь, и вы увидите список файлов и папок, имеющихся на диске «D:».

Теперь создадим папку прямо в корне диска. Для этого используем команду — «mkdir», а в качестве параметра через пробел нужно вписать имя будущей папки, например, «mkdir xp». В данном случае создастся папка с именем «xp».

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

Для перехода в ту или иную папку используйте команду «cd». Здесь в качестве аргумента также используется имя каталога для перехода. Введём «cd xp» и попадём внутрь папки (сделаем эту папку текущей).

Создадим в папке ещё одну, используя команду «mkdir». Пусть это будет папка «123».

Теперь удалим её. Для этого вводим «rmdir 123». Выполните теперь в каталоге «xp» команду «dir» и вы увидите, что папки «123» больше нет.

Если вы захотите подробнее ознакомиться с описанием той или иной команды, просто введите ключ «/?» сразу после команды, и на экран будет выведена подсказка. Например, введите «dir /?». Другой вариант запуска подсказки: «help dir».

Запомнить все существующие команды не просто — их огромное множество. На официальном сайте Microsoft имеется наиболее полное руководство по командной строке, хотя и описаний, выдаваемых командой help вполне достаточно.

Видео по теме

1. Оболочка командной строки Windows. Интерпретатор Cmd.exe

В операционной системе Windows, как и в других операционных системах, интерактивные (набираемые с клавиатуры и сразу же выполняемые) команды выполняются с помощью так называемого командного интерпретатора, иначе называемого командным процессором или оболочкой командной строки (command shell). Командный интерпретатор или оболочка командной строки — это программа, которая, находясь в оперативной памяти, считывает набираемые вами команды и обрабатывает их.

Для запуска командного интерпретатора (открытия нового сеанса командной строки) можно выбрать пункт Выполнить… (Run) в меню Пуск (Start), ввести имя файла Cmd.exe и нажать кнопку OK.

1.1 Синтаксис командной строки, перенаправление ввода – вывода

Файловая система имеет древовидную структуру и имена файлов задаются в формате [диск:] [путь]имя_файла. Если путь начинается с символа «», то маршрут вычисляется от корневого каталога – иначе от текущего.

Например, c:123.txt задает файл 123.txt в текущем каталоге, c:123.txt – в корневом, а DOC123.txt – в подкаталоге DOC текущего каталога.

Существуют особые обозначения для текущего каталога (точка «.») и трех его верхних уровней (две точки «..» — родительский, три «…» — второго уровня и, наконец, четыре «….» — третьего уровня).

Например, для текущего каталога C:WindowsMediaOffice97 путь к файлу autoexec.bat в корневом каталоге диска C: может быть записан в виде ….autoexec.bat.

В именах файлов (но не дисков или каталогов) можно применять так называемые групповые символы или шаблоны: ? (вопросительный знак) и * (звездочка). Символ * в имени файла означает произвольное количество любых допустимых символов, символ ? — один произвольный символ или его отсутствие. Скажем, под шаблон text??1.txt подходят, например, имена text121.txt и text11.txt, под шаблон text*.txt — имена text.txt, textab12.txt, а под шаблон text.* — все файлы с именем text и произвольным расширением.

Например, DIR /? > helpdir.txt выведет справку по команде DIR в файл. Символ «>>» позволяет не создавать файл заново, а дописать в него. По аналогии символ «<» позволяет читать данные не с клавиатуры, а с файла. Например, DATE < date.txt ввод новой даты из файла.

1.2 Переменные окружения

При загрузке ОС Windows в оперативной памяти постоянно хранится набор т.н. переменных окружения (environment variables). Хотя в Windows есть более совершенный способ для хранения системных значений – реестр, многие программы по-прежнему используют переменные окружения. Наиболее важные переменные хранят системный путь для поиска (PATH), каталог запуска Windows (WINDIR), место хранения временных файлов (TEMP) и многое другое.

Переменные устанавливаются с помощью команды

SET [переменная=[строка]]

Запуск SET без параметров приводит к выводу списка переменных среды. Для получения их значений (всегда строки) нужно имя соответствующей переменной заключить в символы «%», например: %TEMP%.

1.3 Внутренние и внешние команды. Структура команд

Некоторые команды распознаются и выполняются непосредственно самим командным интерпретатором — такие команды называются внутренними (например, COPY или DIR) Другие команды операционной системы представляют собой отдельные программы, расположенные по умолчанию в том же каталоге, что и Cmd.exe, которые Windows загружает и выполняет аналогично другим программам. Такие команды называются внешними (например, MORE или XCOPY).

Рассмотрим структуру самой командной строки и принцип работы с ней. Для того, чтобы выполнить команду, вы после приглашения командной строки (например, C:>) вводите имя этой команды (регистр не важен), ее параметры и ключи (если они необходимы) и нажимаете клавишу <Enter>. Например:

C:>COPY C:myfile.txt A: /V

Имя команды здесь — COPY, параметры — C:myfile.txt и A:, а ключом является /V. Отметим, что в некоторых командах ключи могут начинаться не с символа /, а с символа – (минус), например, -V.

Многие команды Windows имеют большое количество дополнительных параметров и ключей, запомнить которые зачастую бывает трудно. Большинство команд снабжено встроенной справкой, в которой кратко описываются назначение и синтаксис данной команды. Получить доступ к такой справке можно путем ввода команды с ключом /?.

1.4 Условное выполнение и группировка команд

В командной строке Windows NT/2000/XP можно использовать специальные символы, которые позволяют вводить несколько команд одновременно и управлять работой команд в зависимости от результатов их выполнения. С помощью таких символов условной обработки можно содержание небольшого пакетного файла записать в одной строке и выполнить полученную составную команду.

Используя символ амперсанта &, можно разделить несколько утилит в одной командной строке, при этом они будут выполняться друг за другом. Например, если набрать команду DIR & PAUSE & COPY /? и нажать клавишу <Enter>, то вначале на экран будет выведено содержимое текущего каталога, а после нажатия любой клавиши — встроенная справка команды COPY.

Символ ^ позволяет использовать командные символы как текст, то есть при этом происходит игнорирование значения специальных символов. Например, если ввести в командной строке

ECHO Абв & COPY /?

и нажать клавишу <Enter>, то произойдет выполнение подряд двух команд: ECHO Абв и COPY /? (команда ECHO выводит на экран символы, указанные в командной строке после нее). Если же выполнить команду

ECHO Абв ^& COPY /?

то на экран будет выведено

Абв & COPY /?

В этом случае просто выполняется одна команда ECHO с соответствующими параметрами.

Условная обработка команд в Windows осуществляется с помощью символов && и || следующим образом. Двойной амперсант && запускает команду, стоящую за ним в командной строке, только в том случае, если команда, стоящая перед амперсантами была выполнена успешно. Например, если в корневом каталоге диска C: есть файл plan.txt, то выполнение строки TYPE C:plan.txt && DIR приведет к выводу на экран этого файла и содержимого текущего каталога. Если же файл C:plan.txt не существует, то команда DIR выполняться не будет.

Два символа || осуществляют в командной строке обратное действие, т.е. запускают команду, стоящую за этими символами, только в том случае, если команда, идущая перед ними, не была успешно выполнена. Таким образом, если в предыдущем примере файл C:plan.txt будет отсутствовать, то в результате выполнения строки TYPE C:plan.txt || DIR на экран выведется содержимое текущего каталога.

Отметим, что условная обработка действует только на ближайшую команду, то есть в строке

TYPE C:plan.txt && DIR & COPY /?

команда COPY /? запустится в любом случае, независимо от результата выполнения команды TYPE C:plan.txt.

Несколько утилит можно сгруппировать в командной строке с помощью скобок. Рассмотрим, например, две строки:

TYPE C:plan.txt && DIR & COPY /?
TYPE C:plan.txt && (DIR & COPY /?)

В первой из них символ условной обработки && действует только на команду DIR, во второй — одновременно на две команды: DIR и COPY.

A command-line interpreter or command-line processor uses a command-line interface (CLI) to receive commands from a user in the form of lines of text. This provides a means of setting parameters for the environment, invoking executables and providing information to them as to what actions they are to perform. In some cases the invocation is conditional based on conditions established by the user or previous executables. Such access was first provided by computer terminals starting in the mid-1960s. This provided an interactive environment not available with punched cards or other input methods.

Today, many users rely upon graphical user interfaces and menu-driven interactions. However, some programming and maintenance tasks may not have a graphical user interface and use a command line.

Alternatives to the command-line interface include text-based user interface menus (for example, IBM AIX SMIT), keyboard shortcuts, and various desktop metaphors centered on the pointer (usually controlled with a mouse). Examples of this include the Microsoft Windows, DOS Shell, and Mouse Systems PowerPanel. Command-line interfaces are often implemented in terminal devices that are also capable of screen-oriented text-based user interfaces that use cursor addressing to place symbols on a display screen.

Programs with command-line interfaces are generally easier to automate via scripting.

Many software systems implement command-line interfaces for control and operation. This includes programming environments and utility programs.

Comparison to graphical user interfaces[edit]

Compared with a graphical user interface, a command-line interface requires fewer system resources to implement. Since options to commands are given in a few characters in each command line, an experienced user often finds the options easier to access. Automation of repetitive tasks is simplified by line editing and history mechanisms for storing frequently used sequences; this may extend to a scripting language that can take parameters and variable options. A command-line history can be kept, allowing review or repetition of commands.

A command-line system may require paper or online manuals for the user’s reference, although often a «help» option provides a concise review of the options of a command. The command-line environment may not provide graphical enhancements such as different fonts or extended edit windows found in a GUI. It may be difficult for a new user to become familiar with all the commands and options available, compared with the icons and drop-down menus of a graphical user interface, without reference to manuals.

Types[edit]

Operating system command-line interfaces[edit]

Operating system (OS) command-line interfaces are usually distinct programs supplied with the operating system. A program that implements such a text interface is often called a command-line interpreter, command processor or shell.

Examples of command-line interpreters include DEC’s DIGITAL Command Language (DCL) in OpenVMS and RSX-11, the various Unix shells (sh, ksh, csh, tcsh, zsh, Bash, etc.), CP/M’s CCP, DOS’ COMMAND.COM, as well as the OS/2 and the Windows CMD.EXE programs, the latter groups being based heavily on DEC’s RSX-11 and RSTS CLIs. Under most operating systems, it is possible to replace the default shell program with alternatives; examples include 4DOS for DOS, 4OS2 for OS/2, and 4NT / Take Command for Windows.

Although the term ‘shell’ is often used to describe a command-line interpreter, strictly speaking, a ‘shell’ can be any program that constitutes the user-interface, including fully graphically oriented ones. For example, the default Windows GUI is a shell program named EXPLORER.EXE, as defined in the SHELL=EXPLORER.EXE line in the WIN.INI configuration file. These programs are shells, but not CLIs.

Application command-line interfaces[edit]

Application programs (as opposed to operating systems) may also have command-line interfaces.

An application program may support none, any, or all of these three major types of command-line interface mechanisms:

• Parameters: Most command-line interfaces support a means to pass additional information to a program when it is launched.
• Interactive command-line sessions: After launch, a program may provide an operator with an independent means to enter commands.
• Inter-process communication: Most operating systems support means of inter-process communication (for example, standard streams or named pipes). Command lines from client processes may be redirected to a CLI program by one of these methods.

Some applications support a CLI, presenting their own prompt to the user and accepting command lines. Other programs support both a CLI and a GUI. In some cases, a GUI is simply a wrapper around a separate CLI executable file. In other cases, a program may provide a CLI as an optional alternative to its GUI. CLIs and GUIs often support different functionality. For example, all features of MATLAB, a numerical analysis computer program, are available via the CLI, whereas the MATLAB GUI exposes only a subset of features.

In Colossal Cave Adventure from 1975, the user uses a CLI to enter one or two words to explore a cave system.

History[edit]

The command-line interface evolved from a form of communication conducted by people over teleprinter (TTY) machines. Sometimes these involved sending an order or a confirmation using telex. Early computer systems often used teleprinter as the means of interaction with an operator.

The mechanical teleprinter was replaced by a «glass tty», a keyboard and screen emulating the teleprinter. «Smart» terminals permitted additional functions, such as cursor movement over the entire screen, or local editing of data on the terminal for transmission to the computer. As the microcomputer revolution replaced the traditional – minicomputer + terminals – time sharing architecture, hardware terminals were replaced by terminal emulators — PC software that interpreted terminal signals sent through the PC’s serial ports. These were typically used to interface an organization’s new PC’s with their existing mini- or mainframe computers, or to connect PC to PC. Some of these PCs were running Bulletin Board System software.

Early operating system CLIs were implemented as part of resident monitor programs, and could not easily be replaced. The first implementation of the shell as a replaceable component was part of the Multics time-sharing operating system.^[1] In 1964, MIT Computation Center staff member Louis Pouzin developed the RUNCOM tool for executing command scripts while allowing argument substitution.^[2] Pouzin coined the term «shell» to describe the technique of using commands like a programming language, and wrote a paper about how to implement the idea in the Multics operating system.^[3] Pouzin returned to his native France in 1965, and the first Multics shell was developed by Glenda Schroeder.^[2]

The first Unix shell, the V6 shell, was developed by Ken Thompson in 1971 at Bell Labs and was modeled after Schroeder’s Multics shell.^[4][5] The Bourne shell was introduced in 1977 as a replacement for the V6 shell. Although it is used as an interactive command interpreter, it was also intended as a scripting language and contains most of the features that are commonly considered to produce structured programs. The Bourne shell led to the development of the KornShell (ksh), Almquist shell (ash), and the popular Bourne-again shell (or Bash).^[5]

Early microcomputers themselves were based on a command-line interface such as CP/M, DOS or AppleSoft BASIC. During the 1980s and 1990s, the introduction of the Apple Macintosh and of Microsoft Windows on PCs saw the command line interface as the primary user interface replaced by the Graphical User Interface. The command line remained available as an alternative user interface, often used by system administrators and other advanced users for system administration, computer programming and batch processing.

In November 2006, Microsoft released version 1.0 of Windows PowerShell (formerly codenamed Monad), which combined features of traditional Unix shells with their proprietary object-oriented .NET Framework. MinGW and Cygwin are open-source packages for Windows that offer a Unix-like CLI. Microsoft provides MKS Inc.’s ksh implementation MKS Korn shell for Windows through their Services for UNIX add-on.

Since 2001, the Macintosh operating system macOS has been based on a Unix-like operating system called Darwin. On these computers, users can access a Unix-like command-line interface by running the terminal emulator program called Terminal, which is found in the Utilities sub-folder of the Applications folder, or by remotely logging into the machine using ssh. Z shell is the default shell for macOS; Bash, tcsh, and the KornShell are also provided. Before macOS Catalina, Bash was the default.

Usage[edit]

A CLI is used whenever a large vocabulary of commands or queries, coupled with a wide (or arbitrary) range of options, can be entered more rapidly as text than with a pure GUI. This is typically the case with operating system command shells. CLIs are also used by systems with insufficient resources to support a graphical user interface. Some computer language systems (such as Python, Forth, LISP, Rexx, and many dialects of BASIC) provide an interactive command-line mode to allow for rapid evaluation of code.

CLIs are often used by programmers and system administrators, in engineering and scientific environments, and by technically advanced personal computer users. CLIs are also popular among people with visual disabilities since the commands and responses can be displayed using refreshable Braille displays.

Anatomy of a shell CLI[edit]

The general pattern of a command line interface^[6][7] is:

Prompt command param1 param2 param3 … paramN

• Prompt — generated by the program to provide context for the user.
• Command — provided by the user. Commands are usually one of three classes:
  1. Internal commands are recognized and processed by the command line interpreter.
  2. Included commands run separate executables.
  3. External commands run executable files that may be included by other parties.
• param1 …paramN — parameters provided by the user. The format and meaning of the parameters depends upon the command. In the case of Included or External commands, the values of the parameters are delivered to the program as it is launched by the OS. Parameters may be either Arguments or Options.

In this format, the delimiters between command-line elements are whitespace characters and the end-of-line delimiter is the newline delimiter. This is a widely used (but not universal) convention.

A CLI can generally be considered as consisting of syntax and semantics. The syntax is the grammar that all commands must follow. In the case of operating systems, DOS and Unix each define their own set of rules that all commands must follow. In the case of embedded systems, each vendor, such as Nortel, Juniper Networks or Cisco Systems, defines their own proprietary set of rules. These rules also dictate how a user navigates through the system of commands. The semantics define what sort of operations are possible, on what sort of data these operations can be performed, and how the grammar represents these operations and data—the symbolic meaning in the syntax.

Two different CLIs may agree on either syntax or semantics, but it is only when they agree on both that they can be considered sufficiently similar to allow users to use both CLIs without needing to learn anything, as well as to enable re-use of scripts.

A simple CLI will display a prompt, accept a «command line» typed by the user terminated by the Enter key, then execute the specified command and provide textual display of results or error messages. Advanced CLIs will validate, interpret and parameter-expand the command line before executing the specified command, and optionally capture or redirect its output.

Unlike a button or menu item in a GUI, a command line is typically self-documenting, stating exactly what the user wants done. In addition, command lines usually include many defaults that can be changed to customize the results. Useful command lines can be saved by assigning a character string or alias to represent the full command, or several commands can be grouped to perform a more complex sequence – for instance, compile the program, install it, and run it — creating a single entity, called a command procedure or script which itself can be treated as a command. These advantages mean that a user must figure out a complex command or series of commands only once, because they can be saved, to be used again.

The commands given to a CLI shell are often in one of the following forms:

• doSomething how toFiles
• doSomething how sourceFile destinationFile
• doSomething how < inputFile > outputFile
• doSomething how | doSomething how | doSomething how > outputFile

where doSomething is, in effect, a verb, how an adverb (for example, should the command be executed «verbosely» or «quietly») and toFiles an object or objects (typically one or more files) on which the command should act. The > in the third example is a redirection operator, telling the command-line interpreter to send the output of the command not to its own standard output (the screen) but to the named file. This will overwrite the file. Using >> will redirect the output and append it to the file. Another redirection operator is the vertical bar (|), which creates a pipeline where the output of one command becomes the input to the next command.

CLI and resource protection[edit]

One can modify the set of available commands by modifying which paths appear in the PATH environment variable. Under Unix, commands also need be marked as executable files. The directories in the path variable are searched in the order they are given. By re-ordering the path, one can run e.g. OS2MDOSE.EXE instead of OS2E.EXE, when the default is the opposite. Renaming of the executables also works: people often rename their favourite editor to EDIT, for example.

The command line allows one to restrict available commands, such as access to advanced internal commands. The Windows CMD.EXE does this. Often, shareware programs will limit the range of commands, including printing a command ‘your administrator has disabled running batch files’ from the prompt.^{[clarification needed]}

Some CLIs, such as those in network routers, have a hierarchy of modes, with a different set of commands supported in each mode. The set of commands are grouped by association with security, system, interface, etc. In these systems the user might traverse through a series of sub-modes. For example, if the CLI had two modes called interface and system, the user might use the command interface to enter the interface mode. At this point, commands from the system mode may not be accessible until the user exits the interface mode and enters the system mode.

Command prompt[edit]

«Command prompt» redirects here. For the Windows component named Command Prompt, see cmd.exe.

A command prompt (or just prompt) is a sequence of (one or more) characters used in a command-line interface to indicate readiness to accept commands. It literally prompts the user to take action. A prompt usually ends with one of the characters $, %, #,^[8][9] :, > or -^[10] and often includes other information, such as the path of the current working directory and the hostname.

On many Unix and derivative systems, the prompt commonly ends in $ or % if the user is a normal user, but in # if the user is a superuser («root» in Unix terminology).

End-users can often modify prompts. Depending on the environment, they may include colors, special characters, and other elements (like variables and functions for the current time, user, shell number or working directory) in order, for instance, to make the prompt more informative or visually pleasing, to distinguish sessions on various machines, or to indicate the current level of nesting of commands. On some systems, special tokens in the definition of the prompt can be used to cause external programs to be called by the command-line interpreter while displaying the prompt.

In DOS’ COMMAND.COM and in Windows NT’s cmd.exe users can modify the prompt by issuing a PROMPT command or by directly changing the value of the corresponding %PROMPT% environment variable. The default of most modern systems, the C:> style is obtained, for instance, with PROMPT $P$G. The default of older DOS systems, C> is obtained by just PROMPT, although on some systems this produces the newer C:> style, unless used on floppy drives A: or B:; on those systems PROMPT $N$G can be used to override the automatic default and explicitly switch to the older style.

Many Unix systems feature the $PS1 variable (Prompt String 1),^[11] although other variables also may affect the prompt (depending on the shell used). In the Bash shell, a prompt of the form:

[time] user@host: work_dir $

could be set by issuing the command

export PS1='[t] u@H: W $'

In zsh the $RPROMPT variable controls an optional «prompt» on the right-hand side of the display. It is not a real prompt in that the location of text entry does not change. It is used to display information on the same line as the prompt, but right-justified.

In RISC OS the command prompt is a * symbol, and thus (OS) CLI commands are often referred to as «star commands».^[12] One can also access the same commands from other command lines (such as the BBC BASIC command line), by preceding the command with a *.

Arguments[edit]

A command-line argument or parameter is an item of information provided to a program when it is started. A program can have many command-line arguments that identify sources or destinations of information, or that alter the operation of the program.

When a command processor is active a program is typically invoked by typing its name followed by command-line arguments (if any). For example, in Unix and Unix-like environments, an example of a command-line argument is:

«file.s» is a command-line argument which tells the program rm to remove the file «file.s».

Some programming languages, such as C, C++ and Java, allow a program to interpret the command-line arguments by handling them as string parameters in the main function. Other languages, such as Python, expose operating system specific API (functionality) through sys module, and in particular sys.argv for «command-line arguments».

In Unix-like operating systems, a single hyphen used in place of a file name is a special value specifying that a program should handle data coming from the standard input or send data to the standard output.

Command-line option[edit]

A command-line option or simply option (also known as a flag or switch) modifies the operation of a command; the effect is determined by the command’s program. Options follow the command name on the command line, separated by spaces. A space before the first option is not always required, such as Dir/? and DIR /? in DOS, which have the same effect^[10] of listing the DIR command’s available options, whereas dir --help (in many versions of Unix) does require the option to be preceded by at least one space (and is case-sensitive).

The format of options varies widely between operating systems. In most cases the syntax is by convention rather than an operating system requirement; the entire command line is simply a string passed to a program, which can process it in any way the programmer wants, so long as the interpreter can tell where the command name ends and its arguments and options begin.

A few representative samples of command-line options, all relating to listing files in a directory, to illustrate some conventions:

Abbreviating commands[edit]

In Multics, command-line options and subsystem keywords may be abbreviated. This idea appears to derive from the PL/I programming language, with its shortened keywords (e.g., STRG for STRINGRANGE and DCL for DECLARE). For example, in the Multics «forum» subsystem, the -long_subject parameter can be abbreviated -lgsj. It is also common for Multics commands to be abbreviated, typically corresponding to the initial letters of the words that are strung together with underscores to form command names, such as the use of did for delete_iacl_dir.

In some other systems abbreviations are automatic, such as permitting enough of the first characters of a command name to uniquely identify it (such as SU as an abbreviation for SUPERUSER) while others may have some specific abbreviations pre-programmed (e.g. MD for MKDIR in COMMAND.COM) or user-defined via batch scripts and aliases (e.g. alias md mkdir in tcsh).

Option conventions in DOS, Windows, OS/2[edit]

On DOS, OS/2 and Windows, different programs called from their COMMAND.COM or CMD.EXE (or internal their commands) may use different syntax within the same operating system. For example:

• Options may be indicated by either of the «switch characters»: /, -, or either may be allowed. See below.
• They may or may not be case-sensitive.
• Sometimes options and their arguments are run together, sometimes separated by whitespace, and sometimes by a character, typically : or =; thus Prog -fFilename, Prog -f Filename, Prog -f:Filename, Prog -f=Filename.
• Some programs allow single-character options to be combined;^[10] others do not. The switch -fA may mean the same as -f -A,^[10] or it may be incorrect, or it may even be a valid but different parameter.

In DOS, OS/2 and Windows, the forward slash (/) is most prevalent, although the hyphen-minus is also sometimes used. In many versions of DOS (MS-DOS/PC DOS 2.xx and higher, all versions of DR-DOS since 5.0, as well as PTS-DOS, Embedded DOS, FreeDOS and RxDOS) the switch character (sometimes abbreviated switchar or switchchar) to be used is defined by a value returned from a system call (INT 21h/AX=3700h). The default character returned by this API is /, but can be changed to a hyphen-minus on the above-mentioned systems, except for under Datalight ROM-DOS and MS-DOS/PC DOS 5.0 and higher, which always return / from this call (unless one of many available TSRs to reenable the SwitChar feature is loaded). In some of these systems (MS-DOS/PC DOS 2.xx, DOS Plus 2.1, DR-DOS 7.02 and higher, PTS-DOS, Embedded DOS, FreeDOS and RxDOS), the setting can also be pre-configured by a SWITCHAR directive in CONFIG.SYS. General Software’s Embedded DOS provides a SWITCH command for the same purpose, whereas 4DOS allows the setting to be changed via SETDOS /W:n.^[13] Under DR-DOS, if the setting has been changed from /, the first directory separator in the display of the PROMPT parameter $G will change to a forward slash / (which is also a valid directory separator in DOS, FlexOS, 4680 OS, 4690 OS, OS/2 and Windows) thereby serving as a visual clue to indicate the change.^[10] Also, the current setting is reflected also in the built-in help screens.^[10] Some versions of DR-DOS COMMAND.COM also support a PROMPT token $/ to display the current setting. COMMAND.COM since DR-DOS 7.02 also provides a pseudo-environment variable named %/% to allow portable batchjobs to be written.^[14][15] Several external DR-DOS commands additionally support an environment variable %SWITCHAR% to override the system setting.

However, many programs are hardwired to use / only, rather than retrieving the switch setting before parsing command-line arguments. A very small number, mainly ports from Unix-like systems, are programmed to accept «-» even if the switch character is not set to it (for example netstat and ping, supplied with Microsoft Windows, will accept the /? option to list available options, and yet the list will specify the «-» convention).

Option conventions in Unix-like systems[edit]

In Unix-like systems, the ASCII hyphen-minus begins options; the new (and GNU) convention is to use two hyphens then a word (e.g. --create) to identify the option’s use while the old convention (and still available as an option for frequently-used options) is to use one hyphen then one letter (e.g., -c); if one hyphen is followed by two or more letters it may mean two options are being specified, or it may mean the second and subsequent letters are a parameter (such as filename or date) for the first option.^[16]

Two hyphen-minus characters without following letters (--) may indicate that the remaining arguments should not be treated as options, which is useful for example if a file name itself begins with a hyphen, or if further arguments are meant for an inner command (e.g., sudo). Double hyphen-minuses are also sometimes used to prefix «long options» where more descriptive option names are used. This is a common feature of GNU software. The getopt function and program, and the getopts command are usually used for parsing command-line options.

Unix command names, arguments and options are case-sensitive (except in a few examples, mainly where popular commands from other operating systems have been ported to Unix).

Option conventions in other systems[edit]

FlexOS, 4680 OS and 4690 OS use -.

CP/M typically used [.

Conversational Monitor System (CMS) uses a single left parenthesis to separate options at the end of the command from the other arguments. For example, in the following command the options indicate that the target file should be replaced if it exists, and the date and time of the source file should be retained on the copy:
COPY source file a target file b (REPLACE OLDDATE

Data General’s CLI under their RDOS, AOS, etc. operating systems, as well as the version of CLI that came with their Business Basic, uses only / as the switch character, is case-insensitive, and allows «local switches» on some arguments to control the way they are interpreted, such as MAC/U LIB/S A B C $LPT/L has the global option «U» to the macro assembler command to append user symbols, but two local switches, one to specify LIB should be skipped on pass 2 and the other to direct listing to the printer, $LPT.

Built-in usage help[edit]

One of the criticisms of a CLI is the lack of cues to the user as to the available actions.^{[citation needed]} In contrast, GUIs usually inform the user of available actions with menus, icons, or other visual cues.^{[citation needed]} To overcome this limitation, many CLI programs display a usage message, typically when invoked with no arguments or one of ?, -?, -h, -H, /?, /h, /H, /Help, -help, or --help.^[10][17][18]

However, entering a program name without parameters in the hope that it will display usage help can be hazardous, as programs and scripts for which command line arguments are optional will execute without further notice.

Although desirable at least for the help parameter, programs may not support all option lead-in characters exemplified above.
Under DOS, where the default command-line option character can be changed from / to -, programs may query the SwitChar API in order to determine the current setting. So, if a program is not hardwired to support them all, a user may need to know the current setting even to be able to reliably request help.
If the SwitChar has been changed to - and therefore the / character is accepted as alternative path delimiter also at the DOS command line, programs may misinterpret options like /h or /H as paths rather than help parameters.^[10] However, if given as first or only parameter, most DOS programs will, by convention, accept it as request for help regardless of the current SwitChar setting.^[10][13]

In some cases, different levels of help can be selected for a program. Some programs supporting this allow to give a verbosity level as an optional argument to the help parameter (as in /H:1, /H:2, etc.) or they give just a short help on help parameters with question mark and a longer help screen for the other help options.^[19]

Depending on the program, additional or more specific help on accepted parameters is sometimes available by either providing the parameter in question as an argument to the help parameter or vice versa (as in /H:W or in /W:? (assuming /W would be another parameter supported by the program)).^{[20][21][18][17][19][nb 1]}

In a similar fashion to the help parameter, but much less common, some programs provide additional information about themselves (like mode, status, version, author, license or contact information) when invoked with an «about» parameter like -!, /!, -about, or --about.^[17]

Since the ? and ! characters typically also serve other purposes at the command line, they may not be available in all scenarios, therefore, they should not be the only options to access the corresponding help information.

If more detailed help is necessary than provided by a program’s built-in internal help, many systems support a dedicated external «help command» command (or similar), which accepts a command name as calling parameter and will invoke an external help system.

In the DR-DOS family, typing /? or /H at the COMMAND.COM prompt instead of a command itself will display a dynamically generated list of available internal commands;^[10] 4DOS and NDOS support the same feature by typing ? at the prompt^[13] (which is also accepted by newer versions of DR-DOS COMMAND.COM); internal commands can be individually disabled or reenabled via SETDOS /I.^[13] In addition to this, some newer versions of DR-DOS COMMAND.COM also accept a ?% command to display a list of available built-in pseudo-environment variables. Besides their purpose as quick help reference this can be used in batchjobs to query the facilities of the underlying command-line processor.^[10]

Command description syntax[edit]

Built-in usage help and man pages commonly employ a small syntax to describe the valid command form:^{[22][23][24][nb 2]}

• angle brackets for required parameters: ping <hostname>
• square brackets for optional parameters: mkdir [-p] <dirname>
• ellipses for repeated items: cp <source1> [source2…] <dest>
• vertical bars for choice of items: netstat {-t|-u}

Notice that these characters have different meanings than when used directly in the shell. Angle brackets may be omitted when confusing the parameter name with a literal string is not likely.

The space character[edit]

In many areas of computing, but particularly in the command line, the space character can cause problems as it has two distinct and incompatible functions: as part of a command or parameter, or as a parameter or name separator. Ambiguity can be prevented either by prohibiting embedded spaces in file and directory names in the first place (for example, by substituting them with underscores _), or by enclosing a name with embedded spaces between quote characters or using an escape character before the space, usually a backslash (). For example

Long path/Long program name Parameter one Parameter two …

is ambiguous (is «program name» part of the program name, or two parameters?); however

Long_path/Long_program_name Parameter_one Parameter_two …,

LongPath/LongProgramName ParameterOne ParameterTwo …,

"Long path/Long program name" "Parameter one" "Parameter two" …

and

Long path/Long program name Parameter one Parameter two …

are not ambiguous. Unix-based operating systems minimize the use of embedded spaces to minimize the need for quotes. In Microsoft Windows, one often has to use quotes because embedded spaces (such as in directory names) are common.

Command-line interpreter[edit]

Although most users think of the shell as an interactive command interpreter, it is really a programming language in which each statement runs a command. Because it must satisfy both the interactive and programming aspects of command execution, it is a strange language, shaped as much by history as by design.

The term command-line interpreter (CLI) is applied to computer programs designed to interpret a sequence of lines of text which may be entered by a user, read from a file or another kind of data stream. The context of interpretation is usually one of a given operating system or programming language.

Command-line interpreters allow users to issue various commands in a very efficient (and often terse) way. This requires the user to know the names of the commands and their parameters, and the syntax of the language that is interpreted.

The Unix #! mechanism and OS/2 EXTPROC command facilitate the passing of batch files to external processors. One can use these mechanisms to write specific command processors for dedicated uses, and process external data files which reside in batch files.

Many graphical interfaces, such as the OS/2 Presentation Manager and early versions of Microsoft Windows use command-lines to call helper programs to open documents and programs. The commands are stored in the graphical shell^{[clarification needed]} or in files like the registry or the OS/2 OS2USER.INI file.

Early history[edit]

The earliest computers did not support interactive input/output devices, often relying on sense switches and lights to communicate with the computer operator. This was adequate for batch systems that ran one program at a time, often with the programmer acting as operator. This also had the advantage of low overhead, since lights and switches could be tested and set with one machine instruction. Later a single system console was added to allow the operator to communicate with the system.

From the 1960s onwards, user interaction with computers was primarily by means of command-line interfaces, initially on machines like the Teletype Model 33 ASR, but then on early CRT-based computer terminals such as the VT52.

All of these devices were purely text based, with no ability to display graphic or pictures.^{[nb 3]} For business application programs, text-based menus were used, but for more general interaction the command line was the interface.

Around 1964 Louis Pouzin introduced the concept and the name shell in Multics, building on earlier, simpler facilities in the Compatible Time-Sharing System (CTSS).^{[26][better source needed]}

From the early 1970s the Unix operating system adapted the concept of a powerful command-line environment, and introduced the ability to pipe the output of one command in as input to another. Unix also had the capability to save and re-run strings of commands as «shell scripts» which acted like custom commands.

The command-line was also the main interface for the early home computers such as the Commodore PET, Apple II and BBC Micro – almost always in the form of a BASIC interpreter. When more powerful business oriented microcomputers arrived with CP/M and later DOS computers such as the IBM PC, the command-line began to borrow some of the syntax and features of the Unix shells such as globbing and piping of output.

The command-line was first seriously challenged by the PARC GUI approach used in the 1983 Apple Lisa and the 1984 Apple Macintosh. A few computer users used GUIs such as GEOS and Windows 3.1 but the majority of IBM PC users did not replace their COMMAND.COM shell with a GUI until Windows 95 was released in 1995.^[27][28]

Modern usage as an operating system shell[edit]

While most non-expert computer users now use a GUI almost exclusively, more advanced users have access to powerful command-line environments:

• The default VAX/VMS command shell, using the DCL language, has been ported to Windows systems at least three times, including PC-DCL and Acceler8 DCL Lite. Unix command shells have been ported to VMS and DOS/Windows 95 and Windows NT types of operating systems.
• COMMAND.COM is the command-line interpreter of MS-DOS, IBM PC DOS, and clones such as DR-DOS, SISNE plus, PTS-DOS, ROM-DOS, and FreeDOS.
• Windows Resource Kit and Windows Services for UNIX include Korn and the Bourne shells along with a Perl interpreter (Services for UNIX contains ActiveState ActivePerl in later versions and Interix for versions 1 and 2 and a shell compiled by Microsoft)
• IBM OS/2 (and derivatives such as eComStation and ArcaOS) has the cmd.exe processor. This copies the COMMAND.COM commands, with extensions to REXX.
• cmd.exe is part of the Windows NT stream of operating systems.
• Yet another cmd.exe is a stripped-down shell for Windows CE 3.0.
• An MS-DOS type interpreter called PocketDOS has been ported to Windows CE machines; the most recent release is almost identical to MS-DOS 6.22 and can also run Windows 1, 2, and 3.0, QBasic and other development tools, 4NT and 4DOS. The latest release includes several shells, namely MS-DOS 6.22, PC DOS 7, DR DOS 3.xx, and others.
• Windows users might use the CScript interface to alternate programs, from command-line. PowerShell provides a command-line interface, but its applets are not written in Shell script. Implementations of the Unix shell are also available as part of the POSIX sub-system,^[29] Cygwin, MKS Toolkit, UWIN, Hamilton C shell and other software packages. Available shells for these interoperability tools include csh, ksh, sh, Bash, rsh, tclsh and less commonly zsh, psh
• Implementations of PHP have a shell for interactive use called php-cli.
• Standard Tcl/Tk has two interactive shells, Tclsh and Wish, the latter being the GUI version.
• Python, Ruby, Lua, XLNT, and other interpreters also have command shells for interactive use.
• FreeBSD uses tcsh as its default interactive shell for the superuser, and ash as default scripting shell.
• Many Linux distributions have the Bash implementation of the Unix shell.
• Apple macOS and some Linux distributions use zsh. Previously, macOS used tcsh and Bash.
• Embedded Linux (and other embedded Unix-like) devices often use the Ash implementation of the Unix shell, as part of Busybox.
• Android uses the mksh shell,^[30][31] which replaces a shell derived from ash^[32] that was used in older Android versions, supplemented with commands from the separate toolbox^[33] binary.
• Routers with Cisco IOS,^[34] Junos^[35] and many others are commonly configured from the command line.
• The Plan 9 operating system uses the rc shell which is similar in design to the Bourne shell.

Scripting[edit]

Most command-line interpreters support scripting, to various extents. (They are, after all, interpreters of an interpreted programming language, albeit in many cases the language is unique to the particular command-line interpreter.) They will interpret scripts (variously termed shell scripts or batch files) written in the language that they interpret. Some command-line interpreters also incorporate the interpreter engines of other languages, such as REXX, in addition to their own, allowing the executing of scripts, in those languages, directly within the command-line interpreter itself.

Conversely, scripting programming languages, in particular those with an eval function (such as REXX, Perl, Python, Ruby or Jython), can be used to implement command-line interpreters and filters. For a few operating systems, most notably DOS, such a command interpreter provides a more flexible command-line interface than the one supplied. In other cases, such a command interpreter can present a highly customised user interface employing the user interface and input/output facilities of the language.

Other command-line interfaces[edit]

The command line provides an interface between programs as well as the user. In this sense, a command line is an alternative to a dialog box. Editors and databases present a command line, in which alternate command processors might run. On the other hand, one might have options on the command line, which opens a dialog box. The latest version of ‘Take Command’ has this feature. DBase used a dialog box to construct command lines, which could be further edited before use.

Programs like BASIC, diskpart, Edlin, and QBASIC all provide command-line interfaces, some of which use the system shell. Basic is modeled on the default interface for 8-bit Intel computers. Calculators can be run as command-line or dialog interfaces.

Emacs provides a command-line interface in the form of its minibuffer. Commands and arguments can be entered using Emacs standard text editing support, and output is displayed in another buffer.

There are a number of text mode games, like Adventure or King’s Quest 1-3, which relied on the user typing commands at the bottom of the screen. One controls the character by typing commands like ‘get ring’ or ‘look’. The program returns a text which describes how the character sees it, or makes the action happen. The text adventure The Hitchhiker’s Guide to the Galaxy, a piece of interactive fiction based on Douglas Adam’s book of the same name, is a teletype-style command-line game.

The most notable of these interfaces is the standard streams interface, which allows the output of one command to be passed to the input of another. Text files can serve either purpose as well. This provides the interfaces of piping, filters and redirection. Under Unix, devices are files too, so the normal type of file for the shell used for stdin,stdout and stderr is a tty device file.

Another command-line interface allows a shell program to launch helper programs, either to launch documents or start a program. The command is processed internally by the shell, and then passed on to another program to launch the document. The graphical interface of Windows and OS/2 rely heavily on command-lines passed through to other programs – console or graphical, which then usually process the command line without presenting a user-console.

Programs like the OS/2 E editor and some other IBM editors, can process command-lines normally meant for the shell, the output being placed directly in the document window.

A web browser’s URL input field can be used as a command line. It can be used to «launch» web apps, access browser configuration, as well as perform a search. Google, which has been called «the command line of the internet» will perform a domain-specific search when it detects search parameters in a known format.^[36] This functionality is present whether the search is triggered from a browser field or on Google’s website.

There are JavaScript libraries that allow to write command line applications in browser as standalone Web apps or as part of bigger application.^[37] An example of such a website is the CLI interface to DuckDuckGo.^[38] There are also Web-based SSH applications, that allow to give access to server command line interface from a browser.

Many video games on the PC feature a command line interface often referred to as a console. It is typically used by the game developers during development and by mod developers for debugging purposes as well as for cheating or skipping parts of the game.

See also[edit]

• Comparison of command shells
• List of command-line interpreters
• Console application
• Interpreter directive
• Read-eval-print loop
• Shell script
• Run command
• Graphical user interface § Comparison to other interfaces
• In the Beginning… Was the Command Line

Notes[edit]

References[edit]

External links[edit]

• The Roots of DOS David Hunter, Softalk for the IBM Personal Computer March 1983. Archived at Patersontech.com since 2000.
• Command-Line Reference: Microsoft TechNet Database «Command-Line Reference»

A command-line interpreter or command-line processor uses a command-line interface (CLI) to receive commands from a user in the form of lines of text. This provides a means of setting parameters for the environment, invoking executables and providing information to them as to what actions they are to perform. In some cases the invocation is conditional based on conditions established by the user or previous executables. Such access was first provided by computer terminals starting in the mid-1960s. This provided an interactive environment not available with punched cards or other input methods.

Today, many users rely upon graphical user interfaces and menu-driven interactions. However, some programming and maintenance tasks may not have a graphical user interface and use a command line.

Alternatives to the command-line interface include text-based user interface menus (for example, IBM AIX SMIT), keyboard shortcuts, and various desktop metaphors centered on the pointer (usually controlled with a mouse). Examples of this include the Microsoft Windows, DOS Shell, and Mouse Systems PowerPanel. Command-line interfaces are often implemented in terminal devices that are also capable of screen-oriented text-based user interfaces that use cursor addressing to place symbols on a display screen.

Programs with command-line interfaces are generally easier to automate via scripting.

Many software systems implement command-line interfaces for control and operation. This includes programming environments and utility programs.

Comparison to graphical user interfaces[edit]

Compared with a graphical user interface, a command-line interface requires fewer system resources to implement. Since options to commands are given in a few characters in each command line, an experienced user often finds the options easier to access. Automation of repetitive tasks is simplified by line editing and history mechanisms for storing frequently used sequences; this may extend to a scripting language that can take parameters and variable options. A command-line history can be kept, allowing review or repetition of commands.

A command-line system may require paper or online manuals for the user’s reference, although often a «help» option provides a concise review of the options of a command. The command-line environment may not provide graphical enhancements such as different fonts or extended edit windows found in a GUI. It may be difficult for a new user to become familiar with all the commands and options available, compared with the icons and drop-down menus of a graphical user interface, without reference to manuals.

Types[edit]

Operating system command-line interfaces[edit]

Operating system (OS) command-line interfaces are usually distinct programs supplied with the operating system. A program that implements such a text interface is often called a command-line interpreter, command processor or shell.

Examples of command-line interpreters include DEC’s DIGITAL Command Language (DCL) in OpenVMS and RSX-11, the various Unix shells (sh, ksh, csh, tcsh, zsh, Bash, etc.), CP/M’s CCP, DOS’ COMMAND.COM, as well as the OS/2 and the Windows CMD.EXE programs, the latter groups being based heavily on DEC’s RSX-11 and RSTS CLIs. Under most operating systems, it is possible to replace the default shell program with alternatives; examples include 4DOS for DOS, 4OS2 for OS/2, and 4NT / Take Command for Windows.

Although the term ‘shell’ is often used to describe a command-line interpreter, strictly speaking, a ‘shell’ can be any program that constitutes the user-interface, including fully graphically oriented ones. For example, the default Windows GUI is a shell program named EXPLORER.EXE, as defined in the SHELL=EXPLORER.EXE line in the WIN.INI configuration file. These programs are shells, but not CLIs.

Application command-line interfaces[edit]

Application programs (as opposed to operating systems) may also have command-line interfaces.

An application program may support none, any, or all of these three major types of command-line interface mechanisms:

• Parameters: Most command-line interfaces support a means to pass additional information to a program when it is launched.
• Interactive command-line sessions: After launch, a program may provide an operator with an independent means to enter commands.
• Inter-process communication: Most operating systems support means of inter-process communication (for example, standard streams or named pipes). Command lines from client processes may be redirected to a CLI program by one of these methods.

Some applications support a CLI, presenting their own prompt to the user and accepting command lines. Other programs support both a CLI and a GUI. In some cases, a GUI is simply a wrapper around a separate CLI executable file. In other cases, a program may provide a CLI as an optional alternative to its GUI. CLIs and GUIs often support different functionality. For example, all features of MATLAB, a numerical analysis computer program, are available via the CLI, whereas the MATLAB GUI exposes only a subset of features.

In Colossal Cave Adventure from 1975, the user uses a CLI to enter one or two words to explore a cave system.

History[edit]

The command-line interface evolved from a form of communication conducted by people over teleprinter (TTY) machines. Sometimes these involved sending an order or a confirmation using telex. Early computer systems often used teleprinter as the means of interaction with an operator.

The mechanical teleprinter was replaced by a «glass tty», a keyboard and screen emulating the teleprinter. «Smart» terminals permitted additional functions, such as cursor movement over the entire screen, or local editing of data on the terminal for transmission to the computer. As the microcomputer revolution replaced the traditional – minicomputer + terminals – time sharing architecture, hardware terminals were replaced by terminal emulators — PC software that interpreted terminal signals sent through the PC’s serial ports. These were typically used to interface an organization’s new PC’s with their existing mini- or mainframe computers, or to connect PC to PC. Some of these PCs were running Bulletin Board System software.

Early operating system CLIs were implemented as part of resident monitor programs, and could not easily be replaced. The first implementation of the shell as a replaceable component was part of the Multics time-sharing operating system.^[1] In 1964, MIT Computation Center staff member Louis Pouzin developed the RUNCOM tool for executing command scripts while allowing argument substitution.^[2] Pouzin coined the term «shell» to describe the technique of using commands like a programming language, and wrote a paper about how to implement the idea in the Multics operating system.^[3] Pouzin returned to his native France in 1965, and the first Multics shell was developed by Glenda Schroeder.^[2]

The first Unix shell, the V6 shell, was developed by Ken Thompson in 1971 at Bell Labs and was modeled after Schroeder’s Multics shell.^[4][5] The Bourne shell was introduced in 1977 as a replacement for the V6 shell. Although it is used as an interactive command interpreter, it was also intended as a scripting language and contains most of the features that are commonly considered to produce structured programs. The Bourne shell led to the development of the KornShell (ksh), Almquist shell (ash), and the popular Bourne-again shell (or Bash).^[5]

Early microcomputers themselves were based on a command-line interface such as CP/M, DOS or AppleSoft BASIC. During the 1980s and 1990s, the introduction of the Apple Macintosh and of Microsoft Windows on PCs saw the command line interface as the primary user interface replaced by the Graphical User Interface. The command line remained available as an alternative user interface, often used by system administrators and other advanced users for system administration, computer programming and batch processing.

In November 2006, Microsoft released version 1.0 of Windows PowerShell (formerly codenamed Monad), which combined features of traditional Unix shells with their proprietary object-oriented .NET Framework. MinGW and Cygwin are open-source packages for Windows that offer a Unix-like CLI. Microsoft provides MKS Inc.’s ksh implementation MKS Korn shell for Windows through their Services for UNIX add-on.

Since 2001, the Macintosh operating system macOS has been based on a Unix-like operating system called Darwin. On these computers, users can access a Unix-like command-line interface by running the terminal emulator program called Terminal, which is found in the Utilities sub-folder of the Applications folder, or by remotely logging into the machine using ssh. Z shell is the default shell for macOS; Bash, tcsh, and the KornShell are also provided. Before macOS Catalina, Bash was the default.

Usage[edit]

A CLI is used whenever a large vocabulary of commands or queries, coupled with a wide (or arbitrary) range of options, can be entered more rapidly as text than with a pure GUI. This is typically the case with operating system command shells. CLIs are also used by systems with insufficient resources to support a graphical user interface. Some computer language systems (such as Python, Forth, LISP, Rexx, and many dialects of BASIC) provide an interactive command-line mode to allow for rapid evaluation of code.

CLIs are often used by programmers and system administrators, in engineering and scientific environments, and by technically advanced personal computer users. CLIs are also popular among people with visual disabilities since the commands and responses can be displayed using refreshable Braille displays.

Anatomy of a shell CLI[edit]

The general pattern of a command line interface^[6][7] is:

Prompt command param1 param2 param3 … paramN

• Prompt — generated by the program to provide context for the user.
• Command — provided by the user. Commands are usually one of three classes:
  1. Internal commands are recognized and processed by the command line interpreter.
  2. Included commands run separate executables.
  3. External commands run executable files that may be included by other parties.
• param1 …paramN — parameters provided by the user. The format and meaning of the parameters depends upon the command. In the case of Included or External commands, the values of the parameters are delivered to the program as it is launched by the OS. Parameters may be either Arguments or Options.

In this format, the delimiters between command-line elements are whitespace characters and the end-of-line delimiter is the newline delimiter. This is a widely used (but not universal) convention.

A CLI can generally be considered as consisting of syntax and semantics. The syntax is the grammar that all commands must follow. In the case of operating systems, DOS and Unix each define their own set of rules that all commands must follow. In the case of embedded systems, each vendor, such as Nortel, Juniper Networks or Cisco Systems, defines their own proprietary set of rules. These rules also dictate how a user navigates through the system of commands. The semantics define what sort of operations are possible, on what sort of data these operations can be performed, and how the grammar represents these operations and data—the symbolic meaning in the syntax.

Two different CLIs may agree on either syntax or semantics, but it is only when they agree on both that they can be considered sufficiently similar to allow users to use both CLIs without needing to learn anything, as well as to enable re-use of scripts.

A simple CLI will display a prompt, accept a «command line» typed by the user terminated by the Enter key, then execute the specified command and provide textual display of results or error messages. Advanced CLIs will validate, interpret and parameter-expand the command line before executing the specified command, and optionally capture or redirect its output.

Unlike a button or menu item in a GUI, a command line is typically self-documenting, stating exactly what the user wants done. In addition, command lines usually include many defaults that can be changed to customize the results. Useful command lines can be saved by assigning a character string or alias to represent the full command, or several commands can be grouped to perform a more complex sequence – for instance, compile the program, install it, and run it — creating a single entity, called a command procedure or script which itself can be treated as a command. These advantages mean that a user must figure out a complex command or series of commands only once, because they can be saved, to be used again.

The commands given to a CLI shell are often in one of the following forms:

• doSomething how toFiles
• doSomething how sourceFile destinationFile
• doSomething how < inputFile > outputFile
• doSomething how | doSomething how | doSomething how > outputFile

where doSomething is, in effect, a verb, how an adverb (for example, should the command be executed «verbosely» or «quietly») and toFiles an object or objects (typically one or more files) on which the command should act. The > in the third example is a redirection operator, telling the command-line interpreter to send the output of the command not to its own standard output (the screen) but to the named file. This will overwrite the file. Using >> will redirect the output and append it to the file. Another redirection operator is the vertical bar (|), which creates a pipeline where the output of one command becomes the input to the next command.

CLI and resource protection[edit]

One can modify the set of available commands by modifying which paths appear in the PATH environment variable. Under Unix, commands also need be marked as executable files. The directories in the path variable are searched in the order they are given. By re-ordering the path, one can run e.g. OS2MDOSE.EXE instead of OS2E.EXE, when the default is the opposite. Renaming of the executables also works: people often rename their favourite editor to EDIT, for example.

The command line allows one to restrict available commands, such as access to advanced internal commands. The Windows CMD.EXE does this. Often, shareware programs will limit the range of commands, including printing a command ‘your administrator has disabled running batch files’ from the prompt.^{[clarification needed]}

Some CLIs, such as those in network routers, have a hierarchy of modes, with a different set of commands supported in each mode. The set of commands are grouped by association with security, system, interface, etc. In these systems the user might traverse through a series of sub-modes. For example, if the CLI had two modes called interface and system, the user might use the command interface to enter the interface mode. At this point, commands from the system mode may not be accessible until the user exits the interface mode and enters the system mode.

Command prompt[edit]

«Command prompt» redirects here. For the Windows component named Command Prompt, see cmd.exe.

A command prompt (or just prompt) is a sequence of (one or more) characters used in a command-line interface to indicate readiness to accept commands. It literally prompts the user to take action. A prompt usually ends with one of the characters $, %, #,^[8][9] :, > or -^[10] and often includes other information, such as the path of the current working directory and the hostname.

On many Unix and derivative systems, the prompt commonly ends in $ or % if the user is a normal user, but in # if the user is a superuser («root» in Unix terminology).

End-users can often modify prompts. Depending on the environment, they may include colors, special characters, and other elements (like variables and functions for the current time, user, shell number or working directory) in order, for instance, to make the prompt more informative or visually pleasing, to distinguish sessions on various machines, or to indicate the current level of nesting of commands. On some systems, special tokens in the definition of the prompt can be used to cause external programs to be called by the command-line interpreter while displaying the prompt.

In DOS’ COMMAND.COM and in Windows NT’s cmd.exe users can modify the prompt by issuing a PROMPT command or by directly changing the value of the corresponding %PROMPT% environment variable. The default of most modern systems, the C:> style is obtained, for instance, with PROMPT $P$G. The default of older DOS systems, C> is obtained by just PROMPT, although on some systems this produces the newer C:> style, unless used on floppy drives A: or B:; on those systems PROMPT $N$G can be used to override the automatic default and explicitly switch to the older style.

Many Unix systems feature the $PS1 variable (Prompt String 1),^[11] although other variables also may affect the prompt (depending on the shell used). In the Bash shell, a prompt of the form:

[time] user@host: work_dir $

could be set by issuing the command

export PS1='[t] u@H: W $'

In zsh the $RPROMPT variable controls an optional «prompt» on the right-hand side of the display. It is not a real prompt in that the location of text entry does not change. It is used to display information on the same line as the prompt, but right-justified.

In RISC OS the command prompt is a * symbol, and thus (OS) CLI commands are often referred to as «star commands».^[12] One can also access the same commands from other command lines (such as the BBC BASIC command line), by preceding the command with a *.

Arguments[edit]

A command-line argument or parameter is an item of information provided to a program when it is started. A program can have many command-line arguments that identify sources or destinations of information, or that alter the operation of the program.

When a command processor is active a program is typically invoked by typing its name followed by command-line arguments (if any). For example, in Unix and Unix-like environments, an example of a command-line argument is:

«file.s» is a command-line argument which tells the program rm to remove the file «file.s».

Some programming languages, such as C, C++ and Java, allow a program to interpret the command-line arguments by handling them as string parameters in the main function. Other languages, such as Python, expose operating system specific API (functionality) through sys module, and in particular sys.argv for «command-line arguments».

In Unix-like operating systems, a single hyphen used in place of a file name is a special value specifying that a program should handle data coming from the standard input or send data to the standard output.

Command-line option[edit]

A command-line option or simply option (also known as a flag or switch) modifies the operation of a command; the effect is determined by the command’s program. Options follow the command name on the command line, separated by spaces. A space before the first option is not always required, such as Dir/? and DIR /? in DOS, which have the same effect^[10] of listing the DIR command’s available options, whereas dir --help (in many versions of Unix) does require the option to be preceded by at least one space (and is case-sensitive).

The format of options varies widely between operating systems. In most cases the syntax is by convention rather than an operating system requirement; the entire command line is simply a string passed to a program, which can process it in any way the programmer wants, so long as the interpreter can tell where the command name ends and its arguments and options begin.

A few representative samples of command-line options, all relating to listing files in a directory, to illustrate some conventions:

Abbreviating commands[edit]

In Multics, command-line options and subsystem keywords may be abbreviated. This idea appears to derive from the PL/I programming language, with its shortened keywords (e.g., STRG for STRINGRANGE and DCL for DECLARE). For example, in the Multics «forum» subsystem, the -long_subject parameter can be abbreviated -lgsj. It is also common for Multics commands to be abbreviated, typically corresponding to the initial letters of the words that are strung together with underscores to form command names, such as the use of did for delete_iacl_dir.

In some other systems abbreviations are automatic, such as permitting enough of the first characters of a command name to uniquely identify it (such as SU as an abbreviation for SUPERUSER) while others may have some specific abbreviations pre-programmed (e.g. MD for MKDIR in COMMAND.COM) or user-defined via batch scripts and aliases (e.g. alias md mkdir in tcsh).

Option conventions in DOS, Windows, OS/2[edit]

On DOS, OS/2 and Windows, different programs called from their COMMAND.COM or CMD.EXE (or internal their commands) may use different syntax within the same operating system. For example:

• Options may be indicated by either of the «switch characters»: /, -, or either may be allowed. See below.
• They may or may not be case-sensitive.
• Sometimes options and their arguments are run together, sometimes separated by whitespace, and sometimes by a character, typically : or =; thus Prog -fFilename, Prog -f Filename, Prog -f:Filename, Prog -f=Filename.
• Some programs allow single-character options to be combined;^[10] others do not. The switch -fA may mean the same as -f -A,^[10] or it may be incorrect, or it may even be a valid but different parameter.

In DOS, OS/2 and Windows, the forward slash (/) is most prevalent, although the hyphen-minus is also sometimes used. In many versions of DOS (MS-DOS/PC DOS 2.xx and higher, all versions of DR-DOS since 5.0, as well as PTS-DOS, Embedded DOS, FreeDOS and RxDOS) the switch character (sometimes abbreviated switchar or switchchar) to be used is defined by a value returned from a system call (INT 21h/AX=3700h). The default character returned by this API is /, but can be changed to a hyphen-minus on the above-mentioned systems, except for under Datalight ROM-DOS and MS-DOS/PC DOS 5.0 and higher, which always return / from this call (unless one of many available TSRs to reenable the SwitChar feature is loaded). In some of these systems (MS-DOS/PC DOS 2.xx, DOS Plus 2.1, DR-DOS 7.02 and higher, PTS-DOS, Embedded DOS, FreeDOS and RxDOS), the setting can also be pre-configured by a SWITCHAR directive in CONFIG.SYS. General Software’s Embedded DOS provides a SWITCH command for the same purpose, whereas 4DOS allows the setting to be changed via SETDOS /W:n.^[13] Under DR-DOS, if the setting has been changed from /, the first directory separator in the display of the PROMPT parameter $G will change to a forward slash / (which is also a valid directory separator in DOS, FlexOS, 4680 OS, 4690 OS, OS/2 and Windows) thereby serving as a visual clue to indicate the change.^[10] Also, the current setting is reflected also in the built-in help screens.^[10] Some versions of DR-DOS COMMAND.COM also support a PROMPT token $/ to display the current setting. COMMAND.COM since DR-DOS 7.02 also provides a pseudo-environment variable named %/% to allow portable batchjobs to be written.^[14][15] Several external DR-DOS commands additionally support an environment variable %SWITCHAR% to override the system setting.

However, many programs are hardwired to use / only, rather than retrieving the switch setting before parsing command-line arguments. A very small number, mainly ports from Unix-like systems, are programmed to accept «-» even if the switch character is not set to it (for example netstat and ping, supplied with Microsoft Windows, will accept the /? option to list available options, and yet the list will specify the «-» convention).

Option conventions in Unix-like systems[edit]

In Unix-like systems, the ASCII hyphen-minus begins options; the new (and GNU) convention is to use two hyphens then a word (e.g. --create) to identify the option’s use while the old convention (and still available as an option for frequently-used options) is to use one hyphen then one letter (e.g., -c); if one hyphen is followed by two or more letters it may mean two options are being specified, or it may mean the second and subsequent letters are a parameter (such as filename or date) for the first option.^[16]

Two hyphen-minus characters without following letters (--) may indicate that the remaining arguments should not be treated as options, which is useful for example if a file name itself begins with a hyphen, or if further arguments are meant for an inner command (e.g., sudo). Double hyphen-minuses are also sometimes used to prefix «long options» where more descriptive option names are used. This is a common feature of GNU software. The getopt function and program, and the getopts command are usually used for parsing command-line options.

Unix command names, arguments and options are case-sensitive (except in a few examples, mainly where popular commands from other operating systems have been ported to Unix).

Option conventions in other systems[edit]

FlexOS, 4680 OS and 4690 OS use -.

CP/M typically used [.

Conversational Monitor System (CMS) uses a single left parenthesis to separate options at the end of the command from the other arguments. For example, in the following command the options indicate that the target file should be replaced if it exists, and the date and time of the source file should be retained on the copy:
COPY source file a target file b (REPLACE OLDDATE

Data General’s CLI under their RDOS, AOS, etc. operating systems, as well as the version of CLI that came with their Business Basic, uses only / as the switch character, is case-insensitive, and allows «local switches» on some arguments to control the way they are interpreted, such as MAC/U LIB/S A B C $LPT/L has the global option «U» to the macro assembler command to append user symbols, but two local switches, one to specify LIB should be skipped on pass 2 and the other to direct listing to the printer, $LPT.

Built-in usage help[edit]

One of the criticisms of a CLI is the lack of cues to the user as to the available actions.^{[citation needed]} In contrast, GUIs usually inform the user of available actions with menus, icons, or other visual cues.^{[citation needed]} To overcome this limitation, many CLI programs display a usage message, typically when invoked with no arguments or one of ?, -?, -h, -H, /?, /h, /H, /Help, -help, or --help.^[10][17][18]

However, entering a program name without parameters in the hope that it will display usage help can be hazardous, as programs and scripts for which command line arguments are optional will execute without further notice.

Although desirable at least for the help parameter, programs may not support all option lead-in characters exemplified above.
Under DOS, where the default command-line option character can be changed from / to -, programs may query the SwitChar API in order to determine the current setting. So, if a program is not hardwired to support them all, a user may need to know the current setting even to be able to reliably request help.
If the SwitChar has been changed to - and therefore the / character is accepted as alternative path delimiter also at the DOS command line, programs may misinterpret options like /h or /H as paths rather than help parameters.^[10] However, if given as first or only parameter, most DOS programs will, by convention, accept it as request for help regardless of the current SwitChar setting.^[10][13]

In some cases, different levels of help can be selected for a program. Some programs supporting this allow to give a verbosity level as an optional argument to the help parameter (as in /H:1, /H:2, etc.) or they give just a short help on help parameters with question mark and a longer help screen for the other help options.^[19]

Depending on the program, additional or more specific help on accepted parameters is sometimes available by either providing the parameter in question as an argument to the help parameter or vice versa (as in /H:W or in /W:? (assuming /W would be another parameter supported by the program)).^{[20][21][18][17][19][nb 1]}

In a similar fashion to the help parameter, but much less common, some programs provide additional information about themselves (like mode, status, version, author, license or contact information) when invoked with an «about» parameter like -!, /!, -about, or --about.^[17]

Since the ? and ! characters typically also serve other purposes at the command line, they may not be available in all scenarios, therefore, they should not be the only options to access the corresponding help information.

If more detailed help is necessary than provided by a program’s built-in internal help, many systems support a dedicated external «help command» command (or similar), which accepts a command name as calling parameter and will invoke an external help system.

In the DR-DOS family, typing /? or /H at the COMMAND.COM prompt instead of a command itself will display a dynamically generated list of available internal commands;^[10] 4DOS and NDOS support the same feature by typing ? at the prompt^[13] (which is also accepted by newer versions of DR-DOS COMMAND.COM); internal commands can be individually disabled or reenabled via SETDOS /I.^[13] In addition to this, some newer versions of DR-DOS COMMAND.COM also accept a ?% command to display a list of available built-in pseudo-environment variables. Besides their purpose as quick help reference this can be used in batchjobs to query the facilities of the underlying command-line processor.^[10]

Command description syntax[edit]

Built-in usage help and man pages commonly employ a small syntax to describe the valid command form:^{[22][23][24][nb 2]}

• angle brackets for required parameters: ping <hostname>
• square brackets for optional parameters: mkdir [-p] <dirname>
• ellipses for repeated items: cp <source1> [source2…] <dest>
• vertical bars for choice of items: netstat {-t|-u}

Notice that these characters have different meanings than when used directly in the shell. Angle brackets may be omitted when confusing the parameter name with a literal string is not likely.

The space character[edit]

In many areas of computing, but particularly in the command line, the space character can cause problems as it has two distinct and incompatible functions: as part of a command or parameter, or as a parameter or name separator. Ambiguity can be prevented either by prohibiting embedded spaces in file and directory names in the first place (for example, by substituting them with underscores _), or by enclosing a name with embedded spaces between quote characters or using an escape character before the space, usually a backslash (). For example

Long path/Long program name Parameter one Parameter two …

is ambiguous (is «program name» part of the program name, or two parameters?); however

Long_path/Long_program_name Parameter_one Parameter_two …,

LongPath/LongProgramName ParameterOne ParameterTwo …,

"Long path/Long program name" "Parameter one" "Parameter two" …

and

Long path/Long program name Parameter one Parameter two …

are not ambiguous. Unix-based operating systems minimize the use of embedded spaces to minimize the need for quotes. In Microsoft Windows, one often has to use quotes because embedded spaces (such as in directory names) are common.

Command-line interpreter[edit]

Although most users think of the shell as an interactive command interpreter, it is really a programming language in which each statement runs a command. Because it must satisfy both the interactive and programming aspects of command execution, it is a strange language, shaped as much by history as by design.

The term command-line interpreter (CLI) is applied to computer programs designed to interpret a sequence of lines of text which may be entered by a user, read from a file or another kind of data stream. The context of interpretation is usually one of a given operating system or programming language.

Command-line interpreters allow users to issue various commands in a very efficient (and often terse) way. This requires the user to know the names of the commands and their parameters, and the syntax of the language that is interpreted.

The Unix #! mechanism and OS/2 EXTPROC command facilitate the passing of batch files to external processors. One can use these mechanisms to write specific command processors for dedicated uses, and process external data files which reside in batch files.

Many graphical interfaces, such as the OS/2 Presentation Manager and early versions of Microsoft Windows use command-lines to call helper programs to open documents and programs. The commands are stored in the graphical shell^{[clarification needed]} or in files like the registry or the OS/2 OS2USER.INI file.

Early history[edit]

The earliest computers did not support interactive input/output devices, often relying on sense switches and lights to communicate with the computer operator. This was adequate for batch systems that ran one program at a time, often with the programmer acting as operator. This also had the advantage of low overhead, since lights and switches could be tested and set with one machine instruction. Later a single system console was added to allow the operator to communicate with the system.

From the 1960s onwards, user interaction with computers was primarily by means of command-line interfaces, initially on machines like the Teletype Model 33 ASR, but then on early CRT-based computer terminals such as the VT52.

All of these devices were purely text based, with no ability to display graphic or pictures.^{[nb 3]} For business application programs, text-based menus were used, but for more general interaction the command line was the interface.

Around 1964 Louis Pouzin introduced the concept and the name shell in Multics, building on earlier, simpler facilities in the Compatible Time-Sharing System (CTSS).^{[26][better source needed]}

From the early 1970s the Unix operating system adapted the concept of a powerful command-line environment, and introduced the ability to pipe the output of one command in as input to another. Unix also had the capability to save and re-run strings of commands as «shell scripts» which acted like custom commands.

The command-line was also the main interface for the early home computers such as the Commodore PET, Apple II and BBC Micro – almost always in the form of a BASIC interpreter. When more powerful business oriented microcomputers arrived with CP/M and later DOS computers such as the IBM PC, the command-line began to borrow some of the syntax and features of the Unix shells such as globbing and piping of output.

The command-line was first seriously challenged by the PARC GUI approach used in the 1983 Apple Lisa and the 1984 Apple Macintosh. A few computer users used GUIs such as GEOS and Windows 3.1 but the majority of IBM PC users did not replace their COMMAND.COM shell with a GUI until Windows 95 was released in 1995.^[27][28]

Modern usage as an operating system shell[edit]

While most non-expert computer users now use a GUI almost exclusively, more advanced users have access to powerful command-line environments:

• The default VAX/VMS command shell, using the DCL language, has been ported to Windows systems at least three times, including PC-DCL and Acceler8 DCL Lite. Unix command shells have been ported to VMS and DOS/Windows 95 and Windows NT types of operating systems.
• COMMAND.COM is the command-line interpreter of MS-DOS, IBM PC DOS, and clones such as DR-DOS, SISNE plus, PTS-DOS, ROM-DOS, and FreeDOS.
• Windows Resource Kit and Windows Services for UNIX include Korn and the Bourne shells along with a Perl interpreter (Services for UNIX contains ActiveState ActivePerl in later versions and Interix for versions 1 and 2 and a shell compiled by Microsoft)
• IBM OS/2 (and derivatives such as eComStation and ArcaOS) has the cmd.exe processor. This copies the COMMAND.COM commands, with extensions to REXX.
• cmd.exe is part of the Windows NT stream of operating systems.
• Yet another cmd.exe is a stripped-down shell for Windows CE 3.0.
• An MS-DOS type interpreter called PocketDOS has been ported to Windows CE machines; the most recent release is almost identical to MS-DOS 6.22 and can also run Windows 1, 2, and 3.0, QBasic and other development tools, 4NT and 4DOS. The latest release includes several shells, namely MS-DOS 6.22, PC DOS 7, DR DOS 3.xx, and others.
• Windows users might use the CScript interface to alternate programs, from command-line. PowerShell provides a command-line interface, but its applets are not written in Shell script. Implementations of the Unix shell are also available as part of the POSIX sub-system,^[29] Cygwin, MKS Toolkit, UWIN, Hamilton C shell and other software packages. Available shells for these interoperability tools include csh, ksh, sh, Bash, rsh, tclsh and less commonly zsh, psh
• Implementations of PHP have a shell for interactive use called php-cli.
• Standard Tcl/Tk has two interactive shells, Tclsh and Wish, the latter being the GUI version.
• Python, Ruby, Lua, XLNT, and other interpreters also have command shells for interactive use.
• FreeBSD uses tcsh as its default interactive shell for the superuser, and ash as default scripting shell.
• Many Linux distributions have the Bash implementation of the Unix shell.
• Apple macOS and some Linux distributions use zsh. Previously, macOS used tcsh and Bash.
• Embedded Linux (and other embedded Unix-like) devices often use the Ash implementation of the Unix shell, as part of Busybox.
• Android uses the mksh shell,^[30][31] which replaces a shell derived from ash^[32] that was used in older Android versions, supplemented with commands from the separate toolbox^[33] binary.
• Routers with Cisco IOS,^[34] Junos^[35] and many others are commonly configured from the command line.
• The Plan 9 operating system uses the rc shell which is similar in design to the Bourne shell.

Scripting[edit]

Most command-line interpreters support scripting, to various extents. (They are, after all, interpreters of an interpreted programming language, albeit in many cases the language is unique to the particular command-line interpreter.) They will interpret scripts (variously termed shell scripts or batch files) written in the language that they interpret. Some command-line interpreters also incorporate the interpreter engines of other languages, such as REXX, in addition to their own, allowing the executing of scripts, in those languages, directly within the command-line interpreter itself.

Conversely, scripting programming languages, in particular those with an eval function (such as REXX, Perl, Python, Ruby or Jython), can be used to implement command-line interpreters and filters. For a few operating systems, most notably DOS, such a command interpreter provides a more flexible command-line interface than the one supplied. In other cases, such a command interpreter can present a highly customised user interface employing the user interface and input/output facilities of the language.

Other command-line interfaces[edit]

The command line provides an interface between programs as well as the user. In this sense, a command line is an alternative to a dialog box. Editors and databases present a command line, in which alternate command processors might run. On the other hand, one might have options on the command line, which opens a dialog box. The latest version of ‘Take Command’ has this feature. DBase used a dialog box to construct command lines, which could be further edited before use.

Programs like BASIC, diskpart, Edlin, and QBASIC all provide command-line interfaces, some of which use the system shell. Basic is modeled on the default interface for 8-bit Intel computers. Calculators can be run as command-line or dialog interfaces.

Emacs provides a command-line interface in the form of its minibuffer. Commands and arguments can be entered using Emacs standard text editing support, and output is displayed in another buffer.

There are a number of text mode games, like Adventure or King’s Quest 1-3, which relied on the user typing commands at the bottom of the screen. One controls the character by typing commands like ‘get ring’ or ‘look’. The program returns a text which describes how the character sees it, or makes the action happen. The text adventure The Hitchhiker’s Guide to the Galaxy, a piece of interactive fiction based on Douglas Adam’s book of the same name, is a teletype-style command-line game.

The most notable of these interfaces is the standard streams interface, which allows the output of one command to be passed to the input of another. Text files can serve either purpose as well. This provides the interfaces of piping, filters and redirection. Under Unix, devices are files too, so the normal type of file for the shell used for stdin,stdout and stderr is a tty device file.

Another command-line interface allows a shell program to launch helper programs, either to launch documents or start a program. The command is processed internally by the shell, and then passed on to another program to launch the document. The graphical interface of Windows and OS/2 rely heavily on command-lines passed through to other programs – console or graphical, which then usually process the command line without presenting a user-console.

Programs like the OS/2 E editor and some other IBM editors, can process command-lines normally meant for the shell, the output being placed directly in the document window.

A web browser’s URL input field can be used as a command line. It can be used to «launch» web apps, access browser configuration, as well as perform a search. Google, which has been called «the command line of the internet» will perform a domain-specific search when it detects search parameters in a known format.^[36] This functionality is present whether the search is triggered from a browser field or on Google’s website.

There are JavaScript libraries that allow to write command line applications in browser as standalone Web apps or as part of bigger application.^[37] An example of such a website is the CLI interface to DuckDuckGo.^[38] There are also Web-based SSH applications, that allow to give access to server command line interface from a browser.

Many video games on the PC feature a command line interface often referred to as a console. It is typically used by the game developers during development and by mod developers for debugging purposes as well as for cheating or skipping parts of the game.

See also[edit]

• Comparison of command shells
• List of command-line interpreters
• Console application
• Interpreter directive
• Read-eval-print loop
• Shell script
• Run command
• Graphical user interface § Comparison to other interfaces
• In the Beginning… Was the Command Line

Notes[edit]

References[edit]

External links[edit]

• The Roots of DOS David Hunter, Softalk for the IBM Personal Computer March 1983. Archived at Patersontech.com since 2000.
• Command-Line Reference: Microsoft TechNet Database «Command-Line Reference»

Интерфейс – средство взаимодействия.
В ОС два типа интерфейсов:

1) Интерфейс командной строки

<Команда>_[<список параметров>]

Команда – описание файла, который должен
использоваться, за исключением внутренних
команд.

Список параметров – список файлов и
ключей.

Путь
= Диск (С; D); Путь (маршрут);
Имя (обязательная компонента); Тип.

список каталогов (либо от текущего, либо
от корневого). Если путь начинается с /
– то поиск с корневого каталога. Иначе
с текущего.

% — любой символ; * — любое количество
символов.

2) Графический интерфейс.

Элемент
управления средой W

Взаимодействие с приложением.

Системное меню, углы, заголовок, границы,
кнопки состояния – элементы управления.
Рабочее поле – содер. интерфейса
приложения.

Окно – основной элемент интерфейса.

Состояния: раскрыто, обычный размер,
свернуто, закрыто.

Рабочая область (элементы управления):

— меню

— панель управления

— полосы прокрутки

— вкладки

— переключатели

— флаги

— счетчики

— списки (выпадающие и т.д.)

— поле ввода

— ползунок и т.д.

Окно (средство управления другими
элементами)

Объект (ресурс)
– описание некоторого ресурса, с
которым работает пользователь.

Аппаратура Информация

Файлы
Каталоги Управляющая

Ярлыки Приложения
Документы

//Управляющая – то, что хранится в
реестре. Доступ через оконный интерфейс.
Среда окружения. Каталоги – папки.
Документы – файлы данных, с которыми
работают приложения. Ярлыки –
специальные файлы, которые являются
ссылкой на другой файл, использующийся
для доступа, без их физического
копирования. Приложения –
использующиеся файлы, содержащие код.
//

§8. Переменные окружения.

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

set_<имя переменной
=<значение (пути)> (исп. список
каталогов).

Переменные окружения

1) Переменные окружения пользователя,
зависят от регистрации пользователя.

2) Переменные окружения системные.

PATH – автоматический поиск
файлов, если указанный файл не найден
в текущем каталоге. Представляет собой
список маршрутов отделенных «;».
Если файл не найден, то система осуществляет
поиск в соответствии с PATH.

PATH EXT –
определенные типы файлов, для которых
определена процедура поиска (CMD
(4), .EXE (3), .COM
(2), .BAT (1))

TEMP или TMP –
указывают операционной системе на
каталог временных файлов. SET
TEMP = %WINDIR%TEMP,
C:WINNTTMP.

LIB – часто используется
для указания каталога, где хранят
стандартные библиотеки объектных
модулей, которые используются средами
программирования для построения
выполняемых файлов.

CMDSPEC – имя командного
процесса, который активизируется вызовом
cmd.

Некоторые переменные не требуют указывать
команду set_<имя>; —
обнуление, ликвидация переменной
окружения.

SET <имя> = %<имя>%;
<новое значение> — старое значение
заменяется новым.

set для написания командных
файлов.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Командный язык операционной системы MSDOS и Windows

Загрузка компьютера с операционной системой MS DOS

При включении компьютера (или нажатии клавиши RESET) очищается содержимое оперативной памяти, из ПЗУ переписывается в ОП и запускается BIOS. BIOS производит тестирование памяти и устройств компьютера на работоспособность; при наличии критических ошибок выдается звуковой сигнал и/или сообщение и процесс загрузки прекращается. В процессе тестирования предоставляется возможность войти в CMOS и внести изменения в параметры конфигурации компьютера (если такие изменения внесены, то необходимо процесс загрузки начать заново). В первом секторе диска, где находится операционная система, BIOS считывает программу-загрузчик и передает ей управление. Программа загрузчик считывает и загружает в оперативную память файлы IO.SYS, MSDOS.SYS, COMMAND.COM и CONFIG.SYS. Далее загружаются драйверы устройств и выполняются команды конфигурирования, указанные в файле CONFIG.SYS, и выполняется файл AUTOEXEC.BAT, запускающий отмеченные там программы (например, NC или Windows).

В командном файле AUTOEXEC.BAT записывают команды, которые должны выполняться каждый раз при включении компьютера, например:

команды запуска некоторых программ, списки каталогов, в которых следует производить поиск запускаемых программ и др.

Если файла AUTOEXEC.BAT нет, то на экране появляется запрос на ввод текущей даты и времени, после чего на экране появляется приглашение (например, С:>) для ввода команд DOS.

Для общения с ПК на языке команд операционной системой предоставляется пользователю возможность ввода команд и необходимых параметров этих команд в специальном месте окна экрана – в командной строке. В командной строке всегда указан логический дисковод, путь к текущему каталогу (текущей папке) и приглашение к набору команды в виде символа “>”.

Например: С:temabook>[место для ввода команды и ее параметров]

Текущий каталог – каталог, в котором будет осуществляться поиск и размещение файлов, указанных в параметрах веденной команды.

В приведенном примере текущим является каталог book.

dir [дисковод] [путь] [ключи]

Ключи:

Пример:

Dir a: просмотр корневого каталога логического диска А

Dir a:/p/w постраничный вывод каталога диска А с выводом на одной строке до 5 имен файлов

md [дисковод:] [путь]

Назначение: Команда создания каталога.

Этой командой можно создавать многоуровневую структуру каталога. В MS DOSмаксимальная длина пути от корневого каталога до каталога нижнего уровня должна быть не более 63 символов.

Пример:

md utilproba– создание поддиректории probaв каталоге util.

Mem [ключи]

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

Ключи:

Назначение: очищает экран

CD [дисковод:][путь]

Назначение: Производит смену текущего каталога, то есть текущий каталог меняет на указанный.

Пример:

Del [дисковод :] [полное имя файла][/p]

Назначение: Команда на удаление файла (файлов).

Ключи:

/p— выводить запрос на подтверждение удаления.

В команде можно использовать подстановочные символы «*», «?» так, как они были объяснены выше.

Примеры:

Физически удаление файла происходит следующим образом. В каталоге стирается первый символ имени, а в FAT кластеры, где находился файл, помечают как свободные. То есть до первой записи на физическом носителе можно восстановить случайно удаленный файл специальной программой (в MS-DOS – это PCTOOLS). В Windows удаление файлов происходит через корзину, и место в FAT помечается как свободное после очистки корзины. Но пока файл находится в корзине, его можно восстановить.

copy [дисковод:] полное_имя_1 [дисковод:] полное_имя_2

Назначение: Копирует один и более файлов в указанное место.

Copy [дисковод:] +[дисковод:] [дисковод:]

Назначение: Объединяет однотипные файлы:

copy con

Назначение: Создает текстовый файл с консоли клавиатуры.

copy /b prn

Назначение: Выводит файл на печать:

Файл не может быть скопирован сам в себя. Необходима точность определения, что и куда копируем.

Примеры:

Copy d:a*.txt c:util – копировать файлы, имеющие в имени 1-й символ “а”, с диска D на диск C в директорию util

Copy primer.txt+proba.txt 2prim.txt – объединить файлы primer.txt и proba.txt и сохранить объединенный файл под именем 2prim.txt в текущем каталоге.

ren [дисковод:] имя файла1 имя файла2

Назначение: Изменяет имя файла или каталога

Команда rd [дисковод:] [путь]

Назначение: Удаляется пустой каталог из многоуровневой структуры каталогов.

type [дисковод:] [путь] имя файла

Назначение: Отображает на дисплее содержимое текстового файла.

Пример:

type c:utilprimer.txt – просмотреть файл primer.txt на диске С в директории util

Ver

Назначение: Выдает версию операционной системы установленной на компьютере

xcopy [дисковод:] [путь1] [дисковод:] [путь2][ ключи]

Назначение: Копирует файлы и каталоги более низких уровней.

ключи:

/e – копировать все подкаталоги, даже если они пустые

Пример:

format дисковод [ключи]

Назначение: Форматирует указанный диск в формате пригодном для хранения файлов MS-DOS.

При форматировании на диске создается новая таблица FAT и файл корневого каталога.

ключи:

Пример:

Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет

Источник

Команды Windows

все поддерживаемые версии Windows (сервер и клиент) имеют набор встроенных команд консоли Win32.

этот набор документации описывает Windows команды, которые можно использовать для автоматизации задач с помощью скриптов или средств создания скриптов.

Предварительные требования

Сведения, содержащиеся в этом разделе, применимы к:

Общие сведения о командной оболочке

командная оболочка была первой оболочкой, встроенной в Windows для автоматизации стандартных задач, таких как управление учетными записями пользователей или ночное резервное копирование с пакетными файлами (.bat). с помощью Windows сервера сценариев можно выполнять более сложные сценарии в командной оболочке. Дополнительные сведения см. в разделе cscript или Wscript. С помощью скриптов можно более эффективно выполнять операции, чем с помощью пользовательского интерфейса. Скрипты принимают все команды, доступные в командной строке.

Windows имеет две командные оболочки: командная оболочка и PowerShell. Каждая оболочка представляет собой программную программу, обеспечивающую прямой обмен данными между вами и операционной системой или приложением, предоставляя среду для автоматизации ИТ-операций.

PowerShell был разработан для расширения возможностей командной оболочки для выполнения команд PowerShell, называемых командлетами. командлеты похожи на команды Windows, но предоставляют более расширяемый язык сценариев. вы можете выполнять команды Windows и командлеты powershell в powershell, но командная оболочка может выполнять только команды Windows, а не командлеты powershell.

для наиболее надежной и актуальной Windows автоматизации рекомендуется использовать PowerShell вместо команд Windows или Windows сервера скриптов для автоматизации Windows.

Вы также можете скачать и установить PowerShell Core, версию PowerShell с открытым исходным кодом.

Неправильное изменение реестра может серьезно повредить систему. Перед внесением следующих изменений в реестр следует создать резервную копию всех ценных данных на компьютере.

Чтобы включить или отключить завершение имен файлов и каталогов в командной оболочке на компьютере или в сеансе входа пользователя, запустите regedit.exe и задайте следующее значение reg_DWOrd:

Справочник по командной строке A-Z

Чтобы найти сведения о конкретной команде, в следующем меню A-Z щелкните букву, с которой начинается команда, а затем щелкните имя команды.

Источник

Список команд Windows ( Windows CMD ) с описанием и примерами.

Командная строка Windows является стандартным средством диагностики, настройки и управления компонентами операционной системы и прикладным программным обеспечением. В отличие от графической среды пользователя, командная строка является более гибким и универсальным инструментом, позволяющим решать многие задачи администрирования системы стандартными средствами Windows без установки дополнительного программного обеспечения.

Способы запуска командной строки

Ссылки на материалы по настройке командной строки и приемах работы с ней размещены в конце страницы.

Справочник по командам CMD Windows

Данная страница представляет собой самый полный документ в русскоязычном сегменте Интернет, содержащий список команд командной строки всех версий Windows. Наименования подавляющего большинства команд являются ссылками и ведут на страницы с подробным их описанием и примерами использования. В разных версиях ОС семейства Windows набор поддерживаемых команд, их параметры командной строки, синтаксис и отображение результатов выполнения могут различаться. Одна и та же утилита командной строки может присутствовать в стандартной поставке одной версии Windows, но отсутствовать в другой, или входить в состав дополнительных средств, как например, Resource Kit или Software Development Kit.

На данной странице представлено описание не только внутренних команд CMD, но и стандартных утилит командной строки, входящих в состав конкретных версии операционной системы (ОС) семейства Windows. Некоторые из приведенных команд устарели, и больше не поддерживаются разработчиком или не имеют смысла в современных операционных системах, что отмечается в описании команды.

Список команд постоянно обновляется и включает в себя все новейшие команды, добавляемые в стандартную поставку при выходе новых версий или обновлений ОС Windows 10.

IPCONFIG просмотр и управление конфигурацией протокола IP

PING утилита проверки доступности узла

SHIFT сдвиг входных параметров для командного файла

Прочие материалы по работе с командной строкой Windows:

Источник

Язык интерпретатора Cmd.exe. Командные файлы

Язык интерпретатора Cmd.exe. Командные файлы

Язык оболочки командной строки ( shell language ) в Windows реализован в виде командных (или пакетных) файлов. Командный файл в Windows — это обычный текстовый файл с расширением bat или cmd, в котором записаны допустимые команды операционной системы (как внешние, так и внутренние), а также некоторые дополнительные инструкции и ключевые слова, придающие командным файлам некоторое сходство с алгоритмическими языками программирования. Например, если записать в файл deltmp.bat следующие команды:

Вывод сообщений и дублирование команд

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

Таким образом, если поставить в самое начало файла команду

то это решит все проблемы с дублированием команд.

В пакетном файле можно выводить на экран строки с сообщениями. Делается это с помощью команды

С помощью такого метода можно, скажем, заполнять файлы-протоколы с отчетом о произведенных действиях. Например:

Использование параметров командной строки

При запуске пакетных файлов в командной строке можно указывать произвольное число параметров, значения которых можно использовать внутри файла. Это позволяет, например, применять один и тот же командный файл для выполнения команд с различными параметрами.

Если запустить его из командной строки с двумя параметрами, например

то на экран выведется сообщение

и произойдет копирование каталога C:Programs со всеми его подкаталогами в D:Backup.

Рассмотрим пример. Пусть командный файл my.bat вызван из командной строки следующим образом:

Например, в следующей команде:

В командных файлах имеются некоторые возможности синтаксического анализа заменяемых параметров. Для параметра с номером n (%n) допустимы синтаксические конструкции (операторы), представленные в табл. 3.1.

Fn Переменная %n расширяется до полного имени файла %

Dn Из переменной %n выделяется только имя диска %

Pn Из переменной %n выделяется только путь к файлу %

Nn Из переменной %n выделяется только имя файла %

Xn Из переменной %n выделяется расширение имени файла %

Sn Значение операторов N и X для переменной %n изменяется так, что они работают с кратким именем файла %

Данные синтаксические конструкции можно объединять друг с другом, например:

DPn — из переменной %n выделяется имя диска и путь,

NXn — из переменной %n выделяется имя файла и расширение.

Рассмотрим следующий пример. Пусть мы находимся в каталоге C:TEXT и запускаем пакетный файл с параметром Рассказ.doc ( %1=Рассказ.doc ). Тогда применение операторов, описанных в табл. 3.1, к параметру %1 даст следующие результаты:

Источник

Тяжкое наследие прошлого. Проблемы командной строки Windows

Предисловие от автора, Рича Тёрнера из Microsoft. Это статья о командной строке: от её появления и эволюции до планов капитального ремонта Windows Console и командной строки в будущих версиях Windows. Будь вы опытным профессионалом или новичком в IT, надеемся, что вы найдёте статью интересной.

Давным-давно в далёкой-далёкой серверной.

С первых дней развития информатики людям нужен был эффективный способ передавать компьютеру команды и данные и видеть результат выполнения этих команд/вычислений.

Одним из первых по-настоящему эффективных человеко-машинных интерфейсов стал Tele-Typewriter или «телетайп». Это электромеханическая машина с клавиатурой для ввода данных и каким-нибудь устройством вывода — сначала использовался принтер, позже экран.

Вводимые оператором символы локально буферизуются и отправляются с телетайпа на соседний компьютер или мейнфрейм в виде серии сигналов по электрическому кабелю (например, RS-232) со скоростью 10 символов в секунду (110 бод, бит в секунду, bps):

Телетайп Model 33 ASR

Примечание: Дэвид Гессвейн ведёт отличный сайт по PDP-8, где можно найти больше информации об ASR33 (и соответствующей технологии PDP-8), в том числе фотографии, видео и др.

Программа на компьютере получает введённые символы, решает, что с ними делать, и, возможно, асинхронно отправляет ответ на телетайп. Телетайп может напечатать/показать оператору полученные символы.

Затем технология улучшилась, скорость передачи выросла до 19200 bps, а шумные и дорогие принтеры заменили ЭЛТ-дисплеями (широко распространённый тип дисплеев в 80-е и 90-е годы), как на популярном терминале DEC VT100:

Терминал DEC VT100

Хотя технология улучшилась, но эта модель — терминал отправляет символы программе на компьютере, а он выдаёт текст для пользователя — осталась и сегодня как фундаментальная модель взаимодействия всех командных строк и консолей на всех платформах!

Архитектура терминала и командной строки

Модель по-своему элегантна. Одна из причин — в сохранении простоты и цельности каждого компонента: клавиатура выдаёт символы которые буферизуются как электрические сигналы. Устройство вывода просто выдаёт на дисплей (бумагу/экран) символы, полученные с компьютера.

На каждом этапе в системе передаётся только поток символов, так что это относительно простой процесс для внедрения различной инфраструктуры связи. Например, для добавления модемов, чтобы передавать потоки входных и выходных символов на большие расстояния по телефонным линиям.

Кодировка текста

Важно помнить, что терминалы и компьютеры обмениваются данными через потоки символов. При нажатии клавиши на клавиатуре терминала на подключенный компьютер отправляется значение, представляющее введённый символ. Нажмите клавишу ’A’ — и отправляется значение 65 (0x41). Нажмите ’Z’ — и отправляется 90 (0x5a).

7-битная кодировка ASCII

Список символов и их значений определён в стандарте American Standard Code for Information Interchange (ASCII), он же стандарт ISO/IEC 646 / ECMA-6 — «7-битный кодированный набор символов», который определяет:

Когда 7 бит недостаточно: кодовые страницы

Однако 7 бит не обеспечивают достаточно места для кодирования многих диакритических знаков, знаков препинания и символов, используемых в других языках и регионах. Так что с добавлением дополнительного бита можно расширить таблицу символов ASCII дополнительными наборами «кодовых страниц» для символов 128−255 (и возможного переопределения нескольких непечатаемых символов ASCII).

Например, IBM ввела кодовую страницу 437 с несколькими графическими символами вроде ╫ (215) и ╣(185) и математическими, включая π (227) и ± (241), а также переопределила печатные символы для обычно непечатаемых символов 1−31:

Кодовая страница 437

Кодовая страница Latin-1 определяет множество символов, используемых языками на основе латиницы:

Кодовая страница Latin-1

Во многих окружениях командной строки и оболочках можно изменять текущую кодовую страницу, чтобы терминал отображал различные символы (в зависимости от доступных шрифтов), особенно для символов со значением 128−255. Но неправильно указанная кодовая страница приведёт к отображению кракозябр. И да, «кракозябры» — это настоящий термин! Кто бы мог подумать? 😉

Когда 8 бит недостаточно: Юникод

Кодовые страницы временно решили проблему, но у них много недостатков, например, они не позволяют отображать текст одновременно из нескольких кодовых страниц/языков. Таким образом, пришлось ввести новую кодировку, которая точно отображает каждый символ и алфавит для всех языков, известных человечеству, оставляя ещё много свободного места! Представляем Юникод.

Юникод — это международный стандарт (ISO/IEC 10646), который в данный момент определяет 137 439 символов из 146 современных и исторических письменностей, а также многие символы и глифы, в том числе многочисленные смайлики, которые широко используются практически в каждом приложении, платформе и устройстве. Юникод регулярно обновляется дополнительными системами письменности, новыми/исправленными смайликами, символами и т. д.

Юникод также определяет «непечатаемые» символы форматирования, которые позволяют, например, соединить символы и/или повлиять на предыдущие или последующие символы! Это особенно полезно в письменностях вроде арабской, где лигатура конкретного символа определяется окружающими. Эмодзи могут использовать соединительный символ нулевой ширины (zero width joiner), чтобы объединить несколько символов в один визуальный глиф. Например, эмодзи кота-ниндзя Microsoft формируются путём соединения кота с другими эмодзи:

Эмодзи кота-ниндзя Microsoft

Когда байтов слишком много: UTF-8!

Для уникального и систематического представления всех символов требуется большое пространство, до нескольких байт на каждый символ.

Поэтому для экономии было разработано несколько новых кодировок Юникода. Среди самых популярных — UTF-32 (4 байта на символ), UTF-16/UCS-2 (2 байта) и UTF-8 (1−4 байта на символ).

Во многом благодаря обратной совместимости с ASCII и экономии места UTF-8 стала самой популярной кодировкой Юникода в интернете. Она демонстрирует взрывной рост с 2008 года, когда обогнала по популярности ASCII и другие популярные кодировки:

Рост популярности кодировки UTF-8 (источник: Википедия)

Таким образом, поначалу терминалы поддерживали 7-битный, а затем 8-битный текст ANSI, но большинство современных терминалов поддерживают текст Unicode/UTF-8.

Итак, что такое командная строка и что такое оболочка?

«Командная строка» или CLI (интерфейс/интерпретатор командной строки) описывает самый фундаментальный механизм, через который человек управляет компьютером: CLI принимает введённый оператором ввод и выполняет требуемые команды.

Например, echo Hello отправляет текст «Hello» на устройство вывода (например, на экран). dir (Cmd) или ls (PowerShell/*NIX) перечисляет содержимое текущего каталога и т.д.

Раньше доступные команды были относительно простыми, но операторы требовали всё более изощрённых команд и возможности писать скрипты для автоматизации повторяющихся или сложных задач. Таким образом, процессоры командной строки стали сложнее и превратились в то, что теперь называют «оболочкой» командной строки (shell).

В Unix/Linux оригинальная оболочка Unix (sh) породила множество оболочек, включая Korn shell (ksh), C shell (csh) и Bourne Shell (sh). В свою очередь, на их основе создан Bourne Again Shell (bash) и т.д.

Современная командная строка

Современные компьютеры значительно мощнее «тупых терминалов» прошлого и обычно работают под управлением десктопной ОС (например, Windows, Linux, macOS) с графическим пользовательским интерфейсом (GUI). Такое окружение GUI позволяет нескольким приложениям работать одновременно в отдельных окнах на экране и/или невидимо в фоновом режиме.

Cmd, PowerShell и Ubuntu Linux под WSL работают на независимых инстансах консоли

На смену громоздким, неповоротливым электромеханическим телетайпам пришли современные консольные/терминальные приложения, которые работают в окошке на экране компьютера, но по-прежнему выполняют такие же необходимые функции, как аппаратные терминалы из прошлого.

Аналогично и приложения командной строки, к которым подключены терминалы, работают как и раньше: получают входные символы, решают, что делать с этими символами, (необязательно) выполняют работу — и могут выдать текст для отображения пользователю. Только вместо связи по медленным каналам TTY терминальные приложения и приложения командной строки на одной машине общаются по очень скоростным каналам Pseudo Teletype (PTY) в памяти.

Современная командная строка

Современные терминалы в основном взаимодействуют с приложениями командной строки, запущенными локально. Но конечно, они также могут взаимодействовать с приложениями командной строки, запущенными на других машинах в той же сети или даже с удалёнными машинами на другой стороне света через интернет. Это «удалённое» взаимодействие с командной строкой — мощный инструмент, который популярен на каждой платформе, особенно на *NIX.

Эволюция командной строки

Скромное начало: MS-DOS

На заре компьютерной индустрии управление большинством компьютеров осуществлялось путём ввода команд в командной строке. За рыночную долю боролись компьютеры под Unix, CP/M, DR-DOS и других. В итоге система MS-DOS стала стандартом де-факто для IBM PC и всех совместимых компьютеров:

MS-DOS 6.0

Как и большинство основных операционных систем того времени, интерпретатор командной строки или «оболочка» в MS-DOS предоставляла простой, но относительно эффективный набор команд и синтаксис командных скриптов для написания batch-файлов (.bat).

Предприятия крупного и малого бизнеса очень быстро взяли на вооружение MS-DOS и в совокупности создали многие миллионы скриптов, некоторые из которых всё ещё используются сегодня! Batch-скрипты применяются для автоматизации настройки ПК, установки/изменения параметров безопасности, обновления программного обеспечения, сборки кода и т.д.

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

Командная строка представляет мощный инструмент в руках человека, который имеет терпение и упорство, чтобы научиться выжимать максимум из доступных команд и инструментов. Но большинству обычных пользователей сложно эффективно управлять компьютером из командной строки. Большинству не нравилось, что нужно изучать и запоминать много словно мистических аббревиатур, чтобы компьютер произвёл хоть какое-нибудь полезное действие.

Требуется более удобный и ориентированный на производительность пользовательский интерфейс.

Графический интерфейс идёт в мейнстрим

Вскоре после изобретения появилось много конкурирующих GUI на компьютерах Lisa и Macintosh от Apple, Commodore Amiga (Workbench), Atari ST (DRI GEM), Acorn Archimedes (Arthur/RISC OS), Sun Workstation, X11/X Windows и многих других, в том числе Microsoft Windows.

Windows 1.0 вышла в 1985 году и являлась по сути приложением MS-DOS, которое предоставляло простое окружение GUI с плиточным окном, позволяя пользователям запускать несколько приложений бок о бок:

Windows 1.01 на MS-DOS

Windows 2.x, 3.x, 95 и 98 работали на базе MS-DOS. Более поздние версии Windows начали заменять некоторые функции MS-DOS альтернативами Windows (например, операции с файловой системой), но все они полагались на фундамент MS-DOS.

Примечание: Windows ME (Millennium Edition) стала интересным гибридом. В ней наконец-то заменили поддержку MS-DOS и поддержку реального режима из предыдущих версий Windows несколькими новыми функциями (особенно технологии Gaming & Media). Некоторые функции позаимствованы из Windows 2000 (например, новый стек TCP/IP), но настроены для работы на домашних ПК, которым трудно запустить полноценную NT.

Но Microsoft понимала, что не может бесконечно растягивать архитектуру и возможности MS-DOS и Windows. Требовалась новая операционная система с прицелом на будущее.

Microsoft — лидер рынка Unix! Да, серьёзно!

Разрабатывая MS-DOS, Microsoft также занималась поставкой Xenix — фирменного порта Unix версии 7 — для различных процессорных и машинных архитектур, включая Z8000, 8086/80286 и 68000.

К 1984 году Xenix от Microsoft стал самым популярным вариантом Unix в мире!

Тем временем распад Bell Labs — родины Unix — привёл к появлению AT&T, которая начала продавать Unix System V производителям компьютеров и конечным пользователям.

Microsoft понимала, что отсутствие собственной ОС ставит под угрозу её способности для развития. Поэтому было принято решение отказаться от Xenix: в 1987 году Microsoft передала Xenix своему партнёру Santa Cruz Operation (SCO), с которым работала над несколькими проектами по портированию и улучшению Xenix на различных платформах.

Microsoft + IBM == OS/2… ненадолго

В 1985 году Microsoft начала работать с IBM над новой операционной системой OS/2. Она изначально планировалась как «более функциональная DOS» для некоторых современных 32-битных CPU и с учётом других технологий, которые быстро порождались в IBM и у других OEM.

Но история OS/2 оказалась слишком бурной. В 1990 году Microsoft и IBM прекратили сотрудничество. Это было обусловлено рядом факторов, в том числе значительными культурными различиями между разработчиками IBM и Microsoft, проблемами планирования, а также взрывным успехом и ростом внедрения Windows 3.1. IBM продолжала разработку и поддержку OS/2 до конца 2006 года.

К 1988 году Microsoft убедилась, что будущий успех требует более масштабного, смелого и амбициозного подхода. Такой подход потребует новой, современной операционной системы, которая будет поддерживать амбициозные цели компании.

Большая ставка Microsoft: Windows NT

В 1988 году Microsoft пригласила Дэйва Катлера, создателя популярной и уважаемой операционной системы VAX/VMS в компании DEC. Его задача — создать новую, современную, независимую от платформы операционную систему, которой Microsoft будет владеть, контролировать и на которой во многом построит своё будущее.

Этой новой операционной системой стала Windows NT: фундамент, на котором построены Windows 2000, Windows XP, Windows Vista, Windows 7, Windows 8 и Windows 10, а также во все версии Windows Server, Windows Phone 7+, Xbox и HoloLens!

Windows NT изначально спроектирована как кроссплатформенная система. Сначала она поддерживала Intel i860, затем MIPS R3000, Intel 80386+, DEC Alpha и PowerPC. С тех пор семейство ОС Windows NT портировали для поддержки процессорных архитектур IA64 Itanium, x64 и ARM/ARM64, среди прочих.

Windows NT предоставляет интерфейс командной строки через терминальное приложение Windows Console и командную строку Command Prompt (cmd.exe). Cmd разработан на максимальную совместимость с пакетными скриптами MS-DOS, чтобы помочь бизнесу перейти на новую платформу.

Мощь PowerShell

Cmd сохраняется в Windows по сей день (и, вероятно, сохранится в течение многих десятилетий). Поскольку его основная задача — обеспечить максимальную обратную совместимость, Cmd редко улучшается. Даже «исправление ошибок» зачастую затруднено, если эти «баги» существовали в MS-DOS или более ранних версиях Windows!

В начале 2000-х оболочка Cmd уже устарела: Microsoft и её клиенты срочно нуждались в более мощной и гибкой командной строке. Из этой потребности появился PowerShell (который возник из «Манифеста Монады» Джеффри Сновера).

PowerShell — это объектно-ориентированная оболочка, в отличие от оболочек на основе файлов/потоков, которые принято использовать в мире *NIX: вместо потоков текста PowerShell обрабатывает потоки объектов. Он предоставляет авторам скриптов возможность прямого доступа и манипуляций с объектами и их свойствами вместо написания множества скриптов для анализа и обработки текста (как sed/grep/awk/lex/др.).

Чтобы узнать больше о PowerShell, рекомендую прочитать книгу «PowerShell в действии» (Manning Press), написанную Брюсом Пайеттом — разработчиком синтаксиса и языка PowerShell. В частности, первые несколько глав содержат подробное обоснование структуры языка.

PowerShell был принят для использования многими технологиями на платформе Microsoft, включая Windows, Exchange Server, SQL Server, Azure и многими другими. Он предоставляет очень согласованные команды для администрирования и управления практически всеми аспектами Windows и/или среды.

PowerShell Core — это PowerShell с открытым исходным кодом, доступное для Windows и различных версий Linux, BSD и macOS.

POSIX для NT, Interix и служб UNIX

При проектировании NT компания команда Катлера специально разработала ядро NT и операционную систему для поддержки нескольких подсистем-интерфейсов между кодом пользовательского режима и основным ядром.

Когда в 1993 году вышла первая Windows NT версии 3.1, она поддерживала несколько подсистем: МЅ-DOS, Windows, OS/2 и POSIX v1.2. Эти подсистемы позволяли на одной машине и базовой ОС запускать приложения, нацеленные на несколько платформ операционной системы без виртуализации или эмуляции — это внушительная разработка даже по меркам сегодняшнего дня!

Оригинальная реализация POSIX в Windows NT была приемлемой, но для неё требовались значительных улучшения. Поэтому Microsoft приобрела Softway Systems и её POSIX-совместимую подсистему Interix для NT. Изначально Interix поставлялась как отдельное дополнение, а затем её объединили с несколькими полезными утилитами и инструментами и выпустили в виде Services For Unix (SFU) в Windows Server 2003 R2 и Windows Vista. Однако поддержку SFU пришлось прекратить после Windows 8, в основном, из-за недостаточной популярности.

А потом произошла забавная вещь…

Windows 10 — новая эра для командной строки Windows!

В начале разработки Windows 10 компания открыла страницу UserVoice с вопросом, какие функции люди хотят реализовать в различных областях ОС. Сообщество разработчиков особенно громко требовало от Microsoft две вещи:

Подсистема Windows для Linux (WSL)

Основанные на GNU/Linux «дистрибутивы» (сочетания ядра Linux и коллекций инструментов пользовательского режима) становятся всё популярнее, особенно на серверах и в облаке. Хотя в Windows имелась POSIX-совместимая среда выполнения, но SFU не мог запускать многие инструменты и двоичные файлы Linux из-за дополнительных системных вызовов и различий в поведении по сравнению с традиционной Unix/POSIX.

После анализа обратной связи от разработчиков и технически подкованных пользователей Windows, а также в связи с растущим спросом внутри самой Microsoft, компания изучила несколько вариантов, и в конечном итоге решила позволить на Windows запуск оригинальных немодифицированных бинарных файлов Linux!

В середине 2014 года Microsoft сформировала группу разработки того, что станет подсистемой Windows для Linux (WSL). WSL впервые анонсировали в сборке Build 2016, а вскоре предварительная версия вышла на канале Windows 10 Insider.

С тех пор WSL обновляется в большинстве инсайдерских сборок и в каждом крупном выпуске ОС с момента Anniversary Update осенью 2016 года. В каждой новой версии увеличивается функциональность, совместимость и стабильность WSL: в первой версии это был интересный эксперимент, который мог запускать лишь несколько распространённых программ Linux. При активной помощи сообщества (всем спасибо!) разработчики быстро дорабатывали WSL, так что вскоре она получила много новых возможностей и научилась запускать всё более сложные бинарники Linux.

Сегодня (середина 2018 года) WSL запускает большинство двоичных файлов Linux, программы, компиляторы, компоновщики, отладчикии т.д. Многие разработчики, IT-специалисты, инженеры DevOps и многие другие, кому необходимо запускать или создавать инструменты, приложения, службы Linux и т. д., получили резкое повышение производительности и возможность запускать свои любимые инструменты Linux вместе с любимыми инструментами для Windows на одном компьютере, без загрузки двух операционных систем.

Команда WSL продолжает улучшать WSL в части выполнения задач Linux, повышения производительности и интеграции с Windows.

Перезагрузка и капитальный ремонт Windows Console

В конце 2014 года проект по созданию подсистемы Windows для Linux (WSL) шёл полным ходом, и на фоне взрыва оживлённого интереса пользователей к командной строке стало очевидно, что консоль Windows явно нуждается в некотором апгрейде.

В частности, консоли не хватало многих функций, привычных для современных *NIX-совместимых систем, таких как возможность парсинга и вывода последовательностей ANSI/VT, широко используемых в мире *NIX для вывода насыщенного и подсвеченного текста и текстовых UI.

В чём тогда смысл разработки WSL, если пользователь не сможет корректно использовать инструменты Linux?

Сравнение консоли Windows 7 и Windows 10

Так, в 2014 году была сформирована небольшая «группа Windows Console». На неё возложили задачу распутать, понять и улучшить кодовую базу Windows Console… которой к этому времени было около 28 лет — больше, чем программистам, которые работают над этим проектом.

Как подтвердит любой разработчик, которому когда-либо приходилось брать старый, грязный, плохо поддерживаемый код, улучшение такого кода представляет собой сложную задачу. Ещё сложнее не нарушить существующее поведение. Для обновления самой часто запускаемой программы в Windows, не нарушив работу миллионов клиентских скриптов, инструментов, скриптов авторизации, систем сборки, производственных систем, систем анализа и прочих, требуется немало «внимания и терпения». 😉

Для разработчиков проблема усугубилась, когда они поняли всю строгость требований к консоли со стороны клиентов. Например, если производительность консоли изменялась на 1−2% от сборки к сборке, то срабатывали сигналы тревоги в группе Windows Build, что приводило… гм… к «быстрой и прямой обратной связи», то есть требованию немедленного исправления.

Итак, когда мы будем обсуждать улучшения консоли и новые функции, помните, что есть несколько незыблемых принципов, которым должно соответствовать каждое изменение, в том числе:

К чему был этот урок истории?

Я надеюсь, вы поняли, что командная строка остаётся ключевым компонентом стратегии, платформы и экосистемы Microsoft.

Хотя для конечных пользователей Microsoft продвигала графический интерфейс, сама компания и её технические клиенты/пользователи/партнёры в значительной степени полагались на командную строку для выполнения множества технических задач.

На самом деле Microsoft буквально не смогла бы создать ни Windows, ни любой другой из своих программных продуктов без быстрой, эффективной, стабильной и безопасной консоли!

На протяжении эпох MS-DOS, Unix, OS/2 и Windows командная строка оставалась, пожалуй, самым важным инструментом в наборе инструментов каждого технического пользователя. Даже многие пользователи, которые никогда не вводили команды в окно, в реальности используют консоль каждый день! Даже сборка кода в Visual Studio (VS) происходит в скрытом окне консоли. При использовании Exchange Server или средств администрирования SQL Server многие из этих команд выполняются с помощью PowerShell в скрытой консоли.

Механика Windows Console

Во время начала разработки Windows NT в 1989 году не было ни графического интерфейса, ни рабочего стола. Была только полноэкранная командная строка, которая визуально напоминала MS-DOS. Когда появилась реализация графического интерфейса Windows, потребовалось создать приложение консоли для GUI — и таким образом родилась Windows Console! Это одно из первых приложений Windows NT с графическим интерфейсом и, безусловно, одно из старейших приложений Windows, которое по-прежнему используется повсеместно!

Кодовой базе консоли Windows в настоящее время (июль 2018 года) почти 30 лет… по сути, больше, чем разработчикам, которые сейчас над ней работают!

Что делает консоль?

Как мы узнали ранее, у терминала относительно простой алгоритм работы:

Механика Windows Console

Консоль Windows — обычный исполняемый файл Win32. Изначально он написан на C, но большая часть кода сейчас переносится на C++ по мере того, как разработчики модернизируют и разбивают на модули кодовую базу.

Так что внутри консоли Windows?

До Windows 7 инстансы консоли Windows размещались в критически важной подсистеме Client Server Runtime Subsystem (CSRSS)! Но в Windows 7 из соображений безопасности и надёжности консоль переместили из CSRSS в следующие бинарники:

Ядро консоли состоит из следующих компонентов (снизу вверх):

Windows Console API

Как видно из схемы архитектуры, в отличие от терминалов NIX, консоль отправляет/получает вызовы API и/или данные в виде сообщений IO Control (IOCTL), а не текста! Даже встроенные в текст последовательности ANSI/VT из приложений командной строки (в основном Linux), извлекаются, анализируются и преобразуются в вызовы API!

Это различие раскрывает ключевое фундаментальное философское различие между *NIX и Windows: в *NIX «всё является файлом», а в Windows «всё является объектом»!

У обоих подходов есть преимущества и недостатки, которые мы перечислим, но не будем подробно обсуждать. Просто помните, что это ключевое различие в философии объясняет многие фундаментальные различия Windows и *NIX!

В *NIX всё является файлом

Когда Unix впервые появился в конце 1960-х и начале 1970-х годов, одним из основных принципов стало то, что (где это возможно) всё следует абстрагировать как файловый поток. Одна из ключевых целей заключалась в упрощении кода для доступа к устройствам и периферии: если все устройства представляются в ОС как файлы, то коду легче получить к ним доступ.

Эта философия работает на самом глубоком уровне: можно даже перемещаться и опрашивать большую часть конфигурации ОС и компьютера под *NIX, перемещаясь по псевдо/виртуальным файловым системам, которые показывают то, что кажется «файлами» и папками, но на самом деле представляет собой конфигурацию машины и оборудование.

Например, в Linux можно исследовать свойства процессоров, изучая содержимое псевдофайла /proc/cpuinfo :

Но простота и согласованность этой модели могут дорого стоить: извлечение/анализ конкретной информации в псевдофайлах часто требует специальных инструментов, таких как sed, awk, perl, python и т.д. Эти инструменты используются для написания команд и скриптов парсинга текстового содержимого, поиска определённых шаблонов, полей и значений. Некоторые из скриптов могут быть довольно сложными, часто трудными в обслуживании и хрупкими — если структура, шаблон и/или формат текста изменятся, многие скрипты, вероятно, потребуется обновить.

В Windows всё является объектом

Когда проектировалась Windows NT, «объекты» рассматривались как будущее в разработке программного обеспечения: «объектно-ориентированные» языки программирования появлялись быстрее, чем тараканы: Simula и Smalltalk уже зарекомендовали себя, а C++ набирал популярность. За ними последовали другие объектно-ориентированные языки, в том числе Python, Eiffel, Objective-C, ObjectPascal/Delphi, Java, C# и многие другие.

Результат предсказуем. Созданная в те пьянящие, объектно-ориентированные дни (около 1989 года) Windows NT разработана с философией, что «всё является объектом». На самом деле одной из самых важных частей ядра NT является Менеджер объектов!

Windows NT предоставляет богатый набор Win32 API для получения и/или управления объектами ОС. Разработчики используют Win32 API для сбора и представления информации, похожей на данные из псевдофайлов и инструментов *NIX, только через объекты и структуры. А поскольку парсеры, компиляторы и анализаторы понимают структуру объектов, то многие ошибки кодирования часто проявляются на ранней стадии, что помогает проверить синтаксическую и логическую правильность намерений программиста. Со временем это может привести к уменьшению сбоев, волатильности и лучшему порядку.

Итак, возвращаясь к основной дискуссии о консоли Windows: команда NT решила построить «консоль», отличную от традиционного терминала *NIX в нескольких ключевых областях:

Проблемы с консолью Windows

Хотя консольные API стали очень популярны в инструментах и сервисах командной строки, но ориентированная на API модель имеет определённые недостатки, перечисленные ниже.

Только для Windows

Многие средства командной строки и приложения широко используют Console API.

В чём проблема? Они работают только под Windows.

Таким образом, в сочетании с другими различиями (например, в жизненном цикле и т.д.), приложения командной строки Windows не всегда легко переносятся под *NIX и наоборот.

Из-за этого в экосистеме Windows распространены свои собственные, часто похожие, но обычно отличающиеся средства командной строки и приложения. Это означает, что при использовании Windows пользователям приходится изучать один набор приложений и инструментов командной строки, оболочек, языков сценариев и т.д., а при использовании *NIX — другой набор.

У этой проблемы нет простого решения: консоль Windows и командную строку нельзя просто выбросить и заменить на bash и iTerm2 — существуют сотни миллионов приложений и сценариев, которые зависят от консоли Windows и оболочек Cmd/PowerShell.

Сторонние инструменты, такие как Cygwin, отлично переносят многие основные инструменты GNU и библиотеки совместимости в Windows, но не могут запускать непортированные, неизменённые бинарники Linux. Это очень важно, так как многие пакеты и модули Ruby, Python, Node зависят от бинарных файлов Linux и/или зависят от поведения *NIX.

Эти причины привели к тому, что Microsoft расширила совместимость с Windows, разрешив запуск аутентичных двоичных файлов и средств Linux в подсистеме Windows для Linux (WSL). С помощью WSL пользователи теперь могут загружать и устанавливать один или несколько дистрибутивов Linux бок о бок на одной машине, а также использовать apt/zypper/npm/gem/др. для установки и запуска подавляющего большинства инструментов командной строки Linux вместе с их любимыми приложениями и инструментами Windows.

Тем не менее, у нативной консоли остаётся функциональность, которая отсутствует в сторонних терминалах: в частности, Windows Console предоставляет сервисы command-history и command-alias, чтобы каждой оболочке (в частности) не пришлось повторно реализовать одинаковую функциональность.

Сложности с удалённой работой

Как говорилось в начале статьи, терминалы изначально были отделены от компьютера, к которому подключены. Сегодня эта конструкция сохраняется: большинство современных терминалов и оболочек/приложений/проч. командной строки изолированы в рамках отдельных процессов и/или машин.

На *NIX-платформах парадигма изолированности терминалов и приложений командной строки с простым обменом символами привела к тому, что там легко получить доступ и работать с удалённого компьютера/устройства. Если терминал и приложение командной строки обмениваются потоками символов по какой-то упорядоченной инфруструктуре (TTY, PTY и т.д.), то очень легко работать удалённо.

Но в Windows многие приложения командной строки зависят от вызова API консоли и предполагают выполнение на той же машине, что и сама консоль. Это затрудняет удалённое управление. Как приложению командной строки удалённо обратиться к API на консоли локального компьютера? Хуже того, как удалённое приложение обратится к Console API, если доступ к нему осуществляется через терминал на Mac или Linux?!

Извините, что дразню вас, но более подробно мы вернёмся к этой теме в следующей статье.

Запуск консоли… или нет!

Когда пользователь *NIX хочет запустить инструмент командной строки, то сначала запускает терминал. Тот затем запускает оболочку по умолчанию или может быть настроен для запуска определённого приложения/инструмента. Терминал и приложение командной строки взаимодействуют потоками символов через Pseudo TTY (PTY).

Однако в Windows всё работает иначе: пользователи Windows никогда не запускают консоль (conhost.exe) — они сразу запускают оболочки командной строки и приложения, например, Cmd.exe, PowerShell.exe, wsl.exe и прочее. Windows подключает запущенное приложение к текущей консоли (если оно запущено из командной строки) или к вновь созданному экземпляру консоли.

Да, в Windows пользователи запускают приложение командной строки, а не саму консоль.

Немного занудства: многие говорят, что «приложения командной строки запускаются в консоли». Это не так и приводит к большой путанице относительно того, как в реальности работает консоль и приложения командной строки! Приложения командной строки и их консоли запускаются в независимых процессах Win32. Помогите исправить это заблуждение. Всегда говорите, что «средства командной строки/приложения выполняются с подключением к консоли». Спасибо!

Звучит неплохо, правда? На самом деле… нет. Есть некоторые проблемы:

Увы, ситуация тут не очень хорошая. Есть отличные сторонние консоли и серверные приложения для Windows (например, ConEmu/Cmder, Console2/ConsoleZ, Hyper, Visual Studio Code, OpenSSH и т. д.), но им приходится прибегать к изощрённым трюкам, чтобы работать как обычная консоль!

Какое-то безумие, верно?! Тот факт, что эти приложения вообще работают — лишь доказательство изобретательности и целеустремленности их создателей.

Очевидно, что мы стремимся исправить эту ситуацию. Об этом тоже расскажем в следующих статьях.

Windows Console и VT

Как описано выше, консоль Windows предоставляет богатый API. С помощью Console API приложения и инструменты командной строки пишут текст, изменяют его цвет, перемещают курсор и т.д. И благодаря этим API не нужно было поддерживать последовательности ANSI/VT, которые обеспечивают похожую функциональность на других платформах.

Фактически, до Windows 10 в консоли Windows была реализована только минимальная поддержка последовательностей ANSI/VT:

Всё изменилось в 2014 году, когда Microsoft сформировала новую группу разработки Windows Console. Одним из её главных приоритетов стало реализовать всестороннюю поддержку последовательностей ANSI/VT для визуализации выходных данных приложений *NIX, работающих в подсистеме Windows для Linux (WSL) и на удалённых машинах *NIX.

Группа быстро внедрила в консоль Windows 10 всестороннюю поддержку последовательностей ANSI/VT, что позволило пользователям использовать и наслаждаться огромным набором инструментов и приложений командной строки Windows и Linux.

Команда продолжает улучшать поддержку VT с каждым выпуском ОС и будет благодарна за любые проблемы, которые вы упомянете в нашем трекере на GitHub. 😉

Обработка Юникода

К сожалению, консоль Windows и её API появились до изобретения Юникода!

Консоль Windows хранит текст (который впоследствии выводится на экран) как символы кодировки UCS-2 с двумя байтами на символ. Эта кодировка поддерживает кодирование первых 65536 позиций символов, что известно как плоскость 0 или основная многоязычная плоскость (Basic Multilingual Plane, BMP).

Приложения командной строки выводят текст в консоли с помощью Console API. Обрабатывающие текст интерфейсы, бывают двух видов: функции с суффиксом А обрабатывают однобайтовые/символьные строки, функции с суффиксом W обрабатывают двухбайтовые (wchar)/символьные строки.

Примечание: каждый W API поддерживает UCS-2, потому что это всё, что существовало в момент разделения на A/W, и мы думали, что так будет хорошо. Но многие W API уже обновились для поддержки ещё и UTF-16 на том же канале.

Не все W API понимают UTF-16, но все они знают хотя бы UCS-2.

Кроме того, консоль не поддерживает некоторые новые функции Юникода, включая соединительные символы нулевой ширины (zero width joiner), которые используются для объединения отдельных символов в арабских и индийских письменностях, а также для объединения символов эмодзи в один визуальный глиф.

Как же ввести эмодзи кота-ниндзя или сложные многобайтовые китайские/арабские символы в консоль? К сожалению, никак!

Мало того что консольный API не поддерживает символы Юникод больше двух байт на глиф (эмодзи NinjaCat требует 8 байт!), но внутренний буфер UCS-2 консоли тоже не может хранить дополнительные байты данных. Что ещё хуже, текущий GDI-рендерер консоли не сможет отрисовать глиф, даже если тот поместится в буфер!

Эх… Таковы радости legacy-кода.

Здесь опять я намерен прервать рассказ — вернёмся к этой теме в следующей статье. Оставайтесь с нами!

Итак, на чём мы остановились?

Дорогой читатель, если вы прочитали всё вышенаписанное, спасибо вам, и примите поздравления — теперь вы знаете больше о консоли Windows, чем большинство ваших друзей, и, вероятно, даже больше, чем вы сами хотели узнать! Какая удача!

Источник

А Интерфейс командной строки (CLI) процессы команды в компьютерную программу в виде строк текста. Программа, которая обрабатывает интерфейс, называется интерпретатор командной строки или же процессор командной строки. Операционные системы реализуют интерфейс командной строки в ракушка для интерактивного доступа к функциям или службам операционной системы. Такой доступ в первую очередь предоставляли пользователям компьютерные терминалы начиная с середины 1960-х годов и продолжал использоваться на протяжении 1970-х и 1980-х годов на VAX / VMS, Unix системы и системы персональных компьютеров, включая ДОС, CP / M и Apple DOS.

Сегодня многие пользователи полагаются на графический пользовательский интерфейс и взаимодействия через меню. Однако некоторые задачи программирования и обслуживания могут не иметь графического пользовательского интерфейса и по-прежнему использовать командную строку.

Альтернативы интерфейсу командной строки включают текстовый пользовательский интерфейс меню (Например, IBM AIX SMIT ), горячие клавиши, и различные настольные метафоры сосредоточен на указатель (обычно контролируется мышь ). Примеры этого включают Microsoft Windows, DOS Shell, и Mouse Systems PowerPanel. Интерфейсы командной строки часто реализуются в оконечных устройствах, которые также поддерживают экранно-ориентированные текстовые пользовательские интерфейсы, использующие адресацию курсора для размещения символов на экране дисплея.

Программы с интерфейсами командной строки, как правило, легче автоматизировать с помощью сценарии.

Многие программные системы реализуют интерфейсы командной строки для управления и работы. Сюда входят среды программирования и служебные программы.

Сравнение с графическим пользовательским интерфейсом

По сравнению с графическим пользовательским интерфейсом, интерфейс командной строки требует меньше системных ресурсов для реализации. Поскольку параметры команд задаются несколькими символами в каждой командной строке, опытный пользователь может часто находить параметры более доступными. Автоматизация повторяющихся задач упрощается за счет механизмов редактирования строк и истории для хранения часто используемых последовательностей; это может распространяться на язык сценариев который может принимать параметры и переменные параметры. Можно вести историю командной строки, что позволяет просматривать или повторять команды.

Система командной строки может потребовать бумажных или интерактивных руководств для справки пользователя, хотя часто опция «справка» предоставляет краткий обзор параметров команды. Среда командной строки может не предоставлять графических улучшений, таких как различные шрифты или расширенный редактировать окна найдено в графическом интерфейсе. Новому пользователю может быть сложно ознакомиться со всеми доступными командами и параметрами по сравнению с иконки и выпадающие меню графического пользовательского интерфейса, без повторных ссылок на руководства.

Типы

Интерфейсы командной строки операционной системы

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

Примеры интерпретаторов командной строки включают DEC ЦИФРОВОЙ командный язык (DCL) в OpenVMS и RSX-11, различные Оболочки Unix (ш, кш, csh, tcsh, zsh, трепать, так далее.), CP / M с КПК, ДОС ‘ COMMAND.COM, так же хорошо как OS / 2 и окна CMD.EXE программы, последние группы в значительной степени основаны на DEC RSX-11 и RSTS CLI. В большинстве операционных систем можно заменить программу оболочки по умолчанию альтернативными; примеры включают 4ДОС для DOS, 4OS2 для OS / 2 и 4NT / Принять командование для Windows.

Хотя термин «оболочка» часто используется для описания интерпретатора командной строки, строго говоря, «оболочкой» может быть любая программа, составляющая пользовательский интерфейс, включая полностью графически ориентированные. Например, графический интерфейс Windows по умолчанию — это программа оболочки с именем EXPLORER.EXE, как определено в строке SHELL = EXPLORER.EXE в файле конфигурации WIN.INI. Эти программы являются оболочками, но не интерфейсами командной строки.

Интерфейсы командной строки приложения

Прикладные программы (в отличие от операционных систем) могут также иметь интерфейсы командной строки.

Прикладная программа может не поддерживать ни один, ни один или все эти три основных типа механизмов интерфейса командной строки:

• Параметры: Большинство операционных систем поддерживают средства передачи дополнительной информации программе при ее запуске. Когда программа запускается из оболочки командной строки ОС, дополнительный текст, предоставляемый вместе с именем программы, передается в запущенную программу.
• Интерактивные сеансы командной строки: После запуска программа может предоставить оператору независимые средства для ввода команд в виде текста.
• Межпроцессного взаимодействия: Большинство операционных систем поддерживают средства межпроцессного взаимодействия (Например, стандартные потоки или же именованные каналы ). Командные строки из клиентских процессов могут быть перенаправлены в программу CLI одним из этих методов.

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

Ранние игры Sierra, такие как первые три Королевский квест games (1984–1986) использовали команды из внутренней командной строки для перемещения персонажа в графическом окне.

История

Интерфейс командной строки эволюционировал из формы диалога, который когда-то проводился людьми через телетайп (TTY) машины, в которых люди-операторы удаленно обмениваются информацией, обычно по одной строке текста за раз. Ранние компьютерные системы часто использовали телепринтеры как средство взаимодействия с человеком-оператором. Компьютер стал одним из концов модели телетайпа от человека к человеку. Итак, вместо того, чтобы человек общался с другим человеком через телетайп, человек общался с компьютером.

Механический телетайп был заменен на «стекло тти», клавиатура и экран, имитирующие телетайп. «Умные» терминалы разрешены дополнительные функции, такие как перемещение курсора по всему экрану или локальное редактирование данных на терминале для передачи на компьютер. Как микрокомпьютерная революция заменил традиционные — миникомпьютер + терминалы — совместное времяпровождение архитектура, аппаратные терминалы заменены на эмуляторы терминала — Программное обеспечение для ПК, которое интерпретировало сигналы терминала, передаваемые через ПК последовательные порты. Обычно они использовались для сопряжения нового ПК организации с существующими мини- или мэйнфреймами или для подключения ПК к ПК. Некоторые из этих компьютеров работали Электронная доска объявлений программного обеспечения.

Интерфейсы командной строки для ранних операционных систем были реализованы как часть резидентный монитор программы и не могли быть легко заменены. Первая реализация оболочки в качестве заменяемого компонента была частью Мультики совместное времяпровождение Операционная система.^[1] В 1964 г. Вычислительный центр Массачусетского технологического института штатный сотрудник Луи Пузен разработал RUNCOM инструмент для выполнения командных сценариев с возможностью подстановки аргументов.^[2] Пузен ввел термин «ракушка «описать технику использования команд, таких как язык программирования, и написал статью о том, как реализовать эту идею в Мультики Операционная система.^[3] Позен вернулся в родную Францию ​​в 1965 году, и первая оболочка Multics была разработана компанией Гленда Шредер.^[2]

Первый Оболочка Unix, то Оболочка V6, был разработан Кен Томпсон в 1971 г. Bell Labs и был смоделирован на основе оболочки Multics Шредера.^[4][5] В Оболочка Борна был представлен в 1977 году как замена корпуса V6. Хотя он используется как интерактивный интерпретатор команд, он также был задуман как язык сценариев и содержит большинство функций, которые обычно считаются для создания структурированных программ. Оболочка Борна привела к разработке KornShell (кш), Раковина альмквиста (ясень) и популярные Оболочка Bourne-Again (или Баш).^[5]

Сами ранние микрокомпьютеры были основаны на интерфейсе командной строки, таком как CP / M, ДОС или же AppleSoft BASIC. В течение 1980-х и 1990-х годов введение Apple Macintosh и из Майкрософт Виндоус на ПК интерфейс командной строки был заменен основным пользовательским интерфейсом на Графический интерфейс пользователя. Командная строка оставалась доступной в качестве альтернативного пользовательского интерфейса, часто используемого системные администраторы и другие продвинутые пользователи для системного администрирования, компьютерное программирование и пакетная обработка.

В ноябре 2006 г. Microsoft выпущена версия 1.0 Windows PowerShell (ранее под кодовым названием Монада), которые сочетают в себе функции традиционных оболочек Unix с их проприетарными объектно-ориентированными .NET Framework. MinGW и Cygwin находятся Открытый исходный код пакеты для Windows, которые предлагают Unix-подобный CLI. Microsoft предоставляет MKS Inc. с кш выполнение Оболочка МКС Корн для Windows через их Сервисы для UNIX добавить.

С 2001 г. Macintosh Операционная система macOS был основан на Unix-подобный операционная система называется Дарвин. На этих компьютерах пользователи могут получить доступ к Unix-подобному интерфейсу командной строки, запустив эмулятор терминала программа называется Терминал, который находится в подпапке Utilities папки Applications, или путем удаленного входа в систему с помощью ssh. Z оболочка оболочка по умолчанию для macOS; трепать, tcsh, а KornShell также предоставляются. Перед macOS Catalina, по умолчанию использовался bash.

использование

Интерфейс командной строки используется всякий раз, когда большой словарь команд или запросов в сочетании с широким (или произвольным) диапазоном параметров может быть введен в виде текста быстрее, чем с использованием чистого графического интерфейса. Обычно это происходит с командные оболочки операционной системы. Интерфейсы командной строки также используются системами с недостаточными ресурсами для поддержки графического пользовательского интерфейса. Некоторые компьютерные языковые системы (например, Python, Четвертый, LISP, Rexx, и многие диалекты БАЗОВЫЙ ) предоставляют интерактивный режим командной строки для быстрой оценки кода.

Интерфейсы командной строки часто используются программистами и системными администраторами в инженерной и научной среде, а также технически продвинутыми пользователями персональных компьютеров. Интерфейсы командной строки также популярны среди людей с нарушениями зрения, поскольку команды и ответы могут отображаться с помощью обновляемые дисплеи Брайля.

Анатомия оболочки командной строки

Общий шаблон интерфейса командной строки ОС^[6][7] является:

Подсказка команда param1 param2 param3… paramN

• Подсказка — генерируется программой, чтобы предоставить клиенту контекст.
• Команда — предоставляется клиентом. Команды обычно бывают одного из трех классов:
  1. Внутренний команды распознаются и обрабатываются самим интерпретатором командной строки и не зависят от какого-либо внешнего исполняемого файла.
  2. Включено Команды запускают отдельные исполняемые файлы, которые обычно считаются частью операционной среды и всегда включены в ОС.
  3. Внешний Команды запускают исполняемые файлы, которые не являются частью базовой ОС, но добавлены другими сторонами для определенных целей и приложений.
• param1… paramN — Необязательные параметры, предоставляемые клиентом. Формат и значение параметров зависят от выданной команды. В случае включенных или внешних команд значения параметров доставляются программе (заданной командой) по мере ее запуска ОС. Параметры могут быть либо Аргументы или же Опции.

В этом примере разделителями между элементами командной строки являются пробельные символы а разделитель конца строки — это новая линия разделитель. Это широко используемое (но не универсальное) соглашение для интерфейсов командной строки.

CLI обычно можно рассматривать как состоящий из синтаксис и семантика. В синтаксис это грамматика, которой должны следовать все команды. В случае операционные системы, ДОС и Unix каждый определяет свой собственный набор правил, которым должны следовать все команды. В случае встроенные системы, каждый поставщик, например Nortel, Juniper Networks или же Cisco Systems, определяет свой собственный набор правил, которым соответствуют все команды в их CLI. Эти правила также определяют, как пользователь перемещается по системе команд. В семантика определить, какие операции возможны, с какими данными могут выполняться эти операции и как грамматика представляет эти операции и данные — символическое значение в синтаксисе.

Два разных интерфейса командной строки могут согласовывать либо синтаксис, либо семантику, но только тогда, когда они соглашаются с обоими, их можно считать достаточно похожими, чтобы позволить пользователям использовать оба интерфейса командной строки без необходимости что-либо изучать, а также для возможности повторного использования сценариев .

Простой интерфейс командной строки отобразит приглашение, примите «командную строку», введенную пользователем, завершенную Введите ключ, затем выполните указанную команду и обеспечьте текстовое отображение результатов или сообщений об ошибках. Расширенные интерфейсы командной строки будут проверять, интерпретировать и расширять параметры командной строки перед выполнением указанной команды и, при необходимости, захватывать или перенаправлять ее вывод.

В отличие от кнопки или пункта меню в графическом интерфейсе, командная строка обычно самодокументируется, в ней указывается, что именно пользователь хочет сделать. Кроме того, командные строки обычно включают много значения по умолчанию которые можно изменить, чтобы настроить результаты. Полезные командные строки можно сохранить, назначив строка символов или же псевдоним для представления полной команды, или несколько команд могут быть сгруппированы для выполнения более сложной последовательности — например, скомпилировать программу, установить ее и запустить — создавая единый объект, называемый процедурой команды или сценарием, который сам по себе может рассматриваться как команда. Эти преимущества означают, что пользователь должен вычислить сложную команду или серию команд только один раз, потому что их можно сохранить, чтобы использовать снова.

Команды, передаваемые в оболочку CLI, часто имеют одну из следующих форм:

• сделать кое-что как файлы
• doSomething как sourceFile destinationFile
• doSomething как outputFile
• doSomething how | doSomething how | doSomething how> outputFile

куда сделай что-нибудь фактически является глагол, как ан наречие (например, должна ли команда выполняться «подробно» или «тихо») и toFiles объект или объекты (обычно один или несколько файлов), на которые должна действовать команда. В > в третьем примере — оператор перенаправления, сообщая интерпретатору командной строки отправлять выходные данные команды не в свой стандартный вывод (экран), а в указанный файл. Это перезапишет файл. С помощью >> перенаправит вывод и добавит его в файл. Другой оператор перенаправления — это вертикальная полоса (|), что создает трубопровод где выход одной команды становится входом для следующей команды.

CLI и защита ресурсов

Можно изменить набор доступных команд, изменив пути, отображаемые в ДОРОЖКА переменная окружения. В Unix команды также должны быть помечены как исполняемый файл файлы. Каталоги в переменной пути ищутся в том порядке, в котором они указаны. Изменив порядок пути, можно запустить, например, OS2 MDOS E.EXE вместо OS2 E.EXE, если по умолчанию установлено обратное. Также работает переименование исполняемых файлов: например, люди часто переименовывают свой любимый редактор в EDIT.

Командная строка позволяет ограничивать доступные команды, например доступ к расширенным внутренним командам. Окна CMD.EXE Является ли это. Часто условно-бесплатные программы ограничивают диапазон команд, включая печать команды «ваш администратор отключил запуск командных файлов» из командной строки.

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

Командная строка

«Командная строка» перенаправляется сюда. Для компонента Windows под названием Command Prompt см. cmd.exe.

Командная строка (или просто Подсказка) представляет собой последовательность (одного или нескольких) символов, используемых в интерфейсе командной строки, чтобы указать готовность принять команды. Это буквально подсказки пользователь предпринять действия. Подсказка обычно заканчивается одним из символов $, %, #,^[8][9] :, > или же -^[10] и часто включает другую информацию, такую ​​как путь текущего рабочий каталог и имя хоста.

На многих Unix и производные системы подсказка обычно заканчивается на $ или же % если пользователь обычный пользователь, но в # если пользователь суперпользователь («корень» в терминологии Unix).

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

В DOS ‘COMMAND.COM и в Windows NT cmd.exe пользователи могут изменить приглашение, выполнив ПОДСКАЗКА команду или напрямую изменив значение соответствующего %ПОДСКАЗКА% переменная окружения. По умолчанию большинство современных систем C: > стиль получается, например, с ЗАПРОСИТЬ $ P $ G. По умолчанию старые системы DOS, C> получается просто ПОДСКАЗКА, хотя в некоторых системах это приводит к появлению более новых C: > стиль, если только он не используется на дисководах A: или B :; в этих системах ЗАПРОСИТЬ $ N $ G может использоваться для отмены автоматического значения по умолчанию и явного переключения на более старый стиль.

Многие системы Unix имеют $ PS1 переменная (строка приглашения 1),^[11] хотя другие переменные также могут влиять на подсказку (в зависимости от ракушка использовал). в трепать оболочка, подсказка формы:

[время] пользователь @ хост: work_dir $

можно установить, выполнив команду

экспорт PS1='[ t]  u @  H:  W $'

В zsh в $ RPROMPT переменная управляет необязательной «подсказкой» в правой части дисплея. Это не настоящая подсказка, поскольку место ввода текста не меняется. Он используется для отображения информации в той же строке, что и приглашение, но с выравниванием по правому краю.

В ОС RISC командная строка — это * символ, и, следовательно, (ОС) команды CLI часто называют «командами звездочки».^[12] Можно также получить доступ к тем же командам из других командных строк (например, BBC BASIC командная строка), поставив перед командой *.

Аргументы

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

Когда командный процессор активен, программа обычно вызывается путем ввода ее имени, за которым следуют аргументы командной строки (если есть). Например, в Unix и Unix-подобный средах, пример аргумента командной строки:

«file.s» — это аргумент командной строки, который сообщает программе rm удалить файл «file.s».

Некоторые языки программирования, например C, C ++ и Ява, позволить программе интерпретировать аргументы командной строки, обрабатывая их как строковые параметры в основная функция. Другие языки, например Python, выставить специфичную для операционной системы API (функциональность) через sys модуль, и в частности sys.argv для «аргументов командной строки».

В Unix-подобные операционные системы, одиночный дефис, используемый вместо имени файла, является специальным значением, указывающим, что программа должна обрабатывать данные, поступающие из стандартный ввод или отправьте данные в стандартный вывод.

Параметр командной строки

А параметр командной строки или просто вариант (также известный как флаг или же выключатель) изменяет работу команды; эффект определяется программой команды. Параметры следуют за именем команды в командной строке, разделенных пробелами. Пробел перед первым вариантом не всегда требуется, например Dir /? и DIR /? в DOS, которые имеют такой же эффект^[10] перечисления доступных параметров команды DIR, тогда как dir --help (во многих версиях Unix) делает требует, чтобы перед параметром был хотя бы один пробел (с учетом регистра).

Формат параметров широко варьируется в зависимости от операционной системы. В большинстве случаев синтаксис является условным, а не требованиями операционной системы; вся командная строка — это просто строка, переданная программе, которая может обрабатывать ее любым способом, который хочет программист, при условии, что интерпретатор может определить, где заканчивается имя команды и начинаются ее аргументы и параметры.

Несколько репрезентативных примеров параметров командной строки, относящихся к перечислению файлов в каталоге, чтобы проиллюстрировать некоторые соглашения:

Сокращение команд

В Мультики, параметры командной строки и ключевые слова подсистемы могут быть сокращены. Эта идея, кажется, происходит из Язык программирования PL / I, с его сокращенными ключевыми словами (например, STRG для STRINGRANGE и DCL для DECLARE). Например, в подсистеме Multics «forum» -long_subject параметр может быть сокращен -lgsj. Для команд Multics также часто используются сокращения, обычно соответствующие начальным буквам слов, которые соединяются вместе с подчеркиванием для формирования имен команд, например, использование сделал за delete_iacl_dir.

В некоторых других системах сокращения являются автоматическими, например, разрешая достаточное количество первых символов имени команды, чтобы однозначно идентифицировать ее (например, SU как сокращение для СУПЕРПОЛЬЗОВАТЕЛЬ), в то время как другие могут иметь заранее запрограммированные определенные сокращения (например, MD за MKDIR в COMMAND.COM) или определяемых пользователем через пакетные сценарии и псевдонимы (например, псевдоним md mkdir в tcsh ).

Соглашения об опциях в DOS, Windows, OS / 2

В DOS, OS / 2 и Windows разные программы, вызываемые из их COMMAND.COM или CMD.EXE (или внутренних их команд), могут использовать разный синтаксис в одной и той же операционной системе. Например:

• Параметры могут быть обозначены одним из «символов переключения»: /, -, или любое из них может быть разрешено. Смотри ниже.
• Они могут быть или не быть чувствительный к регистру.
• Иногда параметры и их аргументы выполняются вместе, иногда разделяются пробелами, а иногда и символом, обычно : или же =; таким образом Prog -f имя файла, Prog -f имя файла, Prog -f: имя файла, Prog -f = имя файла.
• Некоторые программы позволяют комбинировать односимвольные параметры;^[10] другие нет. Выключатель -fA может означать то же, что и -f -A,^[10] или он может быть неправильным, или это может быть действительный, но другой параметр.

В ДОС, OS / 2 и Windows, косая черта (/) является наиболее распространенным, хотя иногда используется дефис-минус. Во многих версиях DOS (MS-DOS / PC DOS 2.xx и выше все версии DR-DOS начиная с 5.0, а также ПТС-ДОС, Встроенная DOS, FreeDOS и RxDOS ) сменить персонажа (иногда сокращенно переключатель или же Switchchar), который будет использоваться, определяется значением, возвращаемым из системный вызов (ИНТ 21ч / AX = 3700h). Символ по умолчанию, возвращаемый этим API, — /, но его можно изменить на дефис-минус в вышеупомянутых системах, за исключением Datalight ROM-DOS и MS-DOS / PC DOS 5.0 и выше, которые всегда возвращают / с этого звонка (если не один из многих доступных TSR для повторного включения функции SwitChar загружается). В некоторых из этих систем (MS-DOS / PC DOS 2.xx, DOS Plus 2.1, DR-DOS 7.02 и выше, PTS-DOS, Embedded DOS, FreeDOS и RxDOS) параметр также можно предварительно настроить с помощью ПЕРЕКЛЮЧАТЕЛЬ директива в CONFIG.SYS. Встроенная DOS компании General Software предоставляет команду SWITCH для той же цели, тогда как 4ДОС позволяет изменить настройку с помощью SETDOS / W: n.^[13] В DR-DOS, если настройка была изменена с /, первый разделитель каталогов в отображении ПОДСКАЗКА параметр $ G изменится на косую черту / (который также является допустимым разделителем каталогов в DOS, FlexOS, 4680 OS, 4690 OS, OS / 2 и Windows), тем самым служа визуальной подсказкой для обозначения изменения.^[10] Кроме того, текущая настройка отражается также во встроенных экранах справки.^[10] Некоторые версии DR-DOS COMMAND.COM также поддерживают токен PROMPT $/ для отображения текущей настройки. COMMAND.COM, начиная с DR-DOS 7.02, также предоставляет переменная псевдо-среды названный %/% чтобы можно было писать переносимые пакетные задания.^[14][15] Несколько внешних команд DR-DOS дополнительно поддерживают переменная окружения % SWITCHAR% для отмены настройки системы.

Однако многие программы настроены на использование / только вместо получения настройки переключателя перед синтаксическим анализом аргументов командной строки. Очень небольшое количество, в основном порты из Unix-подобных систем, запрограммировано на прием «-», даже если для него не установлен символ переключения (например, netstat и пинг, снабжен чем то Майкрософт Виндоус, примет /? option, чтобы перечислить доступные параметры, и все же в списке будет указано соглашение «-»).

Соглашения об опциях в Unix-подобных системах

В Unix-подобный системы, ASCII дефис-минус начинается варианты; новый (и GNU ) соглашение заключается в использовании два дефисы, затем слово (например, --Создайте), чтобы определить использование параметра, в то время как старое соглашение (и все еще доступное как вариант для часто используемых параметров) заключается в использовании одного дефиса, а затем одной буквы (например, -c); если за одним дефисом следуют две или более букв, это может означать, что указываются две опции, или это может означать, что вторая и последующие буквы являются параметром (например, именем файла или датой) для первой опции.

Два символа дефиса-минус без следующих букв (--) может указывать на то, что оставшиеся аргументы не следует рассматривать как параметры, что полезно, например, если само имя файла начинается с дефиса или если дополнительные аргументы предназначены для внутренней команды (например, судо ). Двойные дефисы-минусы также иногда используются для префикса «длинных опций», где используются более информативные имена опций. Это общая черта GNU программного обеспечения. В Getopt функция и программа, а Getopts обычно используются для анализа параметров командной строки.

Имена команд Unix, аргументы и параметры чувствительны к регистру (за исключением нескольких примеров, в основном, когда популярные команды из других операционных систем были перенесены в Unix).

Соглашения об опциях в других системах

FlexOS, 4680 ОС и 4690 ОС использовать -.

CP / M обычно используется [.

Система разговорного монитора (CMS) использует один левая скобка чтобы отделить параметры в конце команды от других аргументов. Например, в следующей команде параметры указывают, что целевой файл должен быть заменен, если он существует, а дата и время исходного файла должны быть сохранены на копии:КОПИРОВАТЬ исходный файл a целевой файл b (ЗАМЕНИТЬ СТАРЫЙ

Общие данные CLI под их RDOS, AOS и т. д. операционных систем, а также версии CLI, поставляемой с их Бизнес Базовый, использует только / в качестве символа переключателя не учитывает регистр и позволяет «локальным переключателям» некоторых аргументов управлять способом их интерпретации, например MAC / U LIB / S A B C $ LPT / л имеет глобальную опцию «U» к команде макроса ассемблера для добавления пользовательских символов, но два локальных переключателя: один для указания LIB должен быть пропущен на проходе 2, а другой для прямого вывода на принтер, $ LPT.

Встроенная справка по использованию

Одним из недостатков интерфейса командной строки является отсутствие подсказок пользователю относительно доступных действий.^{[нужна цитата ]} Напротив, графические интерфейсы обычно информируют пользователя о доступных действиях с помощью меню, значков или других визуальных подсказок.^{[нужна цитата ]} Чтобы преодолеть это ограничение, многие программы CLI отображают краткую сводку своих допустимых параметров, как правило, когда они вызываются без аргументов или с одним из ?, -?, -час, -ЧАС, /?, /час, /ЧАС, /Помощь, -помощь, или же --помощь.^[10][16][17]

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

Хотя это желательно, по крайней мере, для параметра справки, программы могут не поддерживать все вводные символы, приведенные в примере выше. В DOS, где значение по умолчанию символ параметра командной строки можно изменить с / к -, программы могут запрашивать SwitChar API для определения текущей настройки. Таким образом, если программа не поддерживает их все аппаратно, пользователю может потребоваться знать текущие настройки даже для того, чтобы иметь возможность надежно запросить помощь. Если SwitChar был изменен на - и поэтому / символ принимается как альтернативный разделитель пути также в командной строке DOS, программы могут неверно интерпретировать такие параметры, как /час или же /ЧАС как пути, а не параметры помощи.^[10] Однако, если он указан как первый или единственный параметр, большинство программ DOS по соглашению будут принимать его как запрос о помощи независимо от текущего значения SwitChar.^[10][13]

В некоторых случаях для программы могут быть выбраны разные уровни помощи. Некоторые программы, поддерживающие это, позволяют указывать уровень детализации в качестве необязательного аргумента параметра справки (как в / В: 1, / В: 2и т. д.), либо они предоставляют только краткую справку по параметрам справки со знаком вопроса и более длинный экран справки для других параметров справки.^[18]

В зависимости от программы иногда доступна дополнительная или более конкретная справка по принятым параметрам путем предоставления соответствующего параметра в качестве аргумента для параметра справки или наоборот (как в / H: W или в / W :? (при условии / Вт был бы еще один параметр поддерживаемый программой)).^{[19][20][17][16][18][nb 1]}

Подобно параметру справки, но гораздо реже, некоторые программы предоставляют дополнительную информацию о себе (например, режим, статус, версию, автора, лицензию или контактную информацию) при вызове с параметром «о», например -!, /!, -о, или же --о.^[16]

Поскольку ? и ! символы обычно также служат другим целям в командной строке, они могут быть доступны не во всех сценариях, поэтому они не должны быть единственными параметрами для доступа к соответствующей справочной информации.

Если необходима более подробная справка, чем предоставляется встроенной внутренней справкой программы, многие системы поддерживают специальный внешний «помощь команда«команда (или аналогичная), которая принимает имя команды в качестве параметра вызова и вызывает внешнюю справочную систему.

В семействе DR-DOS ввод /? или же /ЧАС на COMMAND.COM подсказка вместо самой команды будет отображать динамически сгенерированный список доступных внутренних команд;^[10] 4ДОС и NDOS поддержите ту же функцию, набрав ? по запросу^[13] (что также поддерживается более новыми версиями DR-DOS COMMAND.COM); внутренние команды могут быть индивидуально отключены или включены повторно через SETDOS / I.^[13] В дополнение к этому, некоторые новые версии DR-DOS COMMAND.COM также принимают ?% команда для отображения списка доступных встроенных переменные псевдо-среды. Помимо того, что они предназначены для быстрой справки, их можно использовать в пакетных заданиях для запроса возможностей базового процессора командной строки.^[10]

Синтаксис описания команды

Встроенная справка по использованию и страницы руководства обычно используют небольшой синтаксис для описания допустимой формы команды:^{[21][22][23][nb 2]}

• угловые кронштейны для требуется параметры: пинг <имя хоста>
• квадратные скобки для необязательный параметры: mkdir [-p] <имя>
• эллипсы для повторяется Предметы: cp [source2…]
• вертикальные полосы для выбор пунктов: netstat {-t | -u}

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

Космический персонаж

Во многих областях вычислений, но особенно в командной строке, космический символ может вызвать проблемы, поскольку он имеет две различные и несовместимые функции: как часть команды или параметра или как параметр или имя разделитель. Двусмысленность может быть предотвращена либо путем запрета встроенных пробелов в именах файлов и каталогов в первую очередь (например, путем замены их на подчеркивает _), или заключив имя в пробелы между символами кавычек или используя escape-символ перед пробелом обычно обратная косая черта (). Например

Длинный путь / длинное название программы Первый параметр Второй параметр …

неоднозначно (является ли «имя программы» частью имени программы или двумя параметрами?); тем не мение

Long_path / Long_program_name Parameter_one Parameter_two …,

LongPath / LongProgramName Параметр Один Параметр Два …,

«Длинный путь / Длинное имя программы» «Первый параметр» «Второй параметр» …

и

Длинный путь / Длинный программа имя Параметр один Параметр два …

не неоднозначны. Unix Операционные системы на основе минимизируют использование встроенных пробелов, чтобы свести к минимуму необходимость в кавычках. В Майкрософт Виндоус, часто приходится использовать кавычки, потому что встроенные пробелы (например, в именах каталогов) являются обычным явлением.

Интерпретатор командной строки

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

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

Интерпретаторы командной строки позволяют пользователям вводить различные команды очень эффективным (и часто кратким) способом. This requires the user to know the names of the commands and their parameters, and the syntax of the язык that is interpreted.

Unix #! mechanism and OS/2 EXTPROC command facilitate the passing of batch files to external processors. One can use these mechanisms to write specific command processors for dedicated uses, and process external data files which reside in batch files.

Many graphical interfaces, such as the OS/2 Менеджер по презентациям and early versions of Microsoft Windows use command-lines to call helper programs to open documents and programs. The commands are stored in the graphical shell^{[требуется разъяснение ]} or in files like the registry or the OS / 2 OS2USER.INI файл.

Ранняя история

The earliest computers did not support interactive input/output devices, often relying on sense switches and lights to communicate with the computer operator. This was adequate for batch systems that ran one program at a time, often with the programmer acting as operator. This also had the advantage of low overhead, since lights and switches could be tested and set with one machine instruction. Later a single системная консоль was added to allow the operator to communicate with the system.

From the 1960s onwards, user interaction with computers was primarily by means of command-line interfaces, initially on machines like the Телетайп Модель 33 ASR, but then on early ЭЛТ -основан компьютерные терминалы такой как VT52.

All of these devices were purely text based, with no ability to display graphic or pictures.^{[№ 3]} For business прикладные программы, text-based меню were used, but for more general interaction the command line was the interface.

Around 1964 Луи Пузен introduced the concept and the name ракушка в Мультики, building on earlier, simpler facilities in the Совместимая система разделения времени (CTSS).^{[25][нужен лучший источник ]}

From the early 1970s the Unix operating system adapted the concept of a powerful command-line environment, and introduced the ability to трубка the output of one command in as input to another. Unix also had the capability to save and re-run strings of commands as «сценарии оболочки » which acted like custom commands.

The command-line was also the main interface for the early home computers such as the Commodore PET, Яблоко II и BBC Micro – almost always in the form of a БАЗОВЫЙ interpreter. When more powerful business oriented microcomputers arrived with CP / M и позже ДОС компьютеры, такие как IBM PC, the command-line began to borrow some of the syntax and features of the Unix shells such as globbing и трубопровод вывода.

The command-line was first seriously challenged by the PARC GUI approach used in the 1983 Яблочная Лиза и 1984 Apple Macintosh. A few computer users used GUIs such as GEOS и Windows 3.1 but the majority of IBM PC users did not replace their COMMAND.COM shell with a GUI until Windows 95 был выпущен в 1995 году.^[26][27]

Modern usage as an operating system shell

While most non-expert computer users now use a GUI almost exclusively, more advanced users have access to powerful command-line environments:

• The default VAX/VMS command shell, using the DCL language, has been ported to Windows systems at least three times, including PC-DCL and Acceler8 DCL Lite. Unix command shells have been ported to VMS and DOS/Windows 95 and Windows NT types of operating systems. COMMAND.COM and Windows NT cmd.exe have been ported to Windows CE and presumably works on Microsoft Windows NT Embedded 4.0
• Windows Набор ресурсов и Windows Services for Unix include Korn and the Bourne shells along with a Perl interpreter (Services of Unix contains Active State ActivePerl in later versions and Interix for versions 1 and 2 and a shell compiled by Microsoft)
• IBM OS/2 (and derivatives such as eComStation и ArcaOS ) имеет cmd.exe процессор. This copies the COMMAND.COM commands, with extensions to REXX.
• cmd.exe and COMMAND.COM are part of the Windows NT stream of operating systems.
• Yet another cmd.exe is a stripped-down shell for Windows CE 3.0.
• An MS-DOS type interpreter called PocketDOS has been ported to Windows CE machines; the most recent release is almost identical to MS-DOS 6.22 and can also run Windows 1, 2, and 3.0, QBasic and other development tools, 4NT and 4DOS. The latest release includes several shells, namely MS-DOS 6.22, PC DOS 7, DR DOS 3.xx, and others.
• Windows users have a CLI environment named Командная строка Windows, which might use the CScript interface to alternate programs. PowerShell provides a command-line interface, but its applets are not written in Сценарий оболочки. Implementations of the Оболочка Unix are also available as part of the POSIX sub-system,^[28] Cygwin, Набор инструментов MKS, UWIN, Оболочка Hamilton C and other software packages. Available shells for these interoperability tools include csh, ksh, ш, трепать, rsh, tclsh и реже zsh, psh
• COMMAND.COM (4DOS), Windows NT cmd.exe (4NT, TCC), and OS/2 cmd.exe (4OS2) and others based on them are enhanced shells which can be a replacement for the native shell or a means of enhancement of the default shell.
• Реализации PHP have a shell for interactive use called php-cli.
• Стандарт Tcl / Tk has two interactive shells, Tclsh and Wish, the latter being the GUI version.
• Python, Рубин, Lua, XLNT, and other interpreters also have command shells for interactive use.
• FreeBSD использует tcsh as its default interactive shell for the суперпользователь, и пепел as default scripting shell.
• яблоко macOS^{[№ 4]} и много Дистрибутивы Linux иметь Баш реализация Оболочка Unix. Early versions of macOS used tcsh as the default shell.
• Встроенный Linux (and other embedded Unix-подобный ) devices often use the Пепел implementation of the Unix shell, as part of Busybox.
• Android использует мкш shell,^[29][30] which replaces a shell derived from пепел^[31] that was used in older Android versions, supplemented with commands from the separate ящик для инструментов^[32] двоичный.
• Routers with Cisco IOS,^[33] Юнос^[34] and many others are commonly configured from the command line.

Сценарии

Most command-line interpreters support сценарии, to various extents. (They are, after all, interpreters of an interpreted programming language, albeit in many cases the language is unique to the particular command-line interpreter.) They will interpret scripts (variously termed сценарии оболочки или же пакетные файлы ) written in the язык that they interpret. Some command-line interpreters also incorporate the interpreter engines of other languages, such as REXX, in addition to their own, allowing the executing of scripts, in those languages, directly within the command-line interpreter itself.

Наоборот, scripting programming languages, in particular those with an оценка функция (such as REXX, Perl, Python, Рубин или же Jython ), can be used to implement command-line interpreters and filters. Для немногих операционные системы, в первую очередь ДОС, such a command interpreter provides a more flexible command-line interface than the one supplied. In other cases, such a command interpreter can present a highly customised user interface employing the user interface and input/output facilities of the language.

Other command-line interfaces

The command line provides an interface between programs as well as the user. In this sense, a command line is an alternative to a диалоговое окно. Editors and databases present a command line, in which alternate command processors might run. On the other hand, one might have options on the command line, which opens a dialog box. The latest version of ‘Take Command’ has this feature. DBase used a dialog box to construct command lines, which could be further edited before use.

Programs like BASIC, diskpart, Эдлин, and QBASIC all provide command-line interfaces, some of which use the system shell. Basic is modeled on the default interface for 8-bit Intel computers. Calculators can be run as command-line or dialog interfaces.

Emacs provides a command-line interface in the form of its minibuffer. Commands and arguments can be entered using Emacs standard text editing support, and output is displayed in another buffer.

There are a number of text mode games, like Приключение или же King’s Quest 1-3, which relied on the user typing commands at the bottom of the screen. One controls the character by typing commands like ‘get ring’ or ‘look’. The program returns a text which describes how the character sees it, or makes the action happen. В текстовое приключение Автостопом по Галактике, кусок interactive fiction на основе Douglas Adam’s book of the same name, is a teletype-style command-line game.

The most notable of these interfaces is the standard streams interface, which allows the output of one command to be passed to the input of another. Text files can serve either purpose as well. This provides the interfaces of piping, filters and redirection. Under Unix, devices are files too, so the normal type of file for the shell used for stdin,stdout and stderr is a tty device file.

Another command-line interface allows a shell program to launch helper programs, either to launch documents or start a program. The command is processed internally by the shell, and then passed on to another program to launch the document. The graphical interface of Windows and OS/2 rely heavily on command-lines passed through to other programs – console or graphical, which then usually process the command line without presenting a user-console.

Programs like the OS/2 E editor and some other IBM редакторы, can process command-lines normally meant for the shell, the output being placed directly in the document window.

A web browser’s URL input field can be used as a command line. It can be used to «launch» веб-приложения, access browser configuration, as well as perform a search. Google, which has been called «the command line of the internet» will perform a domain-specific search when it detects search parameters in a known format.^[35] This functionality is present whether the search is triggered from a browser field or on Google’s website.

Много видеоигры on the PC feature a command line interface often referred to as a console. It is typically used by the game developers during development and by mod developers for debugging purposes as well as for cheating or skipping parts of the game.

Смотрите также

• Comparison of command shells
• List of command-line interpreters
• Пакетная обработка
• Пакетный файл
• Console application
• Директива переводчика
• Цикл чтения-оценки-печати
• Оболочка (вычисления)
• Язык сценариев
• Сценарий оболочки
• clig
• Компьютерный терминал
• Эмулятор терминала
• Run command
• Graphical user interface § Comparison to other interfaces
• In the Beginning… Was the Command Line

Примечания

Рекомендации

внешняя ссылка

• The Roots of DOS David Hunter, Softalk for the IBM Personal Computer March 1983. Archived at Patersontech.com since 2000.
• Command-Line Reference: Microsoft TechNet Database «Command-Line Reference»

Предисловие от автора, Рича Тёрнера из Microsoft. Это статья о командной строке: от её появления и эволюции до планов капитального ремонта Windows Console и командной строки в будущих версиях Windows. Будь вы опытным профессионалом или новичком в IT, надеемся, что вы найдёте статью интересной.

Давным-давно в далёкой-далёкой серверной…

С первых дней развития информатики людям нужен был эффективный способ передавать компьютеру команды и данные и видеть результат выполнения этих команд/вычислений.

Одним из первых по-настоящему эффективных человеко-машинных интерфейсов стал Tele-Typewriter или «телетайп». Это электромеханическая машина с клавиатурой для ввода данных и каким-нибудь устройством вывода — сначала использовался принтер, позже экран.

Вводимые оператором символы локально буферизуются и отправляются с телетайпа на соседний компьютер или мейнфрейм в виде серии сигналов по электрическому кабелю (например, RS-232) со скоростью 10 символов в секунду (110 бод, бит в секунду, bps):

Телетайп Model 33 ASR

Примечание: Дэвид Гессвейн ведёт отличный сайт по PDP-8, где можно найти больше информации об ASR33 (и соответствующей технологии PDP-8), в том числе фотографии, видео и др.

Программа на компьютере получает введённые символы, решает, что с ними делать, и, возможно, асинхронно отправляет ответ на телетайп. Телетайп может напечатать/показать оператору полученные символы.

Затем технология улучшилась, скорость передачи выросла до 19200 bps, а шумные и дорогие принтеры заменили ЭЛТ-дисплеями (широко распространённый тип дисплеев в 80-е и 90-е годы), как на популярном терминале DEC VT100:

Терминал DEC VT100

Хотя технология улучшилась, но эта модель — терминал отправляет символы программе на компьютере, а он выдаёт текст для пользователя — осталась и сегодня как фундаментальная модель взаимодействия всех командных строк и консолей на всех платформах!

Архитектура терминала и командной строки

Модель по-своему элегантна. Одна из причин — в сохранении простоты и цельности каждого компонента: клавиатура выдаёт символы которые буферизуются как электрические сигналы. Устройство вывода просто выдаёт на дисплей (бумагу/экран) символы, полученные с компьютера.

На каждом этапе в системе передаётся только поток символов, так что это относительно простой процесс для внедрения различной инфраструктуры связи. Например, для добавления модемов, чтобы передавать потоки входных и выходных символов на большие расстояния по телефонным линиям.

Кодировка текста

Важно помнить, что терминалы и компьютеры обмениваются данными через потоки символов. При нажатии клавиши на клавиатуре терминала на подключенный компьютер отправляется значение, представляющее введённый символ. Нажмите клавишу ’A’ — и отправляется значение 65 (0x41). Нажмите ’Z’ — и отправляется 90 (0x5a).

7-битная кодировка ASCII

Список символов и их значений определён в стандарте American Standard Code for Information Interchange (ASCII), он же стандарт ISO/IEC 646 / ECMA-6 — «7-битный кодированный набор символов», который определяет:

• 128 значений, представляющих печатные латинские символы A−Z (65-90), a−z (97−122), 0−9 (48−57)
• Много общих знаков препинания
• Несколько непечатаемых управляющих кодов (0−31 и 127):

Стандартные символы 7-битной ASCII

Когда 7 бит недостаточно: кодовые страницы

Однако 7 бит не обеспечивают достаточно места для кодирования многих диакритических знаков, знаков препинания и символов, используемых в других языках и регионах. Так что с добавлением дополнительного бита можно расширить таблицу символов ASCII дополнительными наборами «кодовых страниц» для символов 128−255 (и возможного переопределения нескольких непечатаемых символов ASCII).

Например, IBM ввела кодовую страницу 437 с несколькими графическими символами вроде ╫ (215) и ╣(185) и математическими, включая π (227) и ± (241), а также переопределила печатные символы для обычно непечатаемых символов 1−31:

Кодовая страница 437

Кодовая страница Latin-1 определяет множество символов, используемых языками на основе латиницы:

Кодовая страница Latin-1

Во многих окружениях командной строки и оболочках можно изменять текущую кодовую страницу, чтобы терминал отображал различные символы (в зависимости от доступных шрифтов), особенно для символов со значением 128−255. Но неправильно указанная кодовая страница приведёт к отображению кракозябр. И да, «кракозябры» — это настоящий термин! Кто бы мог подумать?

Когда 8 бит недостаточно: Юникод

Кодовые страницы временно решили проблему, но у них много недостатков, например, они не позволяют отображать текст одновременно из нескольких кодовых страниц/языков. Таким образом, пришлось ввести новую кодировку, которая точно отображает каждый символ и алфавит для всех языков, известных человечеству, оставляя ещё много свободного места! Представляем Юникод.

Юникод — это международный стандарт (ISO/IEC 10646), который в данный момент определяет 137 439 символов из 146 современных и исторических письменностей, а также многие символы и глифы, в том числе многочисленные смайлики, которые широко используются практически в каждом приложении, платформе и устройстве. Юникод регулярно обновляется дополнительными системами письменности, новыми/исправленными смайликами, символами и т. д.

Юникод также определяет «непечатаемые» символы форматирования, которые позволяют, например, соединить символы и/или повлиять на предыдущие или последующие символы! Это особенно полезно в письменностях вроде арабской, где лигатура конкретного символа определяется окружающими. Эмодзи могут использовать соединительный символ нулевой ширины (zero width joiner), чтобы объединить несколько символов в один визуальный глиф. Например, эмодзи кота-ниндзя Microsoft формируются путём соединения кота с другими эмодзи:

Эмодзи кота-ниндзя Microsoft

Когда байтов слишком много: UTF-8!

Для уникального и систематического представления всех символов требуется большое пространство, до нескольких байт на каждый символ.

Поэтому для экономии было разработано несколько новых кодировок Юникода. Среди самых популярных — UTF-32 (4 байта на символ), UTF-16/UCS-2 (2 байта) и UTF-8 (1−4 байта на символ).

Во многом благодаря обратной совместимости с ASCII и экономии места UTF-8 стала самой популярной кодировкой Юникода в интернете. Она демонстрирует взрывной рост с 2008 года, когда обогнала по популярности ASCII и другие популярные кодировки:

Рост популярности кодировки UTF-8 (источник: Википедия)

Таким образом, поначалу терминалы поддерживали 7-битный, а затем 8-битный текст ANSI, но большинство современных терминалов поддерживают текст Unicode/UTF-8.

Итак, что такое командная строка и что такое оболочка?

«Командная строка» или CLI (интерфейс/интерпретатор командной строки) описывает самый фундаментальный механизм, через который человек управляет компьютером: CLI принимает введённый оператором ввод и выполняет требуемые команды.

Например, echo Hello отправляет текст «Hello» на устройство вывода (например, на экран). dir (Cmd) или ls (PowerShell/*NIX) перечисляет содержимое текущего каталога и т.д.

Раньше доступные команды были относительно простыми, но операторы требовали всё более изощрённых команд и возможности писать скрипты для автоматизации повторяющихся или сложных задач. Таким образом, процессоры командной строки стали сложнее и превратились в то, что теперь называют «оболочкой» командной строки (shell).

В Unix/Linux оригинальная оболочка Unix (sh) породила множество оболочек, включая Korn shell (ksh), C shell (csh) и Bourne Shell (sh). В свою очередь, на их основе создан Bourne Again Shell (bash) и т.д.

В мире Microsoft:

• Оригинальный MS-DOS (command.com) был относительно простой оболочкой командной строки
• «Командная строка» Windows NT (cmd.exe) разработана с учётом совместимым с устаревшими скриптами command.com, плюс добавлены несколько команд для новой, более мощной операционной системы
• В 2006 году Microsoft выпустила Windows PowerShell
  • PowerShell — это современная объектная оболочка командной строки, которая позаимствовала функции других оболочек и включает в себя возможности .NET CLR и фреймворка .NET
  • С помощью PowerShell можно писать скрипты и автоматизировать практически все аспекты одного или нескольких компьютеров под Windows, сети, систем хранения данных, БД и т.д.
  • В 2017 году Microsoft открыла исходный код PowerShell, разрешив запуск на macOS, разных вариантах Linux и BSD
• В 2016 году Microsoft представила подсистему Windows для Linux (WSL)
  • Позволяет запускать обычные немодифицированные двоичные файлы Linux непосредственно в Windows 10
  • Пользователи устанавливают один или несколько обычных дистрибутивов Linux из магазина Windows
  • Можно запустить один или несколько экземпляров дистрибутива параллельно с другими, а также параллельно с существующими приложениями и средствами Windows
  • WSL позволяет запускать бок о бок все инструменты Windows и инструменты командной строки Linux без использования ресурсоёмких виртуальных машин

Мы ещё вернёмся к оболочкам командной строки Windows, но пока запомним, что существуют разные оболочки, они принимают команды, введённые пользователем/оператором, и выполняют широкий спектр задач по мере необходимости.

Современная командная строка

Современные компьютеры значительно мощнее «тупых терминалов» прошлого и обычно работают под управлением десктопной ОС (например, Windows, Linux, macOS) с графическим пользовательским интерфейсом (GUI). Такое окружение GUI позволяет нескольким приложениям работать одновременно в отдельных окнах на экране и/или невидимо в фоновом режиме.

Cmd, PowerShell и Ubuntu Linux под WSL работают на независимых инстансах консоли

На смену громоздким, неповоротливым электромеханическим телетайпам пришли современные консольные/терминальные приложения, которые работают в окошке на экране компьютера, но по-прежнему выполняют такие же необходимые функции, как аппаратные терминалы из прошлого.

Аналогично и приложения командной строки, к которым подключены терминалы, работают как и раньше: получают входные символы, решают, что делать с этими символами, (необязательно) выполняют работу — и могут выдать текст для отображения пользователю. Только вместо связи по медленным каналам TTY терминальные приложения и приложения командной строки на одной машине общаются по очень скоростным каналам Pseudo Teletype (PTY) в памяти.

Современная командная строка

Современные терминалы в основном взаимодействуют с приложениями командной строки, запущенными локально. Но конечно, они также могут взаимодействовать с приложениями командной строки, запущенными на других машинах в той же сети или даже с удалёнными машинами на другой стороне света через интернет. Это «удалённое» взаимодействие с командной строкой — мощный инструмент, который популярен на каждой платформе, особенно на *NIX.

Эволюция командной строки

Скромное начало: MS-DOS

На заре компьютерной индустрии управление большинством компьютеров осуществлялось путём ввода команд в командной строке. За рыночную долю боролись компьютеры под Unix, CP/M, DR-DOS и других. В итоге система MS-DOS стала стандартом де-факто для IBM PC и всех совместимых компьютеров:

MS-DOS 6.0

Как и большинство основных операционных систем того времени, интерпретатор командной строки или «оболочка» в MS-DOS предоставляла простой, но относительно эффективный набор команд и синтаксис командных скриптов для написания batch-файлов (.bat).

Предприятия крупного и малого бизнеса очень быстро взяли на вооружение MS-DOS и в совокупности создали многие миллионы скриптов, некоторые из которых всё ещё используются сегодня! Batch-скрипты применяются для автоматизации настройки ПК, установки/изменения параметров безопасности, обновления программного обеспечения, сборки кода и т.д.

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

Командная строка представляет мощный инструмент в руках человека, который имеет терпение и упорство, чтобы научиться выжимать максимум из доступных команд и инструментов. Но большинству обычных пользователей сложно эффективно управлять компьютером из командной строки. Большинству не нравилось, что нужно изучать и запоминать много словно мистических аббревиатур, чтобы компьютер произвёл хоть какое-нибудь полезное действие.

Требуется более удобный и ориентированный на производительность пользовательский интерфейс.

Графический интерфейс идёт в мейнстрим

Добро пожаловать в графический интерфейс пользователя (GUI), изобретённый в Xerox Alto.

Вскоре после изобретения появилось много конкурирующих GUI на компьютерах Lisa и Macintosh от Apple, Commodore Amiga (Workbench), Atari ST (DRI GEM), Acorn Archimedes (Arthur/RISC OS), Sun Workstation, X11/X Windows и многих других, в том числе Microsoft Windows.

Windows 1.0 вышла в 1985 году и являлась по сути приложением MS-DOS, которое предоставляло простое окружение GUI с плиточным окном, позволяя пользователям запускать несколько приложений бок о бок:

Windows 1.01 на MS-DOS

Windows 2.x, 3.x, 95 и 98 работали на базе MS-DOS. Более поздние версии Windows начали заменять некоторые функции MS-DOS альтернативами Windows (например, операции с файловой системой), но все они полагались на фундамент MS-DOS.

Примечание: Windows ME (Millennium Edition) стала интересным гибридом. В ней наконец-то заменили поддержку MS-DOS и поддержку реального режима из предыдущих версий Windows несколькими новыми функциями (особенно технологии Gaming & Media). Некоторые функции позаимствованы из Windows 2000 (например, новый стек TCP/IP), но настроены для работы на домашних ПК, которым трудно запустить полноценную NT.

Но Microsoft понимала, что не может бесконечно растягивать архитектуру и возможности MS-DOS и Windows. Требовалась новая операционная система с прицелом на будущее.

Microsoft — лидер рынка Unix! Да, серьёзно!

Разрабатывая MS-DOS, Microsoft также занималась поставкой Xenix — фирменного порта Unix версии 7 — для различных процессорных и машинных архитектур, включая Z8000, 8086/80286 и 68000.

К 1984 году Xenix от Microsoft стал самым популярным вариантом Unix в мире!

Тем временем распад Bell Labs — родины Unix — привёл к появлению AT&T, которая начала продавать Unix System V производителям компьютеров и конечным пользователям.

Microsoft понимала, что отсутствие собственной ОС ставит под угрозу её способности для развития. Поэтому было принято решение отказаться от Xenix: в 1987 году Microsoft передала Xenix своему партнёру Santa Cruz Operation (SCO), с которым работала над несколькими проектами по портированию и улучшению Xenix на различных платформах.

Microsoft + IBM == OS/2… ненадолго

В 1985 году Microsoft начала работать с IBM над новой операционной системой OS/2. Она изначально планировалась как «более функциональная DOS» для некоторых современных 32-битных CPU и с учётом других технологий, которые быстро порождались в IBM и у других OEM.

Но история OS/2 оказалась слишком бурной. В 1990 году Microsoft и IBM прекратили сотрудничество. Это было обусловлено рядом факторов, в том числе значительными культурными различиями между разработчиками IBM и Microsoft, проблемами планирования, а также взрывным успехом и ростом внедрения Windows 3.1. IBM продолжала разработку и поддержку OS/2 до конца 2006 года.

К 1988 году Microsoft убедилась, что будущий успех требует более масштабного, смелого и амбициозного подхода. Такой подход потребует новой, современной операционной системы, которая будет поддерживать амбициозные цели компании.

Большая ставка Microsoft: Windows NT

В 1988 году Microsoft пригласила Дэйва Катлера, создателя популярной и уважаемой операционной системы VAX/VMS в компании DEC. Его задача — создать новую, современную, независимую от платформы операционную систему, которой Microsoft будет владеть, контролировать и на которой во многом построит своё будущее.

Этой новой операционной системой стала Windows NT: фундамент, на котором построены Windows 2000, Windows XP, Windows Vista, Windows 7, Windows 8 и Windows 10, а также во все версии Windows Server, Windows Phone 7+, Xbox и HoloLens!

Windows NT изначально спроектирована как кроссплатформенная система. Сначала она поддерживала Intel i860, затем MIPS R3000, Intel 80386+, DEC Alpha и PowerPC. С тех пор семейство ОС Windows NT портировали для поддержки процессорных архитектур IA64 Itanium, x64 и ARM/ARM64, среди прочих.

Windows NT предоставляет интерфейс командной строки через терминальное приложение Windows Console и командную строку Command Prompt (cmd.exe). Cmd разработан на максимальную совместимость с пакетными скриптами MS-DOS, чтобы помочь бизнесу перейти на новую платформу.

Мощь PowerShell

Cmd сохраняется в Windows по сей день (и, вероятно, сохранится в течение многих десятилетий). Поскольку его основная задача — обеспечить максимальную обратную совместимость, Cmd редко улучшается. Даже «исправление ошибок» зачастую затруднено, если эти «баги» существовали в MS-DOS или более ранних версиях Windows!

В начале 2000-х оболочка Cmd уже устарела: Microsoft и её клиенты срочно нуждались в более мощной и гибкой командной строке. Из этой потребности появился PowerShell (который возник из «Манифеста Монады» Джеффри Сновера).

PowerShell — это объектно-ориентированная оболочка, в отличие от оболочек на основе файлов/потоков, которые принято использовать в мире *NIX: вместо потоков текста PowerShell обрабатывает потоки объектов. Он предоставляет авторам скриптов возможность прямого доступа и манипуляций с объектами и их свойствами вместо написания множества скриптов для анализа и обработки текста (как sed/grep/awk/lex/др.).

Созданные на базе .NET Framework и среды Common Language Runtime (CLR), язык и синтаксис PowerShell разработаны для объединения богатства экосистемы .NET со многими распространёнными и полезными функциями из множества других языков сценариев оболочки с акцентом на то, чтобы скрипты обеспечивали максимальную консистентность и исключительную… ну… мощь.

Чтобы узнать больше о PowerShell, рекомендую прочитать книгу «PowerShell в действии» (Manning Press), написанную Брюсом Пайеттом — разработчиком синтаксиса и языка PowerShell. В частности, первые несколько глав содержат подробное обоснование структуры языка.

PowerShell был принят для использования многими технологиями на платформе Microsoft, включая Windows, Exchange Server, SQL Server, Azure и многими другими. Он предоставляет очень согласованные команды для администрирования и управления практически всеми аспектами Windows и/или среды.

PowerShell Core — это PowerShell с открытым исходным кодом, доступное для Windows и различных версий Linux, BSD и macOS.

POSIX для NT, Interix и служб UNIX

При проектировании NT компания команда Катлера специально разработала ядро NT и операционную систему для поддержки нескольких подсистем-интерфейсов между кодом пользовательского режима и основным ядром.

Когда в 1993 году вышла первая Windows NT версии 3.1, она поддерживала несколько подсистем: МЅ-DOS, Windows, OS/2 и POSIX v1.2. Эти подсистемы позволяли на одной машине и базовой ОС запускать приложения, нацеленные на несколько платформ операционной системы без виртуализации или эмуляции — это внушительная разработка даже по меркам сегодняшнего дня!

Оригинальная реализация POSIX в Windows NT была приемлемой, но для неё требовались значительных улучшения. Поэтому Microsoft приобрела Softway Systems и её POSIX-совместимую подсистему Interix для NT. Изначально Interix поставлялась как отдельное дополнение, а затем её объединили с несколькими полезными утилитами и инструментами и выпустили в виде Services For Unix (SFU) в Windows Server 2003 R2 и Windows Vista. Однако поддержку SFU пришлось прекратить после Windows 8, в основном, из-за недостаточной популярности.

А потом произошла забавная вещь…

Windows 10 — новая эра для командной строки Windows!

В начале разработки Windows 10 компания открыла страницу UserVoice с вопросом, какие функции люди хотят реализовать в различных областях ОС. Сообщество разработчиков особенно громко требовало от Microsoft две вещи:

1. Внести значительные улучшения в консоль Windows
2. Предоставить пользователям возможность запускать средства Linux в Windows

На основе этих отзывов Microsoft сформировала две новые группы:

1. Группа разработки Windows Console и командной строки, которой поручили провести капитальный ремонт инфраструктуры Windows Console и командной строки
2. Группа разработки Windows Subsystem for Linux (WSL)

Остальное, как говорится, история!

Подсистема Windows для Linux (WSL)

Основанные на GNU/Linux «дистрибутивы» (сочетания ядра Linux и коллекций инструментов пользовательского режима) становятся всё популярнее, особенно на серверах и в облаке. Хотя в Windows имелась POSIX-совместимая среда выполнения, но SFU не мог запускать многие инструменты и двоичные файлы Linux из-за дополнительных системных вызовов и различий в поведении по сравнению с традиционной Unix/POSIX.

После анализа обратной связи от разработчиков и технически подкованных пользователей Windows, а также в связи с растущим спросом внутри самой Microsoft, компания изучила несколько вариантов, и в конечном итоге решила позволить на Windows запуск оригинальных немодифицированных бинарных файлов Linux!

В середине 2014 года Microsoft сформировала группу разработки того, что станет подсистемой Windows для Linux (WSL). WSL впервые анонсировали в сборке Build 2016, а вскоре предварительная версия вышла на канале Windows 10 Insider.

С тех пор WSL обновляется в большинстве инсайдерских сборок и в каждом крупном выпуске ОС с момента Anniversary Update осенью 2016 года. В каждой новой версии увеличивается функциональность, совместимость и стабильность WSL: в первой версии это был интересный эксперимент, который мог запускать лишь несколько распространённых программ Linux. При активной помощи сообщества (всем спасибо!) разработчики быстро дорабатывали WSL, так что вскоре она получила много новых возможностей и научилась запускать всё более сложные бинарники Linux.

Сегодня (середина 2018 года) WSL запускает большинство двоичных файлов Linux, программы, компиляторы, компоновщики, отладчикии т.д. Многие разработчики, IT-специалисты, инженеры DevOps и многие другие, кому необходимо запускать или создавать инструменты, приложения, службы Linux и т. д., получили резкое повышение производительности и возможность запускать свои любимые инструменты Linux вместе с любимыми инструментами для Windows на одном компьютере, без загрузки двух операционных систем.

Команда WSL продолжает улучшать WSL в части выполнения задач Linux, повышения производительности и интеграции с Windows.

Перезагрузка и капитальный ремонт Windows Console

В конце 2014 года проект по созданию подсистемы Windows для Linux (WSL) шёл полным ходом, и на фоне взрыва оживлённого интереса пользователей к командной строке стало очевидно, что консоль Windows явно нуждается в некотором апгрейде.

В частности, консоли не хватало многих функций, привычных для современных *NIX-совместимых систем, таких как возможность парсинга и вывода последовательностей ANSI/VT, широко используемых в мире *NIX для вывода насыщенного и подсвеченного текста и текстовых UI.

В чём тогда смысл разработки WSL, если пользователь не сможет корректно использовать инструменты Linux?

Ниже пример того, что отображает консоль Windows 7 и Windows 10: обратите внимание, что Windows 7 (слева) не в состоянии правильно отобразить VT, сгенерированный линуксовыми программами tmux, htop, Midnight Commander и cowsay, но они корректно выглядят в Windows 10 (справа):

Сравнение консоли Windows 7 и Windows 10

Так, в 2014 году была сформирована небольшая «группа Windows Console». На неё возложили задачу распутать, понять и улучшить кодовую базу Windows Console… которой к этому времени было около 28 лет — больше, чем программистам, которые работают над этим проектом.

Как подтвердит любой разработчик, которому когда-либо приходилось брать старый, грязный, плохо поддерживаемый код, улучшение такого кода представляет собой сложную задачу. Ещё сложнее не нарушить существующее поведение. Для обновления самой часто запускаемой программы в Windows, не нарушив работу миллионов клиентских скриптов, инструментов, скриптов авторизации, систем сборки, производственных систем, систем анализа и прочих, требуется немало «внимания и терпения».

Для разработчиков проблема усугубилась, когда они поняли всю строгость требований к консоли со стороны клиентов. Например, если производительность консоли изменялась на 1−2% от сборки к сборке, то срабатывали сигналы тревоги в группе Windows Build, что приводило… гм… к «быстрой и прямой обратной связи», то есть требованию немедленного исправления.

Итак, когда мы будем обсуждать улучшения консоли и новые функции, помните, что есть несколько незыблемых принципов, которым должно соответствовать каждое изменение, в том числе:

1. НЕ допускать новых уязвимостей
2. НЕ ломать инструменты, скрипты, команды и т. д. у существующих клиентов (внутренних или внешних)
3. НЕ снижать производительность и не увеличивать потребление памяти/IO (без чётких и хорошо доведённых причин)

За последние три года команда Windows Console провела следующую работу:

• Капитальный ремонт внутренних компонентов
  • Значительное упрощение и уменьшение кодовой базы
  • Замена нескольких внутренних коллекций, списков, стеков и т.д. контейнерами STL
  • Разбиение на модули и изоляция логических и функциональных единиц кода, что позволяет улучшать функции (а иногда и заменять их), не «ломая мир»
• Объединение нескольких ранее отдельных и несовместимых консольных движков в один
• МНОЖЕСТВО улучшений безопасности и надёжности
• Возможность парсинга и вывода последовательностей ANSI/VT, что позволяет консоли точно отображать насыщенный текстовый вывод из *NIX и других современных инструментов командной строки и приложений
• Поддержка 24-битного цвета вместо прежних 16 цветов!
• Улучшенная безбарьерность: Narrator и другие приложения безбарьерной среды работают в окне консоли
• Добавлена/улучшена поддержка мыши и сенсорного ввода

И работа продолжается! В настоящее время мы завершаем реализацию нескольких захватывающих новых функций.

К чему был этот урок истории?

Я надеюсь, вы поняли, что командная строка остаётся ключевым компонентом стратегии, платформы и экосистемы Microsoft.

Хотя для конечных пользователей Microsoft продвигала графический интерфейс, сама компания и её технические клиенты/пользователи/партнёры в значительной степени полагались на командную строку для выполнения множества технических задач.

На самом деле Microsoft буквально не смогла бы создать ни Windows, ни любой другой из своих программных продуктов без быстрой, эффективной, стабильной и безопасной консоли!

На протяжении эпох MS-DOS, Unix, OS/2 и Windows командная строка оставалась, пожалуй, самым важным инструментом в наборе инструментов каждого технического пользователя. Даже многие пользователи, которые никогда не вводили команды в окно, в реальности используют консоль каждый день! Даже сборка кода в Visual Studio (VS) происходит в скрытом окне консоли. При использовании Exchange Server или средств администрирования SQL Server многие из этих команд выполняются с помощью PowerShell в скрытой консоли.

Механика Windows Console

Во время начала разработки Windows NT в 1989 году не было ни графического интерфейса, ни рабочего стола. Была только полноэкранная командная строка, которая визуально напоминала MS-DOS. Когда появилась реализация графического интерфейса Windows, потребовалось создать приложение консоли для GUI — и таким образом родилась Windows Console! Это одно из первых приложений Windows NT с графическим интерфейсом и, безусловно, одно из старейших приложений Windows, которое по-прежнему используется повсеместно!

Кодовой базе консоли Windows в настоящее время (июль 2018 года) почти 30 лет… по сути, больше, чем разработчикам, которые сейчас над ней работают!

Что делает консоль?

Как мы узнали ранее, у терминала относительно простой алгоритм работы:

• Обработать пользовательский ввод
  • Принять входной сигнал от приборов, включая клавиатуру, мышь, тачскрин и др.
  • Перевести ввод в соответствующие символы и/или последовательности ANSI/VT
  • Отправить символы в подключенное приложение/инструмент/оболочку
• Обработать вывод приложения:
  • Принять вывод текста из покдлюченного приложения/инструмента командной строки
  • Обновлять экран по мере необходимости, основываясь на полученных данных от приложения (например, полученный текст, перемещения курсора, изменение цвета текста и т.д.)
• Обработать системные взаимодействия:
  • Запуск по запросу
  • Управление ресурсами
  • Изменение размера/развернуть окно/свернуть окно и т.д.
  • Завершение по запросу или после закрытия канала связи

Но консоль Windows работает немного иначе:

Механика Windows Console

Консоль Windows — обычный исполняемый файл Win32. Изначально он написан на C, но большая часть кода сейчас переносится на C++ по мере того, как разработчики модернизируют и разбивают на модули кодовую базу.

Если вам интересны такие вещи: многие спрашивали, Windows написана на C или C++. Ответ такой: несмотря на объектно-ориентированный дизайн NT, как и большинство ОС, Windows почти полностью написана на C! Почему? Потому что C++ увеличивает потребление памяти и привносит накладные расходы на выполнение кода. Даже сегодня скрытые затраты на выполнение кода C++ могут удивить, но ещё в 1990-х, когда память стоила около $60/МБ (да… $60 за МЕГАБАЙТ!), скрытые затраты на vtables и прочее были значительными. Кроме того, затраты на косвенное обращение к виртуальным методам и разыменование объектов в то время могли привести к очень значительным потерям производительности и масштабированию кода C++. В наше время нужно соблюдать осторожность, но издержки производительности C++ на современных компьютерах вызывают намного меньше беспокойства. Часто это приемлемый компромисс, учитывая безопасность, читабельность и лучшую сопровождаемость кода… именно поэтому мы постепенно переписываем код консоли на современном C++!

Так что внутри консоли Windows?

До Windows 7 инстансы консоли Windows размещались в критически важной подсистеме Client Server Runtime Subsystem (CSRSS)! Но в Windows 7 из соображений безопасности и надёжности консоль переместили из CSRSS в следующие бинарники:

• conhost.exe — пользовательский режим консоли Windows UX и механика командной строки
• condrv.sys — драйвер ядра Windows, обеспечивающий коммуникации между conhost и одной или несколькими оболочками командной строки/инструментами/приложениями

Высокоуровневая схема текущей внутренней архитектуры консоли выглядит следующим образом:

Ядро консоли состоит из следующих компонентов (снизу вверх):

• ConDrv.sys — драйвер режима ядра
  • Обеспечивает высокопроизводительный канал связи между консолью и любыми подключенными приложениями командной строки
  • Переносит туда и обратно сообщения IO Control (IOCTL) между приложениями командной строки и консолью, к которой они «прикреплены»
  • Консольные сообщения IOCTL содержат:
    • Данные, представляющие запросы на выполнение вызовов API для экземпляра консоли
    • Текст, отправляемый из консоли в приложение командной строки
• ConHost.exe — приложение Win32 GUI:
  • ConHost Core — внутренности и механика
    • Сервер API: преобразует сообщения IOCTL, полученные из приложений командной строки, в вызовы API и отправляет текстовые записи из консоли в приложение командной строки
    • API: реализует консольный API Win32 и логику для всех операций, которые консоль может попросить выполнить
    • Буфер ввода: хранит записи событий клавиатуры и мыши, генерируемые пользовательским вводом
    • VT Parser: если включен, анализирует последовательности VT, извлекает их из текста и генерирует эквивалентные вызовы API
    • Буфер вывода: хранит текст, отображаемый на дисплее консоли. По сути, это 2D-массив структур CHAR_INFO, которые содержат символьные данные и атрибуты каждой ячейки (подробнее о буфере ниже)
    • Другое: в схему не включены инфраструктура сохранения/извлечения значений из реестра и/или файлов ярлыков и т.д.
  • Console UX App Services — слой UX и UI
    • Управляет макетом, размером, положением и прочими характеристиками окна консоли на экране
    • Отображает и обрабатывает параметры UI и т.д.
    • Прокачивает очередь сообщений Windows, обрабатывает их и преобразует введённые пользователем данные в записи событий клавиш и мыши, сохраняя их во входном буфере

Windows Console API

Как видно из схемы архитектуры, в отличие от терминалов NIX, консоль отправляет/получает вызовы API и/или данные в виде сообщений IO Control (IOCTL), а не текста! Даже встроенные в текст последовательности ANSI/VT из приложений командной строки (в основном Linux), извлекаются, анализируются и преобразуются в вызовы API!

Это различие раскрывает ключевое фундаментальное философское различие между *NIX и Windows: в *NIX «всё является файлом», а в Windows «всё является объектом»!

У обоих подходов есть преимущества и недостатки, которые мы перечислим, но не будем подробно обсуждать. Просто помните, что это ключевое различие в философии объясняет многие фундаментальные различия Windows и *NIX!

В *NIX всё является файлом

Когда Unix впервые появился в конце 1960-х и начале 1970-х годов, одним из основных принципов стало то, что (где это возможно) всё следует абстрагировать как файловый поток. Одна из ключевых целей заключалась в упрощении кода для доступа к устройствам и периферии: если все устройства представляются в ОС как файлы, то коду легче получить к ним доступ.

Эта философия работает на самом глубоком уровне: можно даже перемещаться и опрашивать большую часть конфигурации ОС и компьютера под *NIX, перемещаясь по псевдо/виртуальным файловым системам, которые показывают то, что кажется «файлами» и папками, но на самом деле представляет собой конфигурацию машины и оборудование.

Например, в Linux можно исследовать свойства процессоров, изучая содержимое псевдофайла /proc/cpuinfo:

Но простота и согласованность этой модели могут дорого стоить: извлечение/анализ конкретной информации в псевдофайлах часто требует специальных инструментов, таких как sed, awk, perl, python и т.д. Эти инструменты используются для написания команд и скриптов парсинга текстового содержимого, поиска определённых шаблонов, полей и значений. Некоторые из скриптов могут быть довольно сложными, часто трудными в обслуживании и хрупкими — если структура, шаблон и/или формат текста изменятся, многие скрипты, вероятно, потребуется обновить.

В Windows всё является объектом

Когда проектировалась Windows NT, «объекты» рассматривались как будущее в разработке программного обеспечения: «объектно-ориентированные» языки программирования появлялись быстрее, чем тараканы: Simula и Smalltalk уже зарекомендовали себя, а C++ набирал популярность. За ними последовали другие объектно-ориентированные языки, в том числе Python, Eiffel, Objective-C, ObjectPascal/Delphi, Java, C# и многие другие.

Результат предсказуем. Созданная в те пьянящие, объектно-ориентированные дни (около 1989 года) Windows NT разработана с философией, что «всё является объектом». На самом деле одной из самых важных частей ядра NT является Менеджер объектов!

Windows NT предоставляет богатый набор Win32 API для получения и/или управления объектами ОС. Разработчики используют Win32 API для сбора и представления информации, похожей на данные из псевдофайлов и инструментов *NIX, только через объекты и структуры. А поскольку парсеры, компиляторы и анализаторы понимают структуру объектов, то многие ошибки кодирования часто проявляются на ранней стадии, что помогает проверить синтаксическую и логическую правильность намерений программиста. Со временем это может привести к уменьшению сбоев, волатильности и лучшему порядку.

Итак, возвращаясь к основной дискуссии о консоли Windows: команда NT решила построить «консоль», отличную от традиционного терминала *NIX в нескольких ключевых областях:

• Console API: вместо того, чтобы полагаться на способность программистов генерировать корректные ANSI/VT-последовательности, которые трудно проверить, консоль Windows управляется через богатые консольные API
• Общие службы: чтобы избежать дублирования служб во всех оболочках командной строки (например, журнал команд, псевдонимы команд), консоль сама предоставляет некоторые из них через Console API

Проблемы с консолью Windows

Хотя консольные API стали очень популярны в инструментах и сервисах командной строки, но ориентированная на API модель имеет определённые недостатки, перечисленные ниже.

Только для Windows

Многие средства командной строки и приложения широко используют Console API.

В чём проблема? Они работают только под Windows.

Таким образом, в сочетании с другими различиями (например, в жизненном цикле и т.д.), приложения командной строки Windows не всегда легко переносятся под *NIX и наоборот.

Из-за этого в экосистеме Windows распространены свои собственные, часто похожие, но обычно отличающиеся средства командной строки и приложения. Это означает, что при использовании Windows пользователям приходится изучать один набор приложений и инструментов командной строки, оболочек, языков сценариев и т.д., а при использовании *NIX — другой набор.

У этой проблемы нет простого решения: консоль Windows и командную строку нельзя просто выбросить и заменить на bash и iTerm2 — существуют сотни миллионов приложений и сценариев, которые зависят от консоли Windows и оболочек Cmd/PowerShell.

Сторонние инструменты, такие как Cygwin, отлично переносят многие основные инструменты GNU и библиотеки совместимости в Windows, но не могут запускать непортированные, неизменённые бинарники Linux. Это очень важно, так как многие пакеты и модули Ruby, Python, Node зависят от бинарных файлов Linux и/или зависят от поведения *NIX.

Эти причины привели к тому, что Microsoft расширила совместимость с Windows, разрешив запуск аутентичных двоичных файлов и средств Linux в подсистеме Windows для Linux (WSL). С помощью WSL пользователи теперь могут загружать и устанавливать один или несколько дистрибутивов Linux бок о бок на одной машине, а также использовать apt/zypper/npm/gem/др. для установки и запуска подавляющего большинства инструментов командной строки Linux вместе с их любимыми приложениями и инструментами Windows.

Тем не менее, у нативной консоли остаётся функциональность, которая отсутствует в сторонних терминалах: в частности, Windows Console предоставляет сервисы command-history и command-alias, чтобы каждой оболочке (в частности) не пришлось повторно реализовать одинаковую функциональность.

Сложности с удалённой работой

Как говорилось в начале статьи, терминалы изначально были отделены от компьютера, к которому подключены. Сегодня эта конструкция сохраняется: большинство современных терминалов и оболочек/приложений/проч. командной строки изолированы в рамках отдельных процессов и/или машин.

На *NIX-платформах парадигма изолированности терминалов и приложений командной строки с простым обменом символами привела к тому, что там легко получить доступ и работать с удалённого компьютера/устройства. Если терминал и приложение командной строки обмениваются потоками символов по какой-то упорядоченной инфруструктуре (TTY, PTY и т.д.), то очень легко работать удалённо.

Но в Windows многие приложения командной строки зависят от вызова API консоли и предполагают выполнение на той же машине, что и сама консоль. Это затрудняет удалённое управление. Как приложению командной строки удалённо обратиться к API на консоли локального компьютера? Хуже того, как удалённое приложение обратится к Console API, если доступ к нему осуществляется через терминал на Mac или Linux?!

Извините, что дразню вас, но более подробно мы вернёмся к этой теме в следующей статье.

Запуск консоли… или нет!

Когда пользователь *NIX хочет запустить инструмент командной строки, то сначала запускает терминал. Тот затем запускает оболочку по умолчанию или может быть настроен для запуска определённого приложения/инструмента. Терминал и приложение командной строки взаимодействуют потоками символов через Pseudo TTY (PTY).

Однако в Windows всё работает иначе: пользователи Windows никогда не запускают консоль (conhost.exe) — они сразу запускают оболочки командной строки и приложения, например, Cmd.exe, PowerShell.exe, wsl.exe и прочее. Windows подключает запущенное приложение к текущей консоли (если оно запущено из командной строки) или к вновь созданному экземпляру консоли.

#SAYWHATNOW?

Да, в Windows пользователи запускают приложение командной строки, а не саму консоль.

Если пользователь запускает приложение командной строки из существующей оболочки командной строки, то Windows обычно присоединяет вновь запущенный .exe к текущей консоли. В противном случае Windows запустит новый экземпляр консоли, к которому будет присоединено только что запущенное приложение.

Немного занудства: многие говорят, что «приложения командной строки запускаются в консоли». Это не так и приводит к большой путанице относительно того, как в реальности работает консоль и приложения командной строки! Приложения командной строки и их консоли запускаются в независимых процессах Win32. Помогите исправить это заблуждение. Всегда говорите, что «средства командной строки/приложения выполняются с подключением к консоли». Спасибо!

Звучит неплохо, правда? На самом деле… нет. Есть некоторые проблемы:

1. Консоль и приложение командной строки взаимодействуют сообщениями IOCTL через драйвер, а не через текстовые потоки
2. Windows указывает, что ConHost.exe — это консольное приложение, подключенное к приложениям командной строки
3. Windows создаёт «каналы» (pipes), по которым взаимодействуют консоль и приложение командной строки

Это существенные ограничения. Что если вы хотите создать альтернативное консольное приложение для Windows? Как отправить события с клавиатуры/мыши и прочие действия пользователя в приложение командной строки, если нельзя получить доступ к каналам, соединяющим консоль с этим приложением?

Увы, ситуация тут не очень хорошая. Есть отличные сторонние консоли и серверные приложения для Windows (например, ConEmu/Cmder, Console2/ConsoleZ, Hyper, Visual Studio Code, OpenSSH и т. д.), но им приходится прибегать к изощрённым трюкам, чтобы работать как обычная консоль!

Например, сторонним консолям приходится запускать приложение командной строки вне экрана, скажем, с координатами (-32000, -32000). Затем отправлять нажатия клавиш на внеэкранную консоль, скрапить с экрана текстовое содержимое внеэкранной консоли — и повторно выводить его в собственном пользовательском интерфейсе!

Какое-то безумие, верно?! Тот факт, что эти приложения вообще работают — лишь доказательство изобретательности и целеустремленности их создателей.

Очевидно, что мы стремимся исправить эту ситуацию. Об этом тоже расскажем в следующих статьях.

Windows Console и VT

Как описано выше, консоль Windows предоставляет богатый API. С помощью Console API приложения и инструменты командной строки пишут текст, изменяют его цвет, перемещают курсор и т.д. И благодаря этим API не нужно было поддерживать последовательности ANSI/VT, которые обеспечивают похожую функциональность на других платформах.

Фактически, до Windows 10 в консоли Windows была реализована только минимальная поддержка последовательностей ANSI/VT:

Всё изменилось в 2014 году, когда Microsoft сформировала новую группу разработки Windows Console. Одним из её главных приоритетов стало реализовать всестороннюю поддержку последовательностей ANSI/VT для визуализации выходных данных приложений *NIX, работающих в подсистеме Windows для Linux (WSL) и на удалённых машинах *NIX.

Группа быстро внедрила в консоль Windows 10 всестороннюю поддержку последовательностей ANSI/VT, что позволило пользователям использовать и наслаждаться огромным набором инструментов и приложений командной строки Windows и Linux.

Команда продолжает улучшать поддержку VT с каждым выпуском ОС и будет благодарна за любые проблемы, которые вы упомянете в нашем трекере на GitHub.

Обработка Юникода

К сожалению, консоль Windows и её API появились до изобретения Юникода!

Консоль Windows хранит текст (который впоследствии выводится на экран) как символы кодировки UCS-2 с двумя байтами на символ. Эта кодировка поддерживает кодирование первых 65536 позиций символов, что известно как плоскость 0 или основная многоязычная плоскость (Basic Multilingual Plane, BMP).

Приложения командной строки выводят текст в консоли с помощью Console API. Обрабатывающие текст интерфейсы, бывают двух видов: функции с суффиксом А обрабатывают однобайтовые/символьные строки, функции с суффиксом W обрабатывают двухбайтовые (wchar)/символьные строки.

Например, функция WriteConsoleOutputCharacter компилируется в WriteConsoleOutputCharacterA() для проектов ASCII или в WriteConsoleOutputCharacterW() для проектов на Юникоде. Код может напрямую вызвать функцию с суффиксом ...A или ...W, если необходима обработка конкретного типа.

Примечание: каждый W API поддерживает UCS-2, потому что это всё, что существовало в момент разделения на A/W, и мы думали, что так будет хорошо. Но многие W API уже обновились для поддержки ещё и UTF-16 на том же канале.

Не все W API понимают UTF-16, но все они знают хотя бы UCS-2.

Кроме того, консоль не поддерживает некоторые новые функции Юникода, включая соединительные символы нулевой ширины (zero width joiner), которые используются для объединения отдельных символов в арабских и индийских письменностях, а также для объединения символов эмодзи в один визуальный глиф.

Как же ввести эмодзи кота-ниндзя или сложные многобайтовые китайские/арабские символы в консоль? К сожалению, никак!

Мало того что консольный API не поддерживает символы Юникод больше двух байт на глиф (эмодзи NinjaCat требует 8 байт!), но внутренний буфер UCS-2 консоли тоже не может хранить дополнительные байты данных. Что ещё хуже, текущий GDI-рендерер консоли не сможет отрисовать глиф, даже если тот поместится в буфер!

Эх… Таковы радости legacy-кода.

Здесь опять я намерен прервать рассказ — вернёмся к этой теме в следующей статье. Оставайтесь с нами!

Итак, на чём мы остановились?

Дорогой читатель, если вы прочитали всё вышенаписанное, спасибо вам, и примите поздравления — теперь вы знаете больше о консоли Windows, чем большинство ваших друзей, и, вероятно, даже больше, чем вы сами хотели узнать! Какая удача!

Мы многое рассмотрели в этой статье:

• Основные строительные блоки консоли Windows:
  • Condrv.sys — коммуникационный драйвер
  • ConHost.ехе — UX консоли и механика:
    • Сервер API — сериализует вызовы API и текстовые данные с помощью сообщений IOCTL, отправляемых в/из драйвера
    • API — функциональность консоли
    • Буферы — буфер ввода, хранящий пользовательский ввод, и буфер вывода, хранящий выходной/отображаемый текст
    • Парсер VT — преобразует последовательности ANSI/VT из текстового потока в вызовы API
    • UX консоли — состояние UI консоли, настройки, функции
    • Другое — технические данные, безопасность и проч.
• Что делает консоль
  • Отправляет пользовательский ввод в подключенное приложение командной строки
  • Получает и отображает выходные данные из подключенного приложения командной строки
• Чем консоль отличается от терминалов *NIX
  • NIX: «Всё представляет собой файл/текстовый поток»
  • Windows: «Все представляет собой объект, доступный через API»
• Проблемы консоли
  • Консольные приложения и приложения командной строки взаимодействуют через запросы вызовов API и текст, сериализованный в Сообщения IOCTL
  • Консольный API могут вызвать только приложения командной строки Windows
    • Сложнее портировать приложения на/из Windows
  • Приложения взаимодействуют с консолью через Windows API
    • Затрудняет удалённое взаимодействие с приложениями и средствами командной строки Windows
  • Зависимость от IOCTL нарушает схему «обмен символами» терминала
    • Затрудняет эксплуатацию инструментов командной строки удалённого с не-Windows машин
  • Запуск приложений командной строки Windows является «необычным»
    • К приложениям командной строки можно присоединить только ConHost.exe
    • Сторонние терминалы вынуждены создавать внеэкранную консоль, отправлять туда символы и скрапить экран
  • Windows исторически не понимает последовательности ANSI/VT
    • В основном исправлено в Windows 10
  • У консоли ограниченная поддержка Юникода и в настоящее время проблемы с хранением и рендерингом UTF-8 и глифов, которые нуждаются в соединительных символах нулевой ширины

В следующих нескольких статьях этой серии мы более подробно разберём консоль и обсудим решение этих проблем… и не только!

Как всегда, следите за обновлениями.