Двенадцатифакторная модель создания CLI-приложений
Современному пользователю сложно представить себе взаимодействие с операционной системой без мышки или пальца на экране. Интерфейс однозначно ассоциируется с чем-то графическим и оконным, основанным на пользовательском опыте миллионов людей за несколько десятилетий. Это очень удобно, однако в разработке софта есть ещё удалённые уголки Вселенной, где для решения сложных комплексных задач просто нет готовых решений с графическими интерфейсами. Тут на помощь приходит старая добрая командная строка (Command Line Interface, CLI). Поводом для перевода и публикации этой статьи стал интерес команды Artezio к повышению удобства, читаемости и возможности поддержки CLI в части разработки. В конце концов это такой же интерфейс как и графический, он тоже должен быть удобным. Мы очень надеемся, что эти знания окажутся полезными для читателей блога.

Интерфейс командной строки (Command line interface, CLI) – это отличный способ создания прикладных приложений. На их разработку требуется значительно меньше времени, чем на веб-приложения, при этом CLI-приложения предоставляют гибкость для решения технических задач ИТ-инженерам. В веб-приложениях вы можете выполнять действия, которые запрограммировал разработчик. А с помощью CLI вы можете с легкостью самостоятельно объединить несколько инструментов для выполнения сложных сценариев и комплексных задач. Для их использования требуются технические знания, но они прекрасно подходят и для задач администратора, опытного пользователя или создания продуктов для разработчиков.
В Heroku разработали методологию под названием «Двенадцатифакторное приложение». Это набор практик, предназначенных для создания легко поддерживаемых веб-приложений. Ниже похожий набор — 12 правил, которые стоит учитывать при разработке CLI-приложений. Следуя этим принципам, вы сможете создавать приложения для командной строки, которые понравятся пользователям.
Мы также сделали CLI-фреймворк под названием oclif, разработанный с учетом этих принципов для создания интерфейсов командной строки в Node.
1. Хорошая справочная информация
Для CLI-приложений очень важно предоставить пользователям хорошую документацию. Намного важнее, чем при разработке веб-приложений, так как вы не можете подсказывать пользователю через интуитивно понятный графический интерфейс.
Хороший интерфейс командной строки умеет сам предоставлять справочную информацию о себе, а также обладает онлайн-документацией или файлом READMI. Это позволяет быстро разобраться прямо из командной строки, в то же время ваши пользователи могут и загуглить какой-то вопрос (кстати, убедитесь, что Google индексирует страницы с документацией).
Man-документация вам, скорее всего, не нужна (если только это не прямое требование ваших пользователей), она редко используется. Начинающие разработчики ничего о ней не знают, и к тому же она не работает под Windows. Оффлайн-поддержка не нужна, у вас уже есть help в CLI. При этом в нашем фреймворке в oclif мы планируем создать man-документацию. В случае фреймворка имеет смысл создать единое описание для всех интерфейсов.
Убедитесь, что все из вариантов ниже отображают справку в интерфейсе командной строки. Вы не знаете, что будет вводить пользователь, поэтому всё это должно показывать справку.
# list all commands $ mycli $ mycli --help $ mycli help $ mycli -h# get help for subcommand $ mycli subcommand --help $ mycli subcommand -h -h,--help
следует зарезервировать только в качестве флага для получения справки. Когда речь идет о subcommand help, вы не можете гарантировать, что help не является аргументом, который надо передать подкоманде. Лучше договориться об общем правиле и всегда показывать справку или ошибку с недопустимым аргументом. Есть приложение Heroku под названием “help”, которое не раз вызывало у меня эту проблему.
Автодополнение для Shell – еще один хороший способ помочь пользователям.
Что касается самой справки, покажите описание команды, аргументов, всех флагов и, самое важное, предоставьте примеры типичного применения CLI, даже если оно очевидно для вас. Это самая распространённая часть документации, на которую ссылаются пользователи.

Конечно же, создавая интерфейс командной строки с oclif, вы всё это получаете бесплатно: онлайн-документация, документация в CLI и автодополнение. Мы даже работаем над средством контроля качества кода, чтобы помочь вам везде применять описания.

2. Лучше использовать флаги, чем аргументы
CLI принимает два типа входных данных shell: флаги и аргументы. При использовании флагов строчка ввода будет чуть длиннее, но они делают CLI более понятным. Например, в Heroku CLI мы часто работали с командой heroku fork. Она копировала из исходного приложения в целевое. Изначально использовался следующий флаг и аргумент:
$ heroku fork FROMAPP --app TOAPP
При этом было сложно понять, что было исходным, а что ― целевым приложением. Мы стали использовать флаги для обоих случаев:
$ heroku fork --from FROMAPP --to TOAPP
Так стало понятнее, что есть исходное, а что ― целевое приложение.
Обратите внимание, что мы удалили эту команду из Heroku CLI, но это хороший пример того, как аргументы могут сбивать с толку.
Иногда аргументы вполне можно использовать, когда они очевидны, например, $ rm file_to_remove. Есть хорошее правило: один тип аргумента – это хорошо, два типа – сомнительно, а три – бесполезно.
Для аргументов переменной длины можно применять несколько аргументов (например, $ rm field file2 file3). Но когда они разных типов, это сбивает пользователя с толку.
Для флагов гораздо проще написать логику автодополнения, так как вы точно знаете, каким должно быть значение.
В CLI, которые передают флаги любому другому процессу (например, heroku run), парсер флагов должен принимать — аргумент для обозначения того, что он должен прекратить парсинг и передать все в качестве аргумента. Это позволяет запустить команду heroku run -a myapp — myscript.sh -a arg1 (это демонстрирует, как –a может быть флагом для heroku run, а другая –a передается в динамические контейнеры).
3. Какую версию я использую?
Убедитесь, что вы можете узнать версию CLI при помощи:
$ mycli version # multi only $ mycli --version $ mycli –V
Если только это не однокомандный CLI, у которого тоже есть флаг -v,—verbose, команда $ mycli –v аналогично должна отображать версию CLI. Запускать три разные команды, чтобы узнать версию CLI, затруднительно до тех пор, пока вы не найдёте нужную.
Команда версии – это основное место, где вы будете запрашивать у пользователей отладочную информацию, поэтому здесь хорошо размещать любой полезный материал, помимо номера версии, который может помочь вам определить проблемы.
Я также предлагаю отправлять строку версии как User-Agent, чтобы вы могли исправить ошибки на стороне сервера (предположим, ваш CLI использует какой-либо API).

4. Следите за потоками
Потоки stdout и stderr позволяют выводить сообщения пользователю, а также перенаправлять их содержимое в файл. Например:
$ myapp > foo.txt Warning: something went wrong
Поскольку этот Warning находится в stderr, он не попадает в файл. Направляя Warningи в stdout, вы не только скроете их от пользователя, но и создадите проблемы для структурированных данных, таких, как JSON или бинарные файлы. Используйте stderr для ошибок и предупреждений, которые по умолчанию всегда будут отображаться на экране, даже если stdout будет перенаправлен.
Хотя не все в stderr является ошибкой. Например, вы можете использовать команду curl для загрузки файла, и вывод её прогресса будет находиться в stderr. Это позволяет вам перенаправить stdout, но при этом видеть прогресс.
Итак, stdout необходим для вывода, stderr – для сообщений.
Если вы запускаете подкоманду в CLI, убедитесь, что вы всегда передаете stderr этой подкоманды пользователю. В таком случае все ошибки всегда будут выводиться на экран пользователя.
5. Отслеживайте проблемы и нестандартные ситуации
В CLI проблемы возникают гораздо чаще, чем в веб-приложениях. Не имея UI для помощи пользователю, единственное, что мы можем сделать – показать ошибку. Это логичное поведение и неотъемлемая часть использования любого CLI.
Прежде всего, ваши ошибки должны быть информативными. Идеальное сообщение об ошибке должно содержать следующее:
- код ошибки,
- название ошибки,
- описание ошибки (опционально),
- способы её исправления,
- URL для получения дополнительной информации.
Например, если наш CLI выдал ошибку о проблеме с правами доступа к файлу, можно отобразить следующее сообщение:
$ myapp dump -o myfile.out Error: EPERM - Invalid permissions on myfile.out Cannot write to myfile.out, file does not have write permissions. Fix with: chmod +w myfile.out
Только подумайте, если бы каждый интерфейс командной строки был таким полезным, как здорово было бы быть программистом.
Всегда есть возможность возникновения необрабатываемых ошибок, ситуации, когда вы не предполагали, что пользователь может с этим столкнуться. Для этого позаботьтесь о возможности просмотреть полную информацию трассировки и отладочную информацию с переменными окружения.
В oclif мы используем отладочный модуль, который позволяет нам выводить операторы отладки, сгруппированные по компонентам, если установлена переменная окружения DEBUG. Мы ведем очень подробное логирование при включенной отладке, это невероятно полезно при исправлении ошибок.
Логи ошибок также могут быть полезными для анализа и исправления ошибок, но убедитесь, что в них имеются временные метки. Рекомендуем периодически очищать их, чтобы они не занимали место на диске, и убедитесь в отсутствии цветовой кодировки ANSI.
6. Выделяйся!
Современным CLI не стоит стесняться быть яркими. Используйте цвета/подсветку для выделения важной информации. Спиннеры, прогресс-бары, счётчики и индикаторы выполнения для отображения длительных задач отлично подойдут, чтобы проинформировать пользователя о ведущейся работе. Применяйте нотификации операционной системы, чтобы показать выполнение длительной задачи.
В то же время у вас должна быть возможность вернуться к классическим схемам отображения информации и понимание, когда стоит это сделать. Например, если stdout пользователя не подключен к TTY (обычно это означает, что он передается в файл), то не отображайте цвета в stdout (аналогично stderr).
Счетчики и индикаторы выполнения также не являются хорошей идеей, если это не TTY. Они отрисовываются из элементов кодировки ANSI, и, конечно, это работает только на экране. В файле они вам совершенно точно не пригодятся.
У пользователя могут быть причины, по которым он не хочет видеть вывод, сияющий как новогодняя ёлка. Учитывайте это, если установлен TERM=dumb, NO COLOR, или, если указано —no-color. Я бы также предложил добавить переменную окружения MYAPP_NOCOLOR=1 для конкретного приложения на случай, если они захотят отключить цвет только в вашем CLI.
7. Предоставьте интерфейс с диалогом, если это возможно
Для принятия входных параметров, если stdin является TTY, предоставьте возможность передать параметры в диалоговом интерфейсе с подсказками, а не заставляйте пользователя обязательно указывать флаг. При этом никогда не делайте диалоги обязательными. Пользователь должен иметь возможность автоматизировать ваш CLI в скрипте.
Ещё одно отличное место для добавления диалогов с подсказками – это подтверждение опасных действий. Например, если вы хотите удалить приложение Heroku, вам придётся снова ввести его имя для подтверждения:
Флажки и радиокнопки — отличный способ улучшить взаимодействие с CLI, когда вы хотите визуально представить параметры пользователю:
8. Используйте таблицы
Обратите внимание, что команда cli.table() из cli-ux@5 позволяет легко создавать таблицы, следуя этим правилам.
Таблицы – распространённый способ вывода данных в CLI. Важно, чтобы каждая строка вывода представляла собой одну «запись» данных. Никогда не выводите границы таблицы. Это неудобно и сложно для парсинга. Ниже пример того, что не стоит делать:

Если каждая строка соответствует одной записи, вы можете использовать команду wc для подсчёта строк или grep для фильтрации каждой строки:

Помните о ширине экрана. Отображайте лишь несколько основных столбцов по умолчанию, но разрешите пользователю передавать команду —columns со списком имён столбцов, указанных через запятую, чтобы добавить и другие данные.
Обрезайте строки, которые будут выходить за пределы текущей ширины экрана, если не задан параметр —no-truncate.
Показывайте заголовки столбцов по умолчанию, но разрешайте их скрывать, используя —no-headers.
Дайте возможность пользователям задавать команду —filter для фильтрации определённых столбцов (обычно это может выполнить grep, но флаг может фильтровать определённые значения ячеек).
Разрешите сортировку по столбцам с помощью —sort. Разрешите обратную сортировку, а также сортировку по множеству колонок.
Разрешите выводить файлы в формате csv или JSON. Отображение необработанных данных в виде JSON – это отличный способ вывода структурированных данных. Ими можно управлять с помощью jq. Хоть jq очень полезен, cut и awk – более простые инструменты, которые лучше работают с данными в csv.
9. Будьте быстрыми
CLI нужно быстро запускаться. Используйте $ time mycli для проверки CLI. Ниже примерный гайд:
Очевидно, если ваш CLI выполняет такую важную задачу, как загрузка большого файла или что-либо ограниченное возможностью процессора, выполнение не будет быстрым. В этом случае покажите прогресс-бар выполнения программы или хотя бы спиннер. Просто наличие спиннера создаст впечатление, что CLI быстрее, чем есть на самом деле.
oclif разработан с минимальным потреблением ресурсов. Прямо сейчас на моем компьютере оно составляет около 150 мс, что достаточно хорошо. Для этого не нужно иметь все файлы js в CLI, только команду, которая должна быть запущена. Таким образом, даже если у вас есть сотни команд, ресурсопотребление всё равно будут составлять 150 мс.
10. Стимулируйте доработки и дополнения со стороны пользователей
Сделайте ваш код открытым. Это позволяет пользователям изучать его и самостоятельно находить проблемы. Хорошая идея для сообщества – предлагать образец кода, если это может быть полезно другим. Это положительно скажется на имидже организаций.
Убедитесь также, что вы выбрали лицензию. GitHub и GitLab – это отличное место, где можно разместить ваш CLI, а READMI дает вам отличную возможность для обзора вашего CLI.
Напишите, как запустить CLI локально и выполнить наборы тестов. Предложите документ с рекомендациями по внесению дополнений, чтобы сообщить участникам, что вы ожидаете с точки зрения синтаксиса коммитов, качества кода, тестов и всего остального, что им важно знать.
Добавьте кодекс поведения, даже если вам кажется, что в этом нет необходимости. Для некоторых людей это имеет значение, и они чувствуют себя гораздо лучше, видя, что такой документ существует. Некоторые, возможно, даже не заметят его, но это будет полезно в случае, если кто-то ведёт себя грубо, а у вас будет документ с разъяснениями.
В oclif имеется система плагинов, которая предлагает отличный способ для дополнения вашего CLI. Эти плагины могут быть в дальнейшем включены в основной плагин для предоставления функционала всем пользователям.
11. Предоставьте чёткую информацию о подкомандах
Существуют два типа CLI: однокомандный и многокомандный. Однокомандный CLI – это базовый CLI вида UNIX, такой, как cp или grep. Многокомандный больше похож на git или npm, принимающий подкоманду в качестве первого аргумента.
Если CLI простой и выполняет только одну базовую задачу, он хорошо подходит для однокомандного CLI. Однако для большинства CLI лучше использовать подкоманды.
В любом случае, если пользователь не передает никаких аргументов в CLI, всегда лучше в ответ перечислить подкоманды (для многокомандного) или отобразить справку (для одногокомандного), а не выполнять какие-либо действия по умолчанию. Обычно пользователь делает это перед тем, как сделать что-либо еще.
Если вы начинаете использовать подкоманды, через какое-то время они превращаются в целые полезные подразделы (мы называем их topics (темами) в oclif). Git обычно отделяет тему от подкоманды пробелами:
$ git submodule add git@github.com:oclif/command
В то же время мы используем двоеточие в Heroku CLI:
$ heroku domains:add www.myapp.com
Двоеточие предпочтительнее, чтобы разграничить команду от аргументов, переданных команде. Пользователь быстро узнает, что аргумент 1 – это команда, и как получить о ней справку.
Проще говоря, есть и другая техническая причина, почему мы предпочитаем двоеточие. Для команд уровня тем, таких, как $ heroku domains, мы перечисляем все домены приложения. Если бы мы использовали пробелы для отделения команд от подкоманд и хотели бы, чтобы эта команда уровня темы принимала аргумент, то парсер не смог бы определить, является ли аргумент подкомандой или аргументом команды темы. Таким образом, использование пробелов для разделения приводит к тому, что вы не можете иметь команды уровня темы, которые также принимают аргумент.
12. Следуйте спецификации XDG
Спецификация XDG – это отличный стандарт, который стоит использовать, чтобы узнать, где размещать файлы. Если переменные окружения, такие, как XDG_CONFIG_HOME не говорят об обратном, используйте ~/.config/myapp для файлов конфигурации и ~/.local/share/myapp для файлов данных.
Для файлов кэша используйте ~/.cache/myapp для UNIX, но на MacOS лучше использовать по умолчанию ~/Library/Caches/myapp. На Windows можно применять %LOCALAPPDATA%\myapp.
Вместо вывода мы хотели бы вам предложить высказать свое мнение о применении описанных подходов. Насколько актуальным остается для вас и вашей компании поиск новых решений и инструментов программирования? Также мы хотим напомнить, что в Artezio открыто много вакансий для начинающих и опытных разработчиков, которым было бы интересно поучаствовать в интересных проектах и расширить свой кругозор благодаря новым знаниям и практикам. Полный список актуальный вакансий можно найти здесь.
- Блог компании ГК ЛАНИТ
- Программирование
Интерфейс командной строки — Основы командной строки
Представьте, что вы изучаете новую для себя программу. Вы запускаете ее, читаете названия пунктов меню, нажимаете на разные кнопки и получаете какой-нибудь результат. В этот момент вы взаимодействуете с графическим интерфейсом — так же его называют GUI или Graphical User Interface.
Но GUI — это не единственный существующий интерфейс. В этом уроке мы изучим интерфейс командной строки (CLI или Command Line Interface). Такой интерфейс может показаться непривычным, ведь в нем нет ничего, кроме названия программы.
Аргументы и опции
Чем чаще вы будете использовать командную строку, тем больше различных программ вам встретится. Многие из них станут повседневными инструментами. Например, вы часто будете пользоваться программой ls , которая выводит на экран список файлов и директорий.
Здесь все просто. Достаточно набрать название программы и нажать Enter :
ls Desktop Documents Downloads Library Movies Music Pictures Public
Еще мы можем посмотреть скрытые файлы и директории. В *nix-системах они начинаются с точки: .profile .
Тогда необходимо набрать ls -a :
ls -a . .CFUserTextEncoding Desktop Downloads Movies Pictures .. .localized Documents Library Music Public
А если захотим посмотреть содержимое каталога Public? Тогда мы воспользуемся командой ls с аргументом:
ls Public Drop Box
Некоторые программы сложно конфигурируются, поэтому их бывает трудно использовать. Посмотрим на такой неочевидный пример:
-i input.mp4 -vcodec libx264 -crf 30 output.mp4
В этом уроке нам пока не нужно детально разбираться во всех подробностях таких сложных примеров. Главное — увидеть закономерности в использовании консольных программ.
Хорошая новость в том, что закономерности есть. Плохая новость — не все четко следуют им.
Практически любую команду можно дополнить двумя способами:
Способ 1 — это аргументы. Для примера рассмотрим команду ls Music , которая содержит аргумент Music
Способ 2 — это опции, еще их иногда называют флагами. Например, команда ls -a содержит в себе опцию -a
Опции
Поговорим подробнее об опциях. Они всегда начинаются с одного или двух дефисов. Одна из часто используемых опций для просмотра списка файлов — -l . Она выводит дополнительную информацию по каждому файлу:
ls -l total 0 drwx------+ 3 Guest _guest 96 Nov 21 2017 Desktop drwx------+ 3 Guest _guest 96 Nov 21 2017 Documents drwx------+ 3 Guest _guest 96 Nov 21 2017 Downloads drwx------+ 26 Guest _guest 832 Nov 21 2017 Library drwx------+ 3 Guest _guest 96 Nov 21 2017 Movies drwx------+ 3 Guest _guest 96 Nov 21 2017 Music drwx------+ 3 Guest _guest 96 Nov 21 2017 Pictures drwxr-xr-x+ 4 Guest _guest 128 Nov 21 2017 Public
Опции можно комбинировать. Представим, что мы хотим увидеть список всех файлов, включая скрытые, причем с подробным описанием. В таком случае нужно набрать команду ls -a -l . Можно объединить эти опции и записать ту же команду вот так:
При работе с опциями не забывайте ставить — . Без него вы получите команду ls la в которой la — это аргумент, а не опция. В таком случае командная оболочка покажет содержимое директории la .
Еще мы можем использовать опции и аргументы одновременно, хотя все зависит от программы. В случае с ls можно использовать одновременно и то, и другое. Чтобы просмотреть полное содержимое директории Music с информацией о каждом файле, можно набрать команду ls -la Music :
ls -la Music total 0 drwx------+ 4 Guest _guest 128 Nov 21 2017 . drwxr-xr-x+ 89 Guest _guest 2848 Aug 24 14:06 .. -rw-r--r-- 1 Guest _guest 0 Nov 21 2017 .localized drwxr-xr-x 9 Guest _guest 288 Aug 26 17:25 iTunes
Как видно из примера выше, опции указываются слева от аргументов. Но иногда бывают ситуации, когда они используются справа, такое чаще встречается в сложных утилитах со вложенными командами. Их мы сейчас не рассматриваем.
Иногда сложно понять подобные записи: -tupa . Не совсем понятно, что это:
- Одна опция tupa
- Четыре опции t , u , p и a , объединенные в одну цепочку
В таких ситуациях нужно смотреть документацию соответствующей программы. Это можно сделать с помощью команды man (сокращение от manual). Достаточно набрать man — и мы попадем в режим чтения документации.
В мануале содержится описание утилиты в целом, формат ее вызова, все возможные опции, примеры вызовов и много другой полезной информации:
Попробуйте прямо сейчас посмотреть мануал программы ls , набрав в терминале man ls . Перемещаться внутри мануала можно так:
- Промотать вперед — f (forward)
- Промотать назад — b (backward)
- Выход из режима просмотра — q (quit)
Еще полезен сайт explainshell . На нем можно вбить любую команду и посмотреть удобное интерактивное описание:
Варианты опций
У большинства утилит есть два варианта одной и той же опции — длинная и короткая версия. Например, в PHP есть -v и —version :
-v PHP 7.2.7 (cli) (built: Jun 22 2018 06:27:50) ( NTS ) Copyright (c) 1997-2018 The PHP Group Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies php --version PHP 7.2.7 (cli) (built: Jun 22 2018 06:27:50) ( NTS ) Copyright (c) 1997-2018 The PHP Group Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
Длинные и короткие версии опций используются в разных ситуациях:
- Когда мы работаем в терминале, важно набирать быстро — там удобны короткие опции
- Когда мы пишем скрипт из разных команд, важно писать понятно — лучше использовать длинные опции. Так с первого взгляда очевидно, что означает каждая опция
Надо отметить, что обычно длинные опции предваряются двумя дефисами, но некоторые программы нарушают это правило и используют один, что вносит путаницу.
Опции, которые мы рассматривали выше, не имеют параметров. Но нередко встречаются опции, которые недостаточно просто указать.
Например, в macOS есть встроенная утилита say . Если просто передать ей какой-то текст, то она его произнесет. Можно пойти дальше и записать произнесенный текст в файл.
Чтобы это сделать, надо указать опцию -o и записать путь до файла:
# Вместо -o можно написать --output-file say -o hi.aac 'Hello, World.'
В этом примере путь до файла — это значение опции, обычно оно указывается через пробел от самой опции.
Если значение опции содержит в себе специальные или пробельные символы, то его нужно оборачивать в кавычки, двойные или одинарные:
-o 'hi.aac' 'Hello, World.'
Некоторые программы допускают использование знака = вместо пробела:
# Команда say такое не позволяет, но зато видно принцип say -o=hi.aac 'Hello, World.'
Кроме того, say позволяет указать входной файл, который нужно прочитать. Если он указан, то say проигнорирует передаваемый текст как аргумент:
# Здесь мы указали входной файл, который нужно прочитать — hello_world.txt # Еще здесь указано, каким голосом надо читать и в какой файл записывать прочитанное say -v Alex -o hi -f hello_world.txt
Теперь посмотрим на документацию программы say , а именно в раздел SYNOPSIS. Там мы увидим все доступные возможности:
[-v voice] [-r rate] [-o outfile [audio format options] | -n name:port | -a device] [-f file | string . ]
Такое подробное описание есть практически у любой утилиты. Описания построены по одному и тому же принципу:
- Квадратные скобки [] обозначают необязательность. Например, опция -v необязательна, то же самое касается и любых других опций этой программы
- Вертикальная черта | обозначает операцию «исключающее или». Посмотрите на последний блок [-f file | string . ] . Он означает, что say может либо произносить текст из файла, либо произносить строчку, переданную как аргумент. Сделать оба варианта одновременно не получится
Бывают и другие вариации описания способов вызова: значение по умолчанию, выбор из конкретных элементов, отрицание.
Здесь мы разобрали только самые базовые моменты, с которыми вам предстоит столкнуться. Не стоит переживать, если вы не чувствуете, что все это запомнили. Опции требуют практики и опыта, а не заучивания теории. Теперь вы понимаете общие принципы и можете смотреть документацию, далее дело за экспериментами.
Дополнительные материалы
- Построение приложений командной строки (CLI)
- Справочник по командной оболочке
![]()
Остались вопросы? Задайте их в разделе «Обсуждение»
Вам ответят команда поддержки Хекслета или другие студенты
Интерфейс командной строки
Современный пользователь почти всегда работает с графическим интерфейсом (GUI — graphical user interface), в котором взаимодействие между человеком и компьютером происходит в основном с помощью кликов мышью по графическим объектам: кнопкам, пунктам меню, текстовым полям и др. Однако так было не всегда.
Первые интерфейсы были текстовыми, команды отдавались словами, которые писались в так называемой командной строке. Такой текстовый способ взаимодействия между человеком и компьютером называется интерфейсом командной строки (CLI — command line interface).
CLI – устаревшая технология с точки зрения рядового пользователя. Однако в ряде профессиональных IT-областей CLI остается востребованным и более удобным, чем GUI. Например, на серверах, в том числе веб-серверах. Так разработчик может развернуть программный сервер на удаленном компьютере и загрузить туда файлы сайта.
В операционных системах, особенно в GNU/Linux, графические интерфейсы разнообразны. Однако все они ориентированы на неподготовленного пользователя, чтобы он мог сам быстро разобраться, как пользоваться системой. Любой приличный GUI должен быть интуитивно понятным.

С командной строкой все не так. Здесь надо знать команды, уметь ими пользоваться, иметь представление об особенностях работы ОС. Однако CLI дает больше возможностей для управления, чем любой GUI. Это и понятно, написать программу без GUI проще. Разработка к ней графического интерфейса – отдельная история. Поэтому через CLI обычно доступно больше системных программ.
Интерфейс командной строки – это абстрактное понятие. Так же как графический интерфейс пользователя. Не существует конкретных программных продуктов под названием CLI или GUI. Однако есть различные реализации как одного, так и другого. В Linux наиболее популярными GUI на сегодняшний день можно назвать различные оболочки для Gnome, а также KDE. У Windows свой GUI, который претерпевает изменения от версии к версии.
Что касается интерфейса командной строки, то в операционных системах на базе ядра Linux в большинстве случаев его обеспечивает программа Bash, которую относят к группе так называемых командных оболочек.
Bash запускается в текстовом режиме или его эмуляторе – специальной программе, открывающейся в графическом режиме, но которая представляет собой текстовое окно. В последних версиях GNU/Linux такая программа-эмулятор обычно называется «Терминал».
Однако кроме этого во многих дистрибутивах Linux можно перейти из графического в текстовый режим работы, нажав Ctrl + Alt + F2 (вместо F2 может быть от F3 до F6). Обычно Ctrl + Alt + F7 возвращает обратно в графический режим.
В текстовом режиме полностью исчезают элементы графического интерфейса, а также курсор мыши. Отдавать команды операционной системе можно только с помощью клавиатуры. Именно так выглядела работа на компьютере до появления GUI.
В те времена терминалами называли комплекты клавиатура + монитор, удаленные от компьютера. К ЭВМ могло быть подсоединено множество терминалов с помощью модемов или последовательных портов. Таким образом осуществлялся многопользовательский режим доступа к ресурсам вычислительной машины.

Консолью называли клавиатуру + монитор, непосредственно соединенные с компьютером. В ряде областей терминальный доступ к общим ресурсам используется и сегодня.
Итак, отметим основные преимущества интерфейса командной строки:
- Командная строка обеспечивает более быстрый доступ к некоторым возможностям операционной системы, нередко это единственный способ запустить тот или иной процесс.
- Текстовый интерфейс менее требовательный к ресурсам, чем графический.
- Бывает, что графический режим просто не нужен, например, на серверах.
- С помощью командной оболочки легче автоматизировать работу операционной системы и программ, так как она может выполнять заранее подготовленные файлы с последовательностью команд.
Курс с ответами к заданиям и дополнительными уроками в PDF
X Скрыть Наверх
Введение в Linux и Bash. Курс
cli язык программирования
CLI (Command-Line Interface) язык программирования — это специальный язык, который предназначен для взаимодействия пользователя с операционной системой или приложением через командную строку. Он позволяет пользователю выполнять различные команды, управлять файлами и директориями, запускать программы и многое другое.
Одним из преимуществ использования CLI языка программирования является его универсальность и простота. Он основан на командах и аргументах, которые задаются пользователем непосредственно в командной строке, что делает его очень гибким и удобным в использовании. Благодаря этому, CLI язык программирования может быть использован для автоматизации повторяющихся задач, создания сценариев, обработки данных и многого другого.
CLI язык программирования широко используется в сфере системного администрирования и разработки программного обеспечения. Он позволяет разработчикам управлять и настраивать систему, создавать скрипты для автоматизации различных процессов, обеспечивать взаимодействие между приложениями и операционной системой, а также выполнять другие задачи.
Одним из самых популярных CLI языков программирования является Bash, который широко используется в операционных системах на основе Unix (таких как Linux и macOS). Bash обладает богатым набором команд и возможностей, позволяющих автоматизировать задачи и управлять системой через командную строку.
Однако, помимо Bash, существуют и другие CLI языки программирования, такие как PowerShell (используется в операционных системах Windows), Python (который может быть использован как скриптовый язык в командной строке), Ruby и многие другие.
Использование CLI языка программирования имеет множество преимуществ. Во-первых, он позволяет повысить эффективность работы, упростив выполнение повторяющихся задач и автоматизируя рутинные операции. Во-вторых, CLI язык программирования обеспечивает более гибкое взаимодействие с операционной системой и приложениями, чем графический интерфейс. В-третьих, использование CLI языка программирования способствует более глубокому пониманию работы операционной системы и позволяет пользователю полностью контролировать и настраивать систему под свои нужды.
В заключение, CLI язык программирования — это мощный инструмент, который помогает пользователям взаимодействовать с операционной системой и приложениями через командную строку. Он обладает гибкостью, простотой и универсальностью, что делает его особенно полезным в сфере системного администрирования и разработки программного обеспечения. Отличительными особенностями CLI языка программирования являются автоматизация задач, возможность создания сценариев и обработки данных, управление файлами и директориями, а также удобное взаимодействие с операционной системой.