Какой интерпретатор команд использует командная оболочка windows

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

В операционной системе Windows, как и в других операционных системах, интерактивные (набираемые с клавиатуры и сразу же выполняемые) команды выполняются с помощью так называемого командного интерпретатора, иначе называемого командным процессором или оболочкой командной строки (command shell). Командный интерпретатор или оболочка командной строки — это программа, которая, находясь в оперативной памяти, считывает набираемые вами команды и обрабатывает их. В Windows 9x, как и в MS-DOS, командный интерпретатор по умолчанию был представлен исполняемым файлом command.com. Начиная с версии Windows NT, в операционной системе реализован интерпретатор команд Cmd.exe, обладающий гораздо более мощными возможностями.

Запуск оболочки

В Windows NT/2000/XP файл Cmd.exe, как и другие исполняемые файлы, соответствующие внешним командам операционной системы, находятся в каталоге %SystemRoot%SYSTEM32 (значением переменной среды %SystemRoot% является системный каталог Windows, обычно C:Windows или C:WinNT). Для запуска командного интерпретатора (открытия нового сеанса командной строки) можно выбрать пункт Выполнить… (Run) в меню Пуск (Start), ввести имя файла Cmd.exe и нажать кнопку OK. В результате откроется новое окно (см. рис. 2.1), в котором можно запускать команды и видеть результат их работы.

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

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

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

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

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

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

Отображение и изменение атрибутов файлов.
ATTRIB [+R|-R] [+A|-A] [+S|-S] [+H|-H] [[диск:][путь]имя_файла] [/S]
  +   Установка атрибута.
  -   Снятие атрибута.
  R   Атрибут "Только чтение".
  A   Атрибут "Архивный".
  S   Атрибут "Системный".
  H   Атрибут "Скрытый".
  /S  Обработка файлов во всех вложенных папках указанного пути.

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

В этом случае после заполнения очередного экрана вывод помощи будет прерываться до нажатия любой клавиши. Кроме того, используя символы перенаправления вывода > и >>, можно текст, выводимый на экран, направить в текстовый файл для дальнейшего просмотра. Например, для вывода текста справки к команде XCOPY в текстовый файл xcopy.txt, используется следующая команда:

Замечание

Вместо имени файла можно указывать обозначения устройств компьютера. В Windows поддерживаются следующие имена устройств: PRN (принтер), LPT1–LPT3 (соответствующие параллельные порты), AUX (устройство, присоединяемое к последовательному порту 1), COM1–COM3 (соответствующие последовательные порты), CON (терминал: при вводе это клавиатура, при выводе — монитор), NUL (пустое устройство, все операции ввода/вывода для него игнорируются).

Перенаправление ввода/вывода и конвейеризация (композиция) команд

Рассмотрим более подробно поддерживаемые в Windows UNIX-подобные концепции переназначения устройств стандартного ввода/вывода и конвейерного выполнения команд.

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

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

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

Если при этом заданный для вывода файл уже существовал, то он перезаписывается (старое содержимое теряется), если не существовал — создается. Можно также не создавать файл заново, а дописывать информацию, выводимую командой, в конец существующего файла. Для этого команда перенаправления вывода должна быть задана так:

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

Приведем несколько примеров перенаправления ввода/вывода.

1. Вывод встроенной справки для команды COPY в файл copy.txt:
2. Добавление текста справки для команды XCOPY в файл copy.txt:
3. Ввод новой даты из файла date.txt (DATE — это команда для просмотра и изменения системной даты):

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

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

Например, в приведенной ниже команде стандартный выходной поток и стандартный поток ошибок перенаправляются в файл copy.txt:

XCOPY A:1.txt C: > copy.txt 2>&1

Наконец, с помощью конструкции

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

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

которая выводит сообщение на экран. Рассмотрим примеры использования этой команды.

1. Посылка символа прогона на принтер:
2. Удаление всех файлов в текущем каталоге без предупреждения (автоматический положительный ответ на запрос об удалении):
3. Соединение по телефону из командной строки (модем связан с портом COM2):

   ECHO ATDT 1(123)555-1234 > COM2

Команды MORE и SORT

Одной из наиболее часто использующихся команд, для работы с которой применяется перенаправление ввода/вывода и конвейеризация, является MORE. Эта команда считывает стандартный ввод из конвейера или перенаправленного файла и выводит информацию частями, размер каждой из которых не больше размера экрана. Используется MORE обычно для просмотра длинных файлов. Возможны три варианта синтаксиса этой команды:

MORE [диск:][путь]имя_файла
MORE < [диск:][путь]имя_файла
имя_команды | MORE

Параметр [диск:][путь]имя_файла определяет расположение и имя файла с просматриваемыми на экране данными. Параметр имя_команды задает команду, вывод которой отображается на экране (например, DIR или команда TYPE, использующаяся для вывода содержимого текстового файла на экран). Приведем два примера.

Для поэкранного просмотра помощи команды DIR используется команда:

Для поэкранного просмотра текстового файла news.txt возможны следующие варианты команд:

MORE news.txt
MORE < news.txt
TYPE news.txt | MORE

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

SORT [/R] [/+n] [[диск1:][путь1]файл1] [> [диск2:][путь2]файл2]

или

[команда ] | SORT [/R] [/+n] [> [диск2:][путь2]файл2]

В первом случае параметр [диск1:][путь1]файл1 определяет имя файла, который нужно отсортировать. Во втором случае будут отсортированы выходные данные указанной команды. Если параметры файл1 или команда не заданы, то SORT будет считывать данные с устройства стандартного ввода.

Параметр [диск2:][путь2]файл2 задает файл, в который будет направляться сортированный вывод; если этот параметр не задан, то вывод будет направлен на устройство стандартного вывода.

По умолчанию сортировка выполняется в порядке возрастания. Ключ /R позволяет изменить порядок сортировки на обратный (от Z к A и затем от 9 до 0). Например, для поэкранного просмотра отсортированного в обратном порядке файла price.txt, нужно задать следующую команду:

SORT /R < price.txt |MORE

Ключ /+n задает сортировку в файле по символам n-го столбца. Например, /+10 означает, что сортировка должна осуществляться, начиная с 10-й позиции в каждой строке. По умолчанию файл сортируется по первому столбцу.

Интерпретатор командной строки (Command Line Interpreter, или CMD) и PowerShell — это приложения, используемые для прямого взаимодействия с операционной системой Windows. На первый взгляд у них много общего, но в этом тексте мы сконцентрируемся на ключевых отличиях командной строки CMD и PowerShell.

Что из себя представляет командная строка Windows?

Интерпретатор командной строки (более распространенное название — командная строка Windows) — это командная оболочка, которая появилась впервые в MS-DOS 1980-х годов. Она позволяла пользователю взаимодействовать с операционной системой (ОС) напрямую. 

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

Прежде чем проводить сравнение Windows PowerShell и CMD, хорошо бы понять, где их найти и как с ними взаимодействовать.

Существует несколько способов открыть интерфейс командной строки. Классический метод — через поисковую строку, введя в ней слова cmd или командная строка.

Для большинства этот способ быстрее и удобнее, но существует и другая возможность получить доступ к cmd.exe:

1. Комбинацией клавиш win+r открыть меню выполнения.
2. Ввести в открывшееся меню команду cmd.

Также можно вручную открыть cmd.exe из его исходного местоположения: C:Windowssystem32cmd.exe.

Для взаимодействия с ОС в командной строке нужно ввести команду и ее параметр.

Например, чтобы проверить соединение с удаленным хостом вводим:

ping -r google.com

Где ping — команда, -r — параметр команды, google.com — адрес удаленного хоста.

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

Команды должны быть введены в Command Prompt без ошибок. Неправильный синтаксис или написание могут привести к сбою команды или, что еще хуже, к выполнению неправильной команды или правильной команды неправильным способом. Если ввести команду без параметров, вы увидите подсказку с возможными параметрами:

Теперь мы можем перейти к PowerShell.

Что такое PowerShell Windows

PowerShell — это более продвинутая версия CMD. Кросс-платформенное решение для автоматизации задач, состоящее из оболочки командной строки, языка сценариев и структуры управления конфигурацией.

Подробнее о PowerShell читайте здесь → 

Ключевым отличием от CMD, заметным на старте работы, являются командлеты — упрощенные команды, используемые в среде PowerShell. Назначение команды PowerShell довольно легко интерпретировать по названию: они следуют простой закономерности — за глаголом идет существительное.

Сравним:

• Команда CMD: ping
• Командлет PowerShell: Test-Connection

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

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

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

Открыть shell, как и командную строку, можно через поисковую строку и через меню выполнения, вписав в обоих случаях PowerShell. Также, в зависимости от версии операционной системы его можно найти в Power User Menu. Открывается оно комбинацией клавиш win+x или нажатием правой кнопки мыши на значок Windows.

Зачем PowerShell обычному пользователю

Разница PowerShell и CMD заключается в их использовании. Последний используется в основном для выполнения пакетных команд, устранения некоторых первичных неполадок. PowerShell, в свою очередь, может использоваться как для выполнения пакетных команд, так и для административных целей.

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

В качестве примера создадим простой выводящий текст сценарий, который состоит из одной команды:

1. Создаем файл сценария (с расширением ps1), в котором будут прописаны команды:

2. В окне PowerShell вводим & и путь к необходимому файлу:

Теперь давайте разберем, как выполнять простое взаимодействие с системой при помощи CMD и PowerShell.

Как получить помощь?

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

В командной строке Windows используется команда help, чтобы отобразить список доступных команд.

В PowerShell, чтобы выполнить такое же действие используется команда Get-help.

Как изменить каталог?

Для изменения каталога (папки) в командной строке применяется команда Change Directory (cd). Эта команда позволяет перейти в другую папку с компьютера (изменить текущий каталог).

В PowerShell команда cd является псевдонимом для командлета Set-Location-Path <название каталога>, выполняющего идентичную функцию.

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

Для перехода в нужную папку с диска, выполните команду CD «название папки». Вложенные папки должны быть разделены символом бэкслэша: . Например, если необходимо перейти в папку user, находящуюся в C:users нужно ввести команду cd usersuser. Используя команду cd .., можно вернуться на один каталог вверх.

Чтобы изменить диск, нужно ввести его название с двоеточием. Например, d:, чтобы переключиться на диск D. В PowerShell используется командлет set-location d:.

От каталогов перейдем к хранящимся в них файлам.

Как перечислить файлы в каталоге?

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

Отличие PowerShell – в используемой для перечисления файлов команде. Чтобы перечислить файлы в каталоге, используется команда Get-ChildItem.

Как переименовать файл?

Чтобы переименовать файл в каталоге, в cmd используется команда ren (rename). После нее сначала вводится имя файла, которое вы хотите заменить, затем вводится желаемое имя. Например, ren dir1 dir2.

В Windows PowerShell используется команда Rename-Item для переименования папки путем передачи пути к переименовываемой папке и целевого имени. Например, C:Windowsdir1 dir2.

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

Ключевые отличия команд PowerShell от CMD

Завершим знакомство обычного пользователя с PowerShell и CMD сравнением команд и командлетов. Остановимся на нескольких примерах.

• Ping: как мы писали ранее, аналогом cmd-команды ping является командлет Test-Connection в PowerShell.

• Tracert: в PowerShell для определения маршрута следования данных в сети используется Test-NetConnection -TraceRoute.

• IPConfig: Get-NetIPConfiguration в PowerShell – эквивалент IPConfig.

• Nslookup: Команда Resolve-DnsName выполняет DNS-запрос для указанного имени. Эта команда функционально аналогична инструменту nslookup, который позволяет пользователям запрашивать имена.

• Netstat: Get-NetRoute в PowerShell получает текущие TCP-соединения.

• Route: Команда Get-NetRoute является аналогом route и получает информацию о маршруте IP из таблицы маршрутизации IP.

• Netsh: Netsh – служебная программа на базе командной строки, позволяющая показывать или изменять конфигурацию сети активного компьютера. Чтобы запустить ее, и в Windows Powershell, и в CMD используется одна и та же команда — netsh.

• Gpupdate: ее аналогом является команда Invoke-GPUpdate. Она обновляет параметры групповой политики, включая параметры безопасности, установленные на удаленных компьютерах.

• Gpresult: Команда Get-GPResultantSetOfPolicy получает и записывает в файл информацию о результирующих политиках (RSoP) для пользователя.

Разница между командной строкой CMD и Windows PowerShell: что выбрать

Мы завершили обзор, которые условно можно назвать «PowerShell против CMD». Очевидно, есть много причин, по которым Windows PowerShell заменила командную строку Windows по умолчанию в ОС Windows 10. Но, если вы привыкли к CMD, вам не обязательно переходить на PowerShell.

Хотя переход не будет болезненным: в среде PowerShell большинство команд из CMD работают. Все потому, что были созданы псевдонимы командной строки в PowerShell, которые позволяют интерпретировать старые команды cmd как новые команды PowerShell.

Какой инструмент выбрать — ваш выбор. Но PowerShell – более современен. В две основные функции PowerShell встроены дополнительные возможности. И эти возможности, или сценарии использования, являются причиной растущей популярности PowerShell.

Чтобы узнать, как старые команды CMD соотносятся с новыми командами PowerShell, используйте команду Get-Alias.

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»

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

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

1.2.1 Запуск оболочки

В
Windows NT/2000/XP файл Cmd.exe, как и другие
исполняемые файлы, соответствующие
внешним командам ОС, находятся в каталоге
%SystemRoot%SYSTEM32 (значением переменной среды
%SystemRoot% является системный каталог
Windows, обычно C:Windows или C:WinNT). Для запуска
командного интерпретатора (открытия
нового сеанса командной строки) можно
выбрать пункт Выполнить… (Run) в меню
Пуск (Start), ввести имя файла Cmd.exe и нажать
кнопку OK. В результате откроется новое
окно (см. рис.
1),
в котором можно запускать команды и
видеть результат их работы.

Рис.
1 —
Командное окно интерпретатора Cmd.exe в
Windows XP

1.2.2 Настройка параметров
командного окна интерпретатора

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

Рис.
2 – окно
настройки свойств интерпретатора

1.2.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 имеют большое количество
дополнительных параметров и ключей,
запомнить которые зачастую бывает
трудно. Большинство команд снабжено
встроенной справкой, в которой кратко
описываются назначение и синтаксис
данной команды. Получить доступ к такой
справке можно путем ввода команды с
ключом /?.
Например, если выполнить команду ATTRIB
/?,
то в окне MS-DOS мы увидим следующий текст:

Отображение
и изменение атрибутов файлов.

ATTRIB
[+R|-R] [+A|-A] [+S|-S] [+H|-H] [[диск:][путь]имя_файла]
[/S]

+
Установка атрибута.

—
Снятие атрибута.

R
Атрибут «Только чтение».

A
Атрибут «Архивный».

S
Атрибут «Системный».

H
Атрибут «Скрытый».

/S
Обработка файлов во всех вложенных
папках указанного пути.

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

XCOPY
/? | MORE

В
этом случае после заполнения очередного
экрана вывод помощи будет прерываться
до нажатия любой клавиши. Кроме того,
используя символы перенаправления
вывода > и >>, можно текст, выводимый
на экран, направить в текстовый файл
для дальнейшего просмотра. Например,
для вывода текста справки к команде
XCOPY в текстовый файл xcopy.txt, используется
следующая команда:

XCOPY
/? > XCOPY.TXT

Замечание.
Вместо имени файла можно указывать
обозначения устройств компьютера. В
Windows поддерживаются следующие имена
устройств:
PRN
(принтер), CON (терминал: при вводе это
клавиатура, при выводе — монитор), NUL
(пустое устройство, все операции
ввода/вывода для него игнорируются).

Соседние файлы в папке ОС 2013 2к ДО

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

Предисловие от автора, Рича Тёрнера из 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 и глифов, которые нуждаются в соединительных символах нулевой ширины

В следующих нескольких статьях этой серии мы более подробно разберём консоль и обсудим решение этих проблем… и не только!

Как всегда, следите за обновлениями.

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.

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

В
операционной системе Windows, как и в других операционных системах,
интерактивные (набираемые с клавиатуры и сразу же выполняемые) команды
выполняются с помощью так называемого командного интерпретатора, иначе
называемого командным процессором или оболочкой командной строки (command shell). Командный интерпретатор или оболочка командной
строки — это программа,
которая, находясь в оперативной памяти, считывает набираемые вами команды и
обрабатывает их. В Windows 9x,
как и в MS-DOS, командный
интерпретатор по
умолчанию был представлен исполняемым файлом command.com.
Начиная с версии Windows NT,
в операционной системе реализован интерпретатор команд Cmd.exe, обладающий гораздо более
мощными возможностями.

Запуск оболочки

В
Windows файл Cmd.exe, как и другие исполняемые файлы, соответствующие внешним
командам операционной
системы, находятся в каталоге %SystemRoot%SYSTEM32 (значением переменной среды
%SystemRoot% является системный каталог Windows, обычно C:Windows или
C:WinNT). Для запуска командного интерпретатора (открытия нового сеанса
командной строки) можно выбрать пункт Выполнить… (Win +
R) в меню Пуск (Start), ввести имя файла Cmd.exe и нажать кнопку
OK. В результате откроется новое окно (см. рис.
2.1), в котором можно запускать команды и видеть результат их работы.

Рис. 2.1. Командное
окно интерпретатора Cmd.exe в Windows XP

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

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

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

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

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

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

Отображение и изменение атрибутов файлов.

ATTRIB [+R|-R] [+A|-A] [+S|-S] [+H|-H] [[диск:][путь]имя_файла] [/S]

  +   Установка атрибута.

  -   Снятие атрибута.

  R   Атрибут "Только чтение".

  A   Атрибут "Архивный".

  S   Атрибут "Системный".

  H   Атрибут "Скрытый".

  /S  Обработка файлов во всех вложенных папках указанного пути.

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

XCOPY /? | MORE

В
этом случае после заполнения очередного экрана вывод помощи будет прерываться
до нажатия любой клавиши. Кроме того, используя символы перенаправления вывода > и >>,
можно текст, выводимый на экран, направить в текстовый файл для дальнейшего
просмотра. Например, для вывода текста справки к команде XCOPY в
текстовый файл xcopy.txt, используется следующая команда:

XCOPY /? > XCOPY.TXT

Замечание

Вместо
имени файла можно указывать обозначения устройств компьютера. В Windows
поддерживаются следующие имена устройств: PRN (принтер), LPT1–LPT3 (соответствующие
параллельные порты), AUX (устройство,
присоединяемое к последовательному порту 1), COM1–COM3 (соответствующие
последовательные порты), CON (терминал: при вводе это клавиатура, при выводе —
монитор), NUL (пустое
устройство, все операции ввода/вывода для него игнорируются).

Перенаправление
ввода/вывода и конвейеризация (композиция) команд

Рассмотрим
более подробно поддерживаемые в Windows UNIX-подобные концепции переназначения
устройств стандартного ввода/вывода и конвейерного выполнения команд.

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

·                    
выводить сообщения программ не на экран (стандартный выходной
поток), а в файл или на принтер (перенаправление вывода);

·                    
читать входные данные не с клавиатуры (стандартный входной поток),
а из заранее подготовленного файла (перенаправление ввода);

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

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

команда > имя_файла

Если
при этом заданный для вывода файл уже существовал, то он перезаписывается
(старое содержимое теряется), если не существовал — создается. Можно также не
создавать файл заново, а дописывать информацию, выводимую командой, в конец
существующего файла. Для этого команда перенаправления вывода должна быть
задана так:

команда >> имя_файла

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

команда < имя_файла

Приведем несколько примеров перенаправления
ввода/вывода.

1.   Вывод
встроенной справки для команды COPY в файл copy.txt:

COPY /? > copy.txt

2.   Добавление
текста справки для команды XCOPY в файл copy.txt:

XCOPY /? >> copy.txt

3.   Ввод новой
даты из файла date.txt (DATE — это команда для просмотра и изменения системной
даты):

DATE < date.txt

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

команда 2> имя_файла

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

команда > имя_файла 2>&1

Например,
в приведенной ниже команде стандартный выходной поток и стандартный поток
ошибок перенаправляются в файл copy.txt:

XCOPY A:1.txt C: > copy.txt 2>&1

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

Используя
механизмы перенаправления ввода/вывода и конвейеризации, можно из командной
строки посылать информацию на различные устройства и автоматизировать ответы на
запросы, выдаваемые командами или программами, использующими стандартный ввод.
Для решения таких задач подходит команда ECHO [сообщение]  которая выводит сообщение на экран.
Рассмотрим примеры использования этой команды.

1.   Посылка
символа прогона на принтер:

ECHO ^L > PRN

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

ECHO y | DEL *.*

3.   Соединение
по телефону из командной строки (модем связан с портом COM2):

ECHO ATDT 1(123)555-1234 > COM2

Команды MORE и SORT

Одной
из наиболее часто использующихся команд, для работы с которой применяется
перенаправление ввода/вывода и конвейеризация, является MORE.
Эта команда считывает стандартный ввод из конвейера или перенаправленного файла
и выводит информацию частями, размер каждой из которых не больше размера
экрана. Используется MORE обычно
для просмотра длинных файлов. Возможны три варианта синтаксиса этой команды:

MORE [диск:][путь]имя_файла

MORE < [диск:][путь]имя_файла

имя_команды | MORE

Параметр [диск:][путь]имя_файла определяет
расположение и имя файла с просматриваемыми на экране данными. Параметр имя_команды задает
команду, вывод которой отображается на экране (например, DIR или
команда TYPE, использующаяся для вывода
содержимого текстового файла на экран). Приведем два примера.

Для
поэкранного просмотра помощи команды DIR используется
команда:

DIR /? | MORE

Для
поэкранного просмотра текстового файла news.txt возможны следующие варианты
команд:

MORE news.txt

MORE < news.txt

TYPE news.txt | MORE

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

SORT [/R] [/+n] [[диск1:][путь1]файл1] [> [диск2:][путь2]файл2]

или

[команда ] | SORT [/R] [/+n] [> [диск2:][путь2]файл2]

В
первом случае параметр [диск1:][путь1]файл1 определяет
имя файла, который нужно отсортировать. Во втором случае будут отсортированы
выходные данные указанной команды. Если параметры файл1 или
команда не заданы, то SORT будет
считывать данные с устройства стандартного ввода.

Параметр [диск2:][путь2]файл2 задает
файл, в который будет направляться сортированный вывод; если этот параметр не
задан, то вывод будет направлен на устройство стандартного вывода.

По
умолчанию сортировка выполняется в порядке возрастания. Ключ /R позволяет
изменить порядок сортировки на обратный (от Z к A и затем от 9 до 0). Например,
для поэкранного просмотра отсортированного в обратном порядке файла price.txt,
нужно задать следующую команду:

SORT /R < price.txt |MORE

Ключ /+n задает
сортировку в файле по символам n-го столбца. Например, /+10 означает,
что сортировка должна осуществляться, начиная с 10-й позиции в каждой строке.
По умолчанию файл сортируется по первому столбцу.

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

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

Используя
символ амперсанда &, можно
разделить несколько утилит в одной командной строке, при этом они будут
выполняться друг за другом. Например, если набрать команду 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.

Примеры команд для работы с
файловой системой

Рассмотрим
некоторые наиболее часто используемые команды для работы с файловой системой.
Отметим сначала несколько особенностей определения путей к файлам в Windows.

Пути к объектам файловой системы

Напомним,
что файловая система логически имеет древовидную структуру и имена файлов
задаются в формате [диск:][путь]имя_файла, то есть
обязательным параметром является только имя файла. При этом, если путь
начинается с символа «», то маршрут вычисляется от
корневого каталога, иначе — от текущего каталога. Например, имя C:123.txt
задает файл 123.txt в текущем каталоге на диске C:, имя C:123.txt — файл
123.txt в корневом каталоге на диске C:, имя ABC123.txt — файл 123.txt в
подкаталоге ABC текущего каталога.

Существуют
особые обозначения для текущего каталога и родительского каталогов. Текущий
каталог обозначается символом “.” (точка), его родительский каталог — символами
“..” (две точки). Например, если текущим каталогом является C:WINDOWS, то путь
к файлу autoexec.bat в корневом каталоге диска C: может быть записан в виде
..autoexec.bat.

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

Для
того, чтобы использовать длинные имена файлов при работе с командной строкой,
их нужно заключать в двойные кавычки. Например, чтобы запустить файл с именем
‘Мое приложение.exe’ из каталога ‘Мои документы’, нужно в командной строке
набрать «C:Мои документыМое приложение.exe» и нажать
клавишу <Enter>.

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

Команда CD

Текущий
каталог можно изменить с помощью команды

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

Путь
к требуемому каталогу указывается с учетом приведенных выше замечаний.
Например, команда CD  выполняет
переход в корневой каталог текущего диска. Если запустить команду CD без
параметров, то на экран будут выведены имена текущего диска и каталога.

Команда
COPY

Одной
из наиболее часто повторяющихся задач при работе на компьютере является
копирование и перемещение файлов из одного места в другое. Для копирования
одного или нескольких файлов используется команда COPY.

Синтаксис
этой команды:

COPY [/A|/B] источник [/A|/B]  [+ источник [/A|/B] [+ ...]] 

  [результат [/A|/B]] [/V][/Y|/–Y]

Краткое описание параметров и ключей команды COPY приведено
в табл. 2.1.

Приведем
примеры использования команды COPY.

1.   Копирование
файла abc.txt из текущего каталога в каталог D:PROGRAM под тем же именем:

COPY abc.txt D:PROGRAM

2.   Копирование
файла abc.txt из текущего каталога в каталог D:PROGRAM под новым именем
def.txt:

COPY abc.txt D:PROGRAMdef.txt

3.   Копирование
всех файлов с расширением txt с диска A: в каталог ‘Мои документы’ на диске C:

COPY A:*.txt "C:Мои документы"

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

COPY A:*.*

В
качестве источника или результата при копировании можно указывать имена не
только файлов, но и устройств компьютера. Например, для того, чтобы распечатать
файл abc.txt на принтере, можно воспользоваться командой копирования этого
файла на устройство PRN: COPY abc.txt PRN

Другой
интересный пример: создадим новый текстовый файл и запишем в него информацию,
без использования текстового редактора. Для этого достаточно ввести команду COPY
CON my.txt, которая будет копировать то, что вы набираете на клавиатуре, в
файл my.txt (если этот файл существовал, то он перезапишется, иначе —
создастся). Для завершения ввода необходимо ввести символ конца файла, то есть
нажать клавиши <Ctrl>+<Z>.

Команда COPY может
также объединять (склеивать) несколько файлов в один. Для этого необходимо
указать единственный результирующий файл и несколько исходных. Это достигается
путем использования групповых знаков (? и *) или формата файл1 + файл2 + файл3.
Например, для объединения файлов 1.txt и 2.txt в файл 3.txt можно задать
следующую команду:

COPY 1.txt+2.txt 3.txt

Объединение
всех файлов с расширением dat из текущего каталога в один файл all.dat может
быть произведено так:

COPY /B *.dat all.dat

Ключ /B здесь
используется для предотвращения усечения соединяемых файлов, так как при
комбинировании файлов команда COPY по
умолчанию считает файлы текстовыми.

Если
имя целевого файла совпадает с именем одного из копируемых файлов (кроме
первого), то исходное содержимое целевого файла теряется. Если имя целевого
файла опущено, то в его качестве используется первый файл из списка. Например,
команда COPY 1.txt+2.txt добавит
к содержимому файла 1.txt содержимое файла 2.txt. Командой COPY можно
воспользоваться и для присвоения какому-либо файлу текущей даты и времени без
модификации его содержимого. Для этого нужно ввести команду типа

COPY /B 1.txt +,,

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

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

Команда
XCOPY

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

Синтаксис
этой команды:

XCOPY источник [результат] [ключи]

Команда XCOPY имеет
множество ключей, мы коснемся лишь некоторых из них. Ключ /D[:[дата]] позволяет
копировать только файлы, измененные не ранее указанной даты. Если параметр дата
не указан, то копирование будет производиться только если источник новее
результата. Например, команда

XCOPY "C:Мои документы*.*" "D:BACKUPМои документы" /D

скопирует
в каталог ‘D:BACKUPМои документы’ только те файлы из каталога ‘C:Мои
документы’, которые были изменены со времени последнего подобного копирования
или которых вообще не было в ‘D:BACKUPМои документы’.

Ключ /S позволяет
копировать все непустые подкаталоги в каталоге-источнике. С помощью же ключа /E можно
копировать вообще все подкаталоги, включая и пустые.

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

Ключ /I важен для
случая, когда копируются несколько файлов, а файл назначения отсутствует. При
задании этого ключа команда XCOPY считает,
что файл назначения должен быть каталогом. Например, если задать ключ/I в
команде копирования всех файлов с расширением txt из текущего каталога в
несуществующий еще подкаталог TEXT,

XCOPY  *.txt TEXT /I

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

Ключи /Q, /F и /L отвечают
за режим отображения при копировании. При задании ключа /Q имена
файлов при копировании не отображаются, ключа /F —
отображаются полные пути источника и результата. Ключ/L обозначает,
что отображаются только файлы, которые должны быть скопированы (при этом само
копирование не производится).

С
помощью ключа /H можно
копировать скрытые и системные файлы, а с помощью ключа /R — заменять
файлы с атрибутом «Только для чтения». Например, для копирования всех
файлов из корневого каталога диска C: (включая системные и скрытые) в каталог
SYS на диске D:, нужно ввести следующую команду:

XCOPY C:*.* D:SYS /H

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

Используя XCOPY можно при
копировании обновлять только уже существующие файлы (новые файлы при этом не
записываются). Для этого применяется ключ /U. Например, если в каталоге C:2
находились файлы a.txt и b.txt, а в каталоге C:1 — файлы a.txt, b.txt, c.txt и
d.txt, то после выполнения команды

XCOPY C:1 C:2 /U

в
каталоге C:2 по-прежнему останутся лишь два файла a.txt и b.txt, содержимое
которых будет заменено содержимым соответствующих файлов из каталога C:1.Если
с помощью XCOPY копировался
файл с атрибутом «Только для чтения», то по умолчанию у файла-копии
этот атрибут снимется. Для того, чтобы копировать не только данные, но и
полностью атрибуты файла, необходимо использовать ключ /K.

Ключи /Y и /-Y определяют,
нужно ли запрашивать подтверждение перед заменой файлов при копировании. /Y означает,
что такой запрос нужен, /-Y —
не нужен.

Команда
DIR

Еще
одной очень полезной командой является

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

Например,
команда  DIR C:*.bat   выведет
на экран все файлы с расширением bat в корневом каталоге диска C:. Если задать
эту команду без параметров, то выводится метка диска и его серийный номер,
имена (в коротком и длинном вариантах) файлов и подкаталогов, находящихся в текущем
каталоге, а также дата и время их последней модификации. После этого выводится
число файлов в каталоге, общий объем (в байтах), занимаемый файлами, и объем
свободного пространства на диске. Например:

Том в устройстве C имеет метку PHYS1_PART2

 Серийный номер тома: 366D-6107

 Содержимое папки C:aditor

.              <ПАПКА>      25.01.00  17:15 .

..             <ПАПКА>      25.01.00  17:15 ..

TEMPLT02 DAT           227  07.08.98   1:00 templt02.dat

UNINST1  000         1 093  02.03.99   8:36 UNINST1.000

HILITE   DAT         1 082  18.09.98  18:55 hilite.dat

TEMPLT01 DAT            48  07.08.98   1:00 templt01.dat

UNINST0  000        40 960  15.04.98   2:08 UNINST0.000

TTABLE   DAT           357  07.08.98   1:00 ttable.dat

ADITOR   EXE       461 312  01.12.99  23:13 aditor.exe

README   TXT         3 974  25.01.00  17:26 readme.txt

ADITOR   HLP        24 594  08.10.98  23:12 aditor.hlp

ТЕКСТО~1 TXT             0  11.03.01   9:02 Текстовый файл.txt

        11 файлов        533 647 байт

         2 папок     143 261 696 байт свободно

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

Том в устройстве C имеет метку PHYS1_PART2

 Серийный номер тома: 366D-6107

 Содержимое папки C:aditor

[.]                [..]               TEMPLT02.DAT UNINST1.000  HILITE.DAT  

TEMPLT01.DAT UNINST0.000  TTABLE.DAT   ADITOR.EXE   README.TXT  

ADITOR.HLP   ТЕКСТО~1.TXT

        11 файлов        533 647 байт

         2 папок     143 257 600 байт свободно

С
помощью ключа /A[[:]атрибуты] можно
вывести имена только тех каталогов и файлов, которые имеют заданные атрибуты ( R —
«Только чтение», A —
«Архивный», S —
«Системный», H —
«Скрытый», префикс «–» имеет значение НЕ). Если ключ /A используется
более чем с одним значением атрибута, будут выведены имена только тех файлов, у
которых все атрибуты совпадают с заданными. Например, для вывода имен всех
файлов в корневом каталоге диска C:, которые одновременно являются скрытыми и
системными, можно задать команду   DIR
C: /A:HS

а
для вывода всех файлов, кроме скрытых — команду   DIR C: /A:-H

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

DIR C: /A:D

Ключ /O[[:]сортировка] задает
порядок сортировки содержимого каталога при выводе его командой DIR.
Если этот ключ опущен, DIR печатает
имена файлов и каталогов в том порядке, в котором они содержатся в каталоге.
Если ключ /O задан,
а параметр сортировка не указан, то DIR выводит
имена в алфавитном порядке. В параметре сортировка можно использовать следующие
значения: N —
по имени (алфавитная), S —
по размеру (начиная с меньших), E —
по расширению (алфавитная), D —
по дате (начиная с более старых), A —
по дате загрузки (начиная с более старых), G —
начать список с каталогов. Префикс «–» означает обратный порядок.
Если задается более одного значения порядка сортировки, файлы сортируются по
первому критерию, затем по второму и т.д.

Ключ /S означает
вывод списка файлов из заданного каталога и его подкаталогов.

Ключ /B перечисляет
только названия каталогов и имена файлов (в длинном формате) по одному на
строку, включая расширение. При этом выводится только основная информация, без
итоговой. Например:

templt02.dat

UNINST1.000

hilite.dat

templt01.dat

UNINST0.000

ttable.dat

aditor.exe

readme.txt

aditor.hlp

Текстовый файл.txt

Команды MKDIR и RMDIR

Для
создания нового каталога и удаления уже существующего пустого каталога
используются команды MKDIR
[диск:]путь и RMDIR
[диск:]путь [ключи] соответственно (или их короткие
аналоги MD и RD ).
Например:

MKDIR "C:Примеры" 

RMDIR "C:Примеры"

Команда MKDIR не может
быть выполнена, если каталог или файл с заданным именем уже существует. Команда RMDIR не будет
выполнена, если удаляемый каталог не пустой.

Команда
DEL

Удалить
один или несколько файлов можно с помощью команды

DEL [диск:][путь]имя_файла [ключи]

Для
удаления сразу нескольких файлов используются групповые знаки ? и *. Ключ /S позволяет
удалить указанные файлы из всех подкаталогов, ключ /F –
принудительно удалить файлы, доступные только для чтения, ключ /A[[:]атрибуты] – отбирать
файлы для удаления по атрибутам (аналогично ключу /A[[:]атрибуты] в команде DIR ).

Команда
REN

Переименовать
файлы и каталоги можно с помощью команды RENAME ( REN ).
Синтаксис этой команды имеет следующий вид:

REN [диск:][путь][каталог1|файл1] [каталог2|файл2]

Здесь
параметр каталог1|файл1 определяет
название каталога/файла, которое нужно изменить, а каталог2|файл2 задает
новое название каталога/файла. В любом параметре команды REN можно
использовать групповые символы ? и *. При этом представленные шаблонами символы
в параметре файл2 будут
идентичны соответствующим символам в параметре файл1.
Например, чтобы изменить у всех файлов с расширением txt в текущей директории
расширение на doc, нужно ввести такую команду:

REN *.txt *.doc

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

Команда
MOVE

Синтаксис
команды для перемещения одного или более файлов имеет вид:

MOVE [/Y|/–Y] [диск:][путь]имя_файла1[,...] результирующий_файл

Синтаксис
команды для переименования папки имеет вид:

MOVE [/Y|/–Y] [диск:][путь]каталог1 каталог2

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

MOVE "C:Мои документысписок.txt" D:list.txt

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

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

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

C:

CD %TEMP%

DEL /F *.tmp

и
запустить его на выполнение (аналогично исполняемым файлам с расширением com или exe), то мы удалим все файлы во
временной директории Windows. Таким образом, исполнение командного файла приводит к тому же
результату, что и последовательный ввод записанных в нем команд. При этом не
проводится никакой предварительной компиляции или проверки синтаксиса кода;
если встречается строка с ошибочной командой, то она игнорируется. Очевидно,
что если вам приходится часто выполнять одни и те же действия, то использование
командных файлов может сэкономить много времени.

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

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

REM Следующие две команды будут дублироваться на экране …

DIR C:

ECHO OFF

REM А остальные уже не будут

DIR D:

Для
восстановления режима дублирования используется команда ECHO
ON. Кроме этого, можно отключить дублирование любой отдельной строки
в командном файле, написав в начале этой строки символ @,
например:

ECHO ON

REM Команда DIR C: дублируется на экране

DIR C:

REM А команда DIR D: — нет

@DIR D:

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

@ECHO OFF

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

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

ECHO сообщение

Например,

@ECHO OFF

ECHO Привет!

Команда ECHO. (точка
должна следовать непосредственно за словом «ECHO») выводит на экран
пустую строку. Например,

@ECHO OFF

ECHO Привет!

ECHO.

ECHO Пока!

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

Используя
механизм перенаправления ввода/вывода (символы > и >>), можно
направить сообщения, выводимые командой ECHO, в определенный текстовый файл.
Например:

@ECHO OFF

ECHO Привет! > hi.txt

ECHO Пока! >> hi.txt

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

@ECHO OFF

REM Попытка копирования

XCOPY C:PROGRAMS D:PROGRAMS /s

REM Добавление сообщения в файл report.txt в случае

REM удачного завершения копирования

IF NOT ERRORLEVEL 1 ECHO Успешное копирование >> report.txt

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

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

Для
доступа из командного файла к параметрам командной строки применяются символы %0,
%1, …, %9 или %*.
При этом вместо %0 подставляется
имя выполняемого пакетного файла, вместо %1, %2, …, %9 —
значения первых девяти параметров командной строки соответственно, а вместо %* — все
аргументы. Если в командной строке при вызове пакетного файла задано меньше
девяти параметров, то «лишние» переменные из %1–%9 замещаются
пустыми строками. Рассмотрим следующий пример. Пусть имеется командный файл
copier.bat следующего содержания:

@ECHO OFF

CLS

ECHO Файл %0 копирует каталог %1 в %2

XCOPY %1 %2 /S

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

copier.bat C:Programs D:Backup

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

Файл copier.bat копирует каталог C:Programs в D:Backup

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

При
необходимости можно использовать более девяти параметров командной строки. Это
достигается с помощью команды SHIFT, которая изменяет значения
замещаемых параметров с %0 по %9,
копируя каждый параметр в предыдущий, то есть значение %1 копируется
в %0,
значение %2 –
в %1 и т.д. Замещаемому
параметру %9 присваивается
значение параметра, следующего в командной строке за старым значением %9.
Если же такой параметр не задан, то новое значение %9 — пустая
строка.

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

my.bat p1 p2 p3

Тогда %0=my.bat,
%1=p1, %2=p2, %3=p3, параметры %4 –
%9 являются
пустыми строками. После выполнения команды SHIFT значения
замещаемых параметров изменятся следующим образом: %0=p1,
%1=p2, %2=p3, параметры %3 – %9 – пустые
строки.

При
включении расширенной обработки команд SHIFT поддерживает
ключ /n,
задающий начало сдвига параметров с номера n, где n может
быть числом от 0 до 9.

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

SHIFT /2

параметр %2 заменяется
на %3, %3 на %4 и т.д., а параметры %0 и %1 остаются
без изменений.

Команда,
обратная SHIFT (обратный
сдвиг), отсутствует. После выполнения SHIFT уже
нельзя восстановить параметр (%0), который был первым перед
сдвигом. Если в командной строке задано больше десяти параметров, то команду SHIFT можно
использовать несколько раз.

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

%~Fn

%~Dn

%~Pn

%~Nn

%~Xn

%~Sn

%~$PATH:n

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

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

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

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

%~F1=C:TEXTРассказ.doc

%~D1=C:

%~P1=TEXT

%~N1=Рассказ

%~X1=.doc

%~DP1=C:TEXT

%~NX1=Рассказ.doc