Зачем в XXI веке разработчику нужны навыки программирования в «голой» консоли? Да затем же, зачем солдату навыки рукопашного и штыкового боя. Тому, чья служба состоит из покраски травы и стен, не нужны совсем, а вот коммандос этому все еще учат.

А уходя от лукавых аналогий, можно назвать вот такие причины:

  • Удобство в работе. Да, как ни странно, работать с инструментами терминала оказывается не менее, а иногда и более удобно, чем с супер-IDE, создатели которой решили за тебя, что и как ты должен делать в своем проекте. Не веришь? В далеком 2008 году я стал участником нежданного эксперимента. Мы с моим коллегой занимались тогда портированием на Python и C кода, написанного специалистом-«предметником» в Matlab. Мой коллега писал в Eclipse, я — в Notepad++, запуская в консоли интерпретатор Python или make. Для автоматического тестирования мы оба использовали набор контрольных примеров. Квалификация, работоспособность, рвение обоих программистов были сопоставимы, прибавим к этому еще желание обогнать соперника. В итоге ни один из нас не показал превосходства в скорости разработки или качестве кода. IDE — не серебряная пуля, серебряной пули нет.
  • Мобильность при смене проекта или области деятельности. Это я опять сужу по себе. Три года назад я сделал большой проект на Qt под RHEL. Сегодня занимаюсь Embedded, а инструменты все те же: screen, vim, ctags, coreutils, make.
  • Долгосрочные перспективы. Судьба проекта не должна быть связана с судьбой IDE. Где былое доминирование Delphi или Eclipse? Многие в опенсорсе стараются не зависеть от конкретной IDE, особенно проприетарной.
  • Опенсорсные проекты. Впрочем, кажется, я уже это говорил. Включая (на минуточку!) и AOSP — Android Open Source Project. Кто владеет приемами разработки без IDE — берет и работает. Кто не владеет — строчит на форумы «Мужики, помогите, СРОЧНО ОЧЕНЬ НАДО импортировать AOSP в xyzStudio!11».
  • Работа на слабом железе. Современные IDE «как не в себя» кушают память, процессор, требуют для комфортной работы гигантских размеров монитор, а лучше — «дайте два». Это не проблема, пока ты сидишь в уютном офисе в эргономическом кресле за большим и чистым столом. Это проблема, когда ты работаешь в командировке в тьмутаракани, в кабине внедорожника, или в салоне самолета, или в вагоне электрички с 10-дюймовым субноутбуком на коленях.
  • Удаленная работа над проектом. Да, конечно, тут есть альтернативы: TeamViewer, TigerVNC. Со своими, конечно, проблемами.
  • Психологический аспект. Повышает уверенность в своих силах, «а я, оказывается, не просто мышевод-клаводав, я же настоящий хацкер, итить!».
 

Screen (или Tmux)

Первый инструмент, который мы рассмотрим, — screen. Он играет ту же роль, что оконный менеджер в мире GUI: управляет несколькими приложениями, позволяя переключаться с одного на другое. В консольной вселенной такие инструменты называются терминальными мультиплексорами. Пожалуй, из всех оконных менеджеров ближе всего к screen будет легендарный ratpoison, позволяющий обходиться одной лишь клавиатурой, без мыши.

Управляют screen с помощью хоткеев. Но раз приложений несколько, а клавиатура одна, надо «дать понять» системе, к кому именно мы обращаемся: к самому терминальному мультиплексору или к приложению. Поэтому все команды screen предваряются аккордом (клавиатурным сочетанием) Ctrl^a. Наиболее распространенные команды привязаны к горячим клавишам, для менее частых нужно перейти в командную строку screen командой : (то есть нажать Ctrl^a, а затем :).

Пример: запускаем screen, видим баннер с предложением нажать пробел или ввод для продолжения работы. Воспользуемся любезным предложением — баннер исчезает, мы снова в терминале. Открываем в Vim (про него будет дальше) файл main.cpp.

vim main.cpp

Мы редактируем файл main.cpp. Ctrl^a, затем Ctrl^c. Мы опять в терминале, а куда пропал Vim? Ничего никуда не пропало, данная комбинация клавиш открывает новый терминал («окно» в терминологии screen). Для возвращения в предыдущий терминал, где открыт Vim, нажимаем Ctrl^a, затем еще раз Ctrl^a.

Не хотелось бы превращать статью в сборник переводов man’ов, поэтому приведу здесь только самые нужные в повседневной практике команды и аккорды (здесь и далее, говоря о screen, начальный аккорд Ctrl^a я для краткости буду опускать):

  • Ctrl^c — открыть новое окно;
  • Ctrl^a — переключиться в предыдущее окно. Аналогичную функцию в мире GUI выполняет клавиатурная комбинация Alt^Tab. Очень удобна, чтобы переключаться туда-сюда между парой окон, например редактором и командной строкой (впрочем, нормальный консольный редактор позволяет выполнять команды командной строки еще проще);
  • x — заблокировать screen (для разблокировки придется ввести пароль);
  • k — закрыть текущее окно (меня эта команда не раз выручала, когда в текущем окне зависало в томной задумчивости подключение к очередной железке по SSH или Telnet);
  • " — открыть список окон, чтобы переключиться в одно из них;
  • ' — ввести имя окна, в которое хочешь переключиться (про то, как задать имя окна, чуть ниже);
  • ? — вывести справку. В общем, мало чем отличается от горячих клавиш оконного менеджера или IDE;
  • Esc — перейти в режим копирования. Я использовал эту штуку исключительно для пролистывания содержимого окна, чтобы посмотреть, а что там было N строк назад. Выход из режима копирования — по нажатию Esc (без предшествующего Ctrl^a);
  • S — (NB! заглавная буква) разделить экран на две половины (два «региона» в терминологии screen). Текущее окно остается в верхнем регионе, в нижнем изначально ничего нет вообще, но, переключившись в этот регион по Tab, можно назначить ему одно из уже открытых окон или открыть новое;
  • Tab — переключение («по кругу») между регионами;
  • Q — закрыть все регионы, кроме текущего. При этом регионы закрываются, но сами окна остаются, и в них можно переключаться;
  • X — закрыть текущий регион.
Screen c экраном, разделенным на два региона
Screen c экраном, разделенным на два региона

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

Высоту регионов можно регулировать, например нижний урезать до двух строк для ввода, а все остальное отдать для вывода какой-нибудь программы, работающей в режиме мониторинга. Операция эта не настолько частая, чтобы заводить для нее отдельную клавиатурную комбинацию, поэтому для нее используется команда resize, которая вводится в командной строке screen: :resize размер-в-строках.

Можно задать увеличение/уменьшение размера, для этого вводим число со знаком + или -: :resize +10 увеличит размер текущего региона на десять строк, :resize -5 уменьшит размер региона на пять строк.

Если тебе чуть-чуть повезло и у тебя достаточно свежая версия screen, то можно разделить экран по горизонтали клавишей |. На самом деле для современных растянутых по горизонтали мониторов это даже более удобно. Можно комбинировать деление экрана по горизонтали и вертикали, но это, по моему опыту, уже не очень-то нужно.

Screen с экраном, разделенным на три региона
Screen с экраном, разделенным на три региона

Чуть выше я говорил, что окну можно назначить имя. Делается это командой :title имя. У меня сейчас обычно «живут» окна с именами src (тут открыт Vim с исходным кодом), uart (подключение к подопытному девайсу по последовательному порту), adb (подключение к подопытному девайсу по ADB), build (запуск сборки). При переключении по клавише ' полное имя вводить не нужно, достаточно набрать первые буквы (sr, ua, ad, bu).

Ну и чтобы закончить со screen, упомяну про отключение. Screen завершается, когда закрывается последнее из его окон. Кроме того, можно выйти из screen, оставив все окна работающими в фоне, командой :detach (также на эту команду по умолчанию назначена клавиша d). Позднее к этому сеансу screen можно будет подключиться снова. Обычно такая фича полезна при работе с удаленной машиной.

И совсем напоследок: случается, что мантейнеры дистрибутива или пользователь конкретной системы меняют одну или несколько клавиатурных комбинаций по умолчанию (в моем опыте была чехарда с клавишей X при переходе с RHEL6 на Debian). Смотри конфигурационные файлы screenrc и, конечно, кури доки (специально для РКН: я в переносном смысле).

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score! Подробнее

Вариант 2. Открой один материал

Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.


Check Also

Как стартовал Nginx. Игорь Сысоев о разработке знаменитого веб-сервера

12 декабря 2019 года в московском офисе разработчиков Nginx прошел неожиданный обыск, о ко…

8 комментариев

  1. Аватар

    http://android-tools.ru

    05.12.2018 at 18:59

  2. Аватар

    Lex.Mikachev

    05.12.2018 at 20:01

    Очень интересная статья, с примерами и достаточно подробным (дальше только в man’ы) описанием. Пожалуй, теперь пересмотрю свое отношение к IDE. Спасибо! 😃

  3. Аватар

    dilnix

    06.12.2018 at 17:30

    да, консоль и редактор — самый старый и универсальный способ работы… никак не хочу осудить разработчиков IDE, но их использование на самом деле притупляет естественные инстинкты любого программиста =/

  4. Аватар

    nezabudka

    10.12.2018 at 00:23

    С тмуксом никакие переходы на wayland не страшны. Но все таки более практичен тайлинговый оконный менеджер. Например i3. Настраиваешь работу с окнами по типу emacs, тоесть через комбинации с Ctrl, Alt. Работа с приложениями в стиле вим, Многие браузеры поддерживают подобные расширения, читалка evince. Консольный файловый менеджер ranger, позволяет не городить огород с vim прикручивая к нему плагины.Обязательно слепой набор на клаве. И вуаля, лежишь на кровати и работаешь. Пальцы сами делают всю рутинную работу, красота.

  5. Аватар

    VNS65.org

    10.12.2018 at 04:56

    Спасибо, статья очень хорошая!

  6. Аватар

    klug

    14.12.2018 at 14:48

    я бы не был так категоричен в отношении IDE. Для чистого С разницы между IDE, что есть на рынке и консолью (при условии опыта владения), может и нет, но попробовал бы автор писать на JAVA, например, без IDE. И не просто показал бы возможность это делать, а именно продуктивность. Ведь для этого и пишутся IDE. Понятно, что все нормальные исходники это тестовые файлы и их можно редактировать в vi(m). Сам часто этим пользуюсь, когда надо, например, что-то быстро поправить на удалённом сервере.
    Однако я бы предостерёг от столь однобокого подхода — выбирайте инструмены согласно задаче. Для портирования из Матлаба в С Notepad++ это, наверное, оптимальный вариант. Для разработки бэкенда на Яве — я бы консоль не рекомендовал вообще. На рынке много уже хороших, а порой и очень хороших IDE, которые не только ускорят разработку, но еще и упростят дебаг, проследят за стилем, подсчитают покрытие, подскажут варианты оптимизации — в общем не только уменьшат количество ошибок, которые неизбежно будут, но доставят удовольствие от процесса. 🙂

    • Аватар

      s0vaxst3r

      10.01.2019 at 06:20

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

  7. Аватар

    s00mbre

    04.02.2019 at 01:22

    Хорошая статья. Но не могу не согласиться с klug — хорошая IDE предоставляет (или должна предоставлять) столько же возможностей для работы с клавы, как и консоль, при этом, естественно, позволяя работать и мышью. На мой взгляд, самый продуктивный способ работы — это одновременно и эффективно использовать оба средства ввода. Хотя, конечно, всё субъективно. Я знаю людей (да и все таких знают), которые на клаве безошибочно строчат по 10-15 символов / сек, а мышь еле ворочают. А другие — наоборот, кликают с немыслимой скоростью, а на клаве еле стучат, постоянно пялясь на раскладку…

Оставить мнение