Comments 84
Текст сочинен нейросетями ?
У терминала есть фатальный и неискоренимый недостаток - прежде, чем быстро набрать быструю и офигенно эффективную команду, вы должны, для начала, вообще узнать о ее существовании, а потом еще и выучить ее синтаксис. В то время как графические интерфейсы обладают свойством, которым терминал обладать не может в принципе - та самая "интуитивная понятность". И вместо того, чтобы тратить время на изучение команд, человек просто сразу решает конечную задачу.
А если говорить о привлечении к работе всяких ИИ-ассистентов - то для подавляющего большинства применений терминал там опять-таки будет лишним звеном, потому что целевое назначение интерфейса - собственно выполнить задачу, а не преобразовать ее в текстовый вид. Отсюда вечная (как минимум до появления нейроинтерфейсов) ниша терминалов - узкоспециализированная работа в некоторых областях.
Я бы ещё добавил, что эффективная работа в терминале требует навыка слепого набора текста, без которого в терминале работать становится несколько проблематично. Если оператор медленно набирает двумя пальцами, уткнувшись взглядом в клавиатуру, то крайне велика вероятность пропустить опечатку, с последующим разгадыванием квеста: почему же не сработала команда?
Но с другой стороны, когда имеешь навыки, работа ускоряется значительно.
Да и терминальный интерфейс подразумевает компонентную систему и легко автоматизировать работу создавая пакеты команд под наиболее часто встречающиеся последовательности действий, не требующих или мало требующих ввода от оператора.
Этот же вывод сделали и в MicroSoft, когда стали замещать потомка (по функционалу) dos (cmd.exe) мощной программной оболочкой PowerShell.
графические интерфейсы обладают свойством, которым терминал обладать не может в принципе - та самая "интуитивная понятность"
А откуда эта интуитивная понятность берется? У GUI интерактивная природа - перед глазами пользователя знакомые интерактивные элементы, с которыми можно взаимодействовать. Аналогичный опыт будет и с CLI, если вызвать theapp --help и пробежаться глазами по ключам - они типовые, зачастую.
и пробежаться глазами по ключам - они типовые, зачастую.
Зачастую они противоречивые и не логичные. Т.к. не было никого, кто бы координировал разработку утилит командной строки и применял хоть какие-либо стандарты. Совершенно непонятно, почему для отметки схемы в команде pg_dump используется ключ -n, или почему у pg_dump есть ключ -f, а у pg_restore его нет.
Если что, я в командной строке сидел ещё во времена ДВК-3. Но как только перестаёшь постоянно выполнять некие повторяющиеся действия, так из головы постепенно улетучиваются ключи, опции, и даже имена самих команд.
Да даже постоянно повторять одни и те же действия, с риском опечаток, и необходимостью совершать дополнительные действия, может быть утомительно.
Простой пример: мне нужно перейти в некий каталог (какой не помню), и что-то в нём сделать. Для начала придётся десяток раз вызвать ls(dir)/cd. mc или Norton Commander куда как приятнее. Особенно если выучишь хоткеи.
CLI, как и игра на пианино, требует постоянной практики.
Зачастую они противоречивые и не логичные.
Это уже вопрос дизайна. Кнопки запросто могут быть такими же.
почему для отметки схемы в команде pg_dump используется ключ -n
Впрочем, там есть и более очевидный ключ --schema.
почему у pg_dump есть ключ -f, а у pg_restore его нет.
-f filename
--file=filename
Specify output file for generated script, or for the listing when used with -l. Use - for stdout.
Для начала придётся десяток раз вызвать ls(dir)/cd.
Попробуйте тыкать в процессе набора путей, тогда может хватить одной cd. Автокомплит - важная штука в CLI.
Norton Commander куда как приятнее
Хороший пример не самого очевидного GUI, имхо. Много возможностей - много хитрых кнопок и хоткеев, которые таки тоже нужно разучивать.
Если что, я в командной строке сидел ещё во времена ДВК-3. Но как только перестаёшь постоянно выполнять некие повторяющиеся действия, так из головы постепенно улетучиваются ключи, опции, и даже имена самих команд.
Так с гуёвым софтом всё то же самое. Мне почти всегда проще нагуглить, куда, в какое подменю спрятали ту или иную функциональность разработчики экселя или гимпа, чем найти самостоятельно. И если в командной строке у приложения почти всегда есть справка, по которой можно искать, т.е. проблему можно решить быстро не уходя из консоли, то для сложного графического приложения почти всегда надо идти в браузер и гуглить. В последнее время ситуация усугубляется тем, что гуглить уже не всегда получается и приходится ютубить, что просто невероятно неэффективно.
Для начала придётся десяток раз вызвать ls(dir)/cd.
Конечно же, нет. Вы просто набираете cd, а затем, пользуетесь клавишей Tab, получая подсказки по каталогам текущего уровня. Что очень быстро и невероятно удобно. Гораздо быстрее, чем продираться в нужную папку файловым менеджером, каждый раз отыскивая глазами следующую папку в иерархии, чтобы перейти в нее.
Когда я пересел на линух, мне очень не хватало Far-а или TotalCommander-а, я искал замены, а потом я освоил консоль и понял, что не нужны мне все эти файловые менеджеры. С ними работаешь медленнее.
Почти со всеми используемыми мной GUI-программами я научился работать методом тыка, без чтения справок и документаций. С терминальными прогами такое не прокатывает. Вот и всё.
(терминал использую каждый день, если что)
Почти со всеми используемыми мной CLI-программами я научился работать просто читая текст, не ползая по меню, не изучая пиктограмы и расположение кнопок. С оконными прогами такое не прокатывает. Вот и всё.
Вы таки с SAP/R3 не работали. Когда куча полей/ вкладок и фиг его знает что куда вводить надо. :)
Ещё тест: попробуйте в Windows Explorer 5 файлов по макаке переименовать (например Добавить _old перед расширением)
И расскажите об успехах :)
TotalCommander может делать групповое переименование по разным патернам причем он динамически показывает какой будет результат. CLI тут и рядом не стоит.
Это не «чистый” GUI
И если у вас 10k файлов, вам динамический результат -по боку.
А ещё файлы могут быть по разным подпапкам разбросаны. -удачи.
Скопируйте все log файлы из папок разного уровня вложенности с помош GUI
Не чистый, а какой?
Изначальная задача была переименовать 5 файлов по маске. В Total Commander это делается просто без всяких знаний. А как это в CLI сделать?
rename 's/search_pattern/replacement/g' *.jpg
Причем, с ключом -n | --nono покажет ожидаемый результат, аналогично TC.
rename --help
Usage:
rename [ -h|-m|-V ] [ -v ] [ -0 ] [ -n ] [ -f ] [ -d ] [ -u [enc]]
[ -e|-E perlexpr]*|perlexpr [ files ]
Options:
-v, --verbose
Verbose: print names of files successfully renamed.
-0, --null
Use \0 as record separator when reading from STDIN.
-n, --nono
No action: print names of files to be renamed, but don't rename.
-f, --force
Over write: allow existing files to be over-written.
--path, --fullpath
Rename full path: including any directory component. DEFAULT
-d, --filename, --nopath, --nofullpath
Do not rename directory: only rename filename component of path.
-h, --help
Help: print SYNOPSIS and OPTIONS.
-m, --man
Manual: print manual page.
-V, --version
Version: show version number.
-u, --unicode [encoding]
Treat filenames as perl (unicode) strings when running the
user-supplied code.
Decode/encode filenames using encoding, if present.
encoding is optional: if omitted, the next argument should be an
option starting with '-', for instance -e.
-e Expression: code to act on files name.
May be repeated to build up code (like "perl -e"). If no -e, the
first argument is used as code.
-E Statement: code to act on files name, as -e but terminated by
';'.
Против
Total Commander Multi-Rename tool
Разве этот интерфейс можно назвать очевидным?
Хмм, в TC интерфейсе хотя бы потыкав мышкой можно сходу понять что происходит. По вашему же примеру даже в хелпе не написано что там за заклинание сразу после rename стоит. Это какой-то perlexpr? Предполагается идти гуглить, что это такое?
в TC интерфейсе хотя бы потыкав мышкой можно сходу понять
Путь экспериментов - это противоположность "сходу".
Это какой-то perlexpr? Предполагается идти гуглить, что это такое?
Более подробное описание и примеры можно найти в манах (man rename).
Скопируйте все log файлы из папок разного уровня вложенности с помош GUI
Это медленно, но не невозможно.
Тогда как пользоваться терминалом, не зная команд, невозможно.
Обычный спор "брони" и "снаряда".
Оба правы и не правы.
Если резюмировать - Графический интерфейс (ГИ) удобен до определенного предела насыщения элементами, потом уже на правильное управление необходимым ПО уходит значительное время,
в случае консоли наоборот, требуется более высокий (для тех кто входил в работу с ЭВТ в ГИ) уровень усилий, но для тех кто много работает на клавиатуре или пишет - проблемы сильной не предполагается.
Графический интерфейс (ГИ) удобен до определенного предела насыщения элементами, потом уже на правильное управление необходимым ПО уходит значительное время
GUI даже после этого предела может быть просто безальтернативным. Как вы предлагаете в терминале, например, заниматься 3D-моделированием или редактированием видео?)
theapp --help
'theapp' is not recognized as an internal or external command,
operable program or batch file.
:(.
P.S. Но, может быть, надо было Theapp? Или the_app? Или app? Или appcli? Или сначала надо сделать appsetup -vfdx --o 4 --P и только потом theapp?
С gui почти те же сложности что и с cli. Попробуйте в блендере найти инструменты для скульптинга, если вы первый раз блендер видите. То же касается и ide например idea. Там есть gui, но реально быстро все происходит, когда пользуешся short cut-ми.
И вот мы приходим к выводу, что наилучший интерфейс - это совмещение GUI и терминала. То, что можно быстро и удобно сделать мышкой - делается мышкой. То, для чего легче набить пару слов с клавиатуры - делается клавиатурой. И то, и другое должно быть доступно. (Я, например, на дух не переношу окно терминала, но при необходимости залезть в реестр прожимаю Win+R regedit, а не ищу его в настройках панели управления - так удобнее и быстрее).
Это да. Гибридный вариант самый удобный, но его труднее реализовать.
Да, но большая часть тех же CAD-ов и имеют такие интерфейсы, выбрал элемент, тут же фокус переносится в поле ввода, там вводишь параметры данного элемента, дальше ты или наводишь мышью этот элемент или позиционируешь вводом координат.
Тут скорее про комьинацию подходов. А в статье больше про gui vs cli. У меня во время работы в одном КБ был диалог с главбухом.
Мне нужно было мышки для конструкторов купить и вроде это не дорого. Но было сказано, что свободных средств нет, а констркор может работать без мышки.
В то время работали в автокаде, кпжется в 14 еще, и нееоторые специалисты реально все или почти все в консоли набирали.
При чем и в GUI и CLI должен быть легкодоступный поиск нужной команды по тексту.
И вместо того, чтобы тратить время на изучение команд, человек просто сразу решает конечную задачу.
GUI сразу же ломаются при необходимости решать пакетные задачки - переименовать 2000 файлов, создать 200 doc(x) по шаблону, отзеркалить 100 картинок, кинуть на печать 5 файлов. А вот в терминале с этим нет особых проблем (за редким исключением)
Да, кое-где программисты думают о людях и добавляют Multi-Rename, но по факту это точечные, единичные фичи, которые существуют для отдельного функционала
В gui вы сразу видите, во что будет переименовано. Например, в тотал командоре
Например, в тотал командоре
Это как раз и относится к "кое-где". Как там в проводнике с групповыми переименованиями?
Во-вторых, что у тотала с остальными фичам? Например, взять список файлов и разложить по папочкам? Или просто взять список файлов (не по шаблону, а именно список) и скопировать из ./datastore в ./common?
В тотале при архивации есть exclude?Ну, чтобы можно было сжать все (*.*) файлы кроме определенных(-exclude *.zip) Спойлер - можно... в теории. Сравните:
Тотал:
Открыть Select group
Написать регулярку. Если вы с ними не знакомы и не пишите каждый день парсер e-mail'ов, то разбираться будете явно не 15 минут. Особенно с exclude.
Тестировать регулярку
Заселектить все кроме
Сжать
Теперь Tar:
tar --exclude='./.zip' -zcvf /backup/filename.tgz .Предположим что Tar не умел бы в exclude..
$files=Get-ChildItem -Exclude ".zip"
Compress-Archive $files.Name ./files.zip
В GUI реализуются востребованные функции, если бы пакетные действия с файлами были популярны, они были бы доступны в любом интерфейсе.
Для нормальной работы почти всегда проще выбрать GUI, для ускоспециализированных задач и автоматизации идем в CLI (сейчас можно даже не вникать, все топовые LLM хорошо пишут цепочки команд). Что не отменяет возможность существования таких особенных людей с особенными задачами, для которых консоль это единственный возможный вариант.
если бы пакетные действия с файлами были популярны, они были бы доступны в любом интерфейсе.
Для нормальной работы почти всегда проще выбрать GUI
Мне можете не рассказывать, я каждый день вижу как люди открывают файл, меняют в нем пару строк, закрывают -> следующий (и так до 50 файлов). Недавно открыли для себя шаблонизаторы (на базе питоновской жинжи, кстати), но пока еще работают по старинке.
Окей, есть сайт, на который надо загрузить 600 КТ, что будет делать девочка-секретарь? Открыть сайт - выбрать файлы, вбить данные, загрузить....подождать... удалить загруженную папочку - обновить страницу. Сколько у нее уйдет на это времени? Неделя, еще и сделает пару-десяток дублированных загрузок.
Что сделает IT-специалист?
foreach ($file in $file_list){
# создать запись
$result = Invoke-WebRequest -Uri $url -Method 'Post' -Body ($new_record | ConvertTo-Json) -Headers $headers
# загрузить файл
$result = Invoke-WebRequest -uri $url -Method 'Put' -Infile $($basePath+'\'+$file) -Headers $headers -ContentType "application/zip"
}Все, ну переменные определить, да поотлаживать часок. Запустить на ночь.
Зайдите в отдел кадров и удивитесь количеству шаблонов и ручного труда. Знаете почему? потому что в офисе работу с переменными сделали через такую жопу, что пользоваться фичей невозможно. Реально проще через пайтон делать (который вообще ни разу не нативный)
И вместо того, чтобы тратить время на изучение команд...
...человек тратит прорву времени на возюкание мышкой по столу, открытие подменю в многоуровневых меню, жмакание значков, вписывание букв в полях ввода..
Все это бывает увлекательно и просто, когда делается один раз, а вот когда оказывается что все это надо повторить раз так двести..
Помню -требовалось по работе взять несколько сотен файлов одного типа из разноуровневых папок, проигнорировав файлы другого типа, и все их в виде текста вставить в документ Ворда. Одинаковую задачу поставили мне и моему коллеге, довольно хорошему программисту, к слову.
Я справился где-то за пол часа, покопался немного с командой find, вспоминал как там в ней рекурсивно искать по папкам и вызывать echo для найденного. Отыскал с ее помощью все нужные файлы, вывел их в один огромный текстовый файл, и потом вставил его в вордовский док. После чего занялся другими текущими задачами. После обеда. смотрю - а коллега проклиная руководство с его дурацкими заданиями, в проводнике ищет файлы, открывает их по очереди, копирует текст из файла, вставляет его в док.. и так по кругу, даже еще процентов на 10 не продвинулся. Когда я сказал ему не маяться фигней и дал ему свой скриптик, он просто в шоке был, ему и в голову не пришло что можно так просто и быстро все сделать,
Я это к тому, что гуй это, конечно, хорошо, но зачастую он реально заставляет человека заниматься каким-то тупым и монотонным трудом, там где можно задачу поручить компьютеру, для чего он собственно и создан.
Я смотрю, вы, как и несколько предыдущих "защитников" cli, не дочитали мой комментарий до конца, где написано:
вечная (как минимум до появления нейроинтерфейсов) ниша терминалов - узкоспециализированная работа в некоторых областях.
Мне даже стало интересно - это постоянная работа в cli влияет на то, что текст воспринимается не целиком, а построчно? :)
Уже давно многие cli тулы поддерживают автокомплиты. При нажатии tab показываюся возможные команды или динамически подгружаются варианты. Просто настроить нужно. А что крошит гуи безоговорочно, так это возможность в одну команду выполнить любую цепочку типовых действий. Вместо того чтобы протыкивать их в гуях.
графические интерфейсы обладают свойством, которым терминал обладать не может в принципе - та самая "интуитивная понятность"
берём какую-нибудь САПР и пробуем "интуитивно" в ней что-то нарисовать чуть сложнее прямоугольника. Разбираться придётся так же "с пузырём"
Как-то автор перескочил через TUI. UI не обязательно может быть графическим. Он вполне может быть себе текстовым. Тот же небезызвестный Norton Commander тому пример. А уж сколько софта было написано на текстовом фреймворке TurboVision…
Как-то автор перескочил через TUI.
Концептуально это то же самое, что и GUI, только с худшим качеством картинки.
Вообще типов интерфейсов сильно больше, конечно. Основные — командная строка, мышь (или аналог), и как промежуточный вариант — мышь + горячие клавиши. Кто из них будет удобнее и быстрее, зависит еще и от устройства. Например, сомневаюсь, что командная строка будет в общем случае быстрее на устройстве с тачскрином без физической клавиатуры.
А еще всякая экзотика (?) типа сенсоров ускорения и ориентации, указания взглядом (как в некоторых фотоаппаратах высокого класса и, говорят, в некоторых системах военного назначения), перчатки и прочие датчики виртуальной реальности и так далее. Экзотика эта делается, очевидно, не на ровном месте, а там, где решаемые задачи не позволяют использовать более распространенные интерфейсы.
Концептуально это то же самое, что и GUI, только с худшим качеством картинки.
Вот тут готов поспорить. Битовая матрица символа считывалась на отлично даже на древних мониторах размером 25 строк на 80 символов.
В своё время разрабатывал прекрасные TUI для ДВК-3.
Плюсом у буковок можно поменять цвет, если монитор не монохромный, и подрисовать им фон. Таким образом можно выделять хот-кеи и активные пункты меню. И даже рисовать тени у открытых окон, имитируя Z-order.
Скрытый текст
Естественно, всякие рюшечки, в виде буковок различного размера, и всякие пиктограммки не нарисуешь.
Но как по мне, TUI не заслуженно забыт и оставлен в сторонке. Ничто не мешает писать утилиты командной строки таким образом, чтобы они не только получали параметры, опции, команды, но и вполне себе обладали интерфейсом пользователя.
Как, например, htop.
В своё время разрабатывал прекрасные TUI для ДВК-3.
Естественно, всякие рюшечки, в виде буковок различного размера, и всякие пиктограммки не нарисуешь.
Тоже работал на ДВК-3 очень давно. Насколько я помню, там можно было накладывать графический экран на текстовый, совмещая текстовый и графический режимы. Это позволяло создавать текстовые меню типа: "L-линия, R-прямоугольник, C-окружность", ожидать нажатия соответствующей клавиши и отображать результат выполнения на графическом экране
Насколько я помню, там можно было накладывать графический экран на текстовый, совмещая текстовый и графический режимы.
Да, можно. Только для этого нужна была библиотека KeyGP, разрабатывавшаяся в Зеленограде, в том же предприятии, где делали ДВК. Эта библиотека была платная и имела хитроумную привязку к диску, т.е. просто так не скопируешь. Причём эта привязка в первых версиях слетала при дефрагментации диска. Потом этот баг пофиксили.
И что самое удивительное, в этом режиме даже работал скроллинг. Можно было вывести строку в stdout и весь экран вместе с текстом и графикой скроллился вверх. Такого я больше нигде не видел. Либо текстовый режим, либо графический.
Только для этого нужна была библиотека KeyGP, разрабатывавшаяся в Зеленограде, в том же предприятии, где делали ДВК. Эта библиотека была платная и имела хитроумную привязку к диску, т.е. просто так не скопируешь
Точно не предпринимал никаких усилий, чтобы совмещать графический и текстовый режимы. Обнаружил эту возможность случайно, если не ошибаюсь - запустил свою текстовую программу, когда на экране оставалось изображение от какой-то игры (что-то вроде Maze Runner), которая слетела. Тоже тогда удивился наличию такой возможности
Я как раз отношусь к тому типу пользователей, которые через UI с помощью мышки выполнят работу быстрее, чем тратя уйму времени на гугление нужных команд и вставки их в терминал (у меня уже был случай, что скопированная команда удалила из системы все пакеты и мне пришлось переустанавливать linux (в команде не было команд remote или rm и поэтому для это было неожиданно))
*PS мой уровень владения терминалом это гугление команд
Все согласятся, что интерфейс этого будущего невероятен и желанен.
Нет, я не соглашусь. У вас через час работы с таким UI руки отвалятся.
Если все графические интерфейсы убрать, то дураки не смогут пользоваться компьютерами. Хорошо же будет, нет?
P.S. автор, спасибо за забавный подстрочник, конечно, но английский текст русскими словами — это уверенный минус
Хорошо же будет, нет?
Нет. Компьютеры нужны чтобы упрощать работу совершенно разным людям. От того, что вылечить вас, оформить вам документы или посчитать и перевести вам зарплату будет дороже и дольше, ваша жизнь вряд ли улучшится.
Простые пользователи не обязательно дураки. Обычные люди пользовались компьютерами и до изобретения графических интерфейсов. Выучить десяток команд для обычного человека — пара пустяков.
Обычные люди пользовались компьютерами и до изобретения графических интерфейсов
Совершенно не в тех масштабах что сегодня. Графический интерфейс дал возможность пользоваться компьютером тем, кто просто не стал бы пользоваться им без него.
Выучить десяток команд для обычного человека — пара пустяков.
А если их не десяток, а пять десятков? При этом 20 ходовые, 20 нужны раз в месяц, а ещё 20 раз в год? Тогда когда человеку понадобится какая-то из последних 20 команд он будет вынужден лезть в справочник. А графический интерфейс позволяет тут же, рядом с параметром разместить и документацию. Не нужно точно помнить то ли там max_limit, то ли max_threshold, то ли от 1 до 10 принимает значение, то ли от 1 до 50. Достаточно помнить что что-то одно из этих двух, где-то на последней вкладке, и диапазон возможных значений может быть прямо рядом с полем подписан, и даже более подробная всплывающая справка тут же, при наведении курсора на знак "?"
Графический интерфейс дал возможность пользоваться компьютером тем, кто просто не стал бы
Вопрос не про тех кто что-то там стал бы. На работе не спрашивают стали бы вы, или нет. Там выдают компьютер и пишут инструкцию. Если сотрудник не справляется, его заменяет другой, который справляется.
Если сотрудник не справляется, его заменяет другой, который справляется.
Или не заменяет, если тех кто владеет этим навыком на рынке меньше, чем рабочих мест, где этот навык нужен. Да и "справляется" понятие растяжимое, может он просто тратит на эти задачи больше времени, вспоминая редкие команды, или листая справочник, но в целом справляется не хуже среднего.
Выучить десяток команд для обычного человека — пара пустяков.
Зачем? Чтобы что? Ну вот надо было мне гибернацию наладить на своём ноуте под Ubuntu. Для этого надо было реорганизовать swap. Ну справился я с этой задачей в консоли. Гибернация работает. Год работает, два работает… Думаете, я помню утилиты и их команды с ключами, которыми пользовался? Помнится только то, чем пользуешься постоянно. А обычные люди не пользуются шеллом, обычные люди пользуются каким-либо приложением. Так что вся работа в командной строке будет сводиться к запуску приложения.
Выучить десяток команд для обычного человека — пара пустяков.
Непонятно только, зачем. Я вот занимаюсь разработкой и потому выучил консольные команды гита, gcc и прочих инструментов, ведь мне это реально нужно. Однако я, пользуясь Arch-подобным дистрибутивом (Manjaro), до сих пор не знаю упоротых ключей pacman, и знать не хочу, потому что почти всегда я ставлю-удаляю-обновляю пакеты через гуишный менеджер пакетов, а если вдруг возникает надобность сделать это из терминала - есть манжаровский pamac с человеческим синтаксисом вроде pamac install вместо пакмановской однобуквенной наркомании.
Удивительно. Я тоже разработчик и пару раз в жизни использовал консоль гита. При этом по большей части использовал гуи оболочки для него - сначала turtoiseGit, в сейчас - тупо IDE, в котором видно всё - комнаты, все ветки, комменты и прочее и прочее. И все можно сделать, просто тыкнув правой клавишей и выбрав нужную контекстную команду.
При этом я, конечно, пользуюсь и cli - всякие openssl, curl, да и просто работа с серверами обязывает. Но часто, если есть возможность выбора, выбираю gui.
все вопросы которые вы бы хотели решить, уже решены во всяких wezterm, alacritty и kitty.
Главный плюс использования CLI - это возможность автоматизации практически чего угодно. То, что можно сделать с помощью .sh, .bat, make-файлов, не имеет никакой графической альтернативы.
Макросы как альтернатива
То, что можно сделать с помощью .sh, .bat, make-файлов, не имеет никакой графической альтернативы.
Разработчики всяких TUI/GUI обёрток над консольными утилитами с вами не согласны. Вы правы, что главный плюс CLI в возможности автоматизации. Но когда мне нужно обработать 36 серий сериала, я не хватаю vim и не пишу скрипт с нуля. А беру MKVToolNix, мержу первый файл, потом импортирую команду. И уже затем пишут цикл в .sh, .bat, .cmd. Получается значительно быстрее, чем читать справку по командам и ключам.
То есть вы по итогу всё равно пишете скрипт, просто не с нуля, а при помощи вспомогательных утилит.
По итогу я могу скрипт не писать. Я могу использовать только MKVToolNix. Просто лично для меня такой способ наиболее быстрый. Я попросил GUI сделать для меня прототип команды и запихнул его в цикл. Я сэкономил время на написании команды (её даже набирать долго, учитывая длинные названия файлов) и на гуглении ключей. А также сэкономил время на создании очереди заданий в GUI. Но по итогу, если пользователь не умеет писать шелл-скрипты, этот навык для него необязателен.
Но по итогу, если пользователь не умеет писать шелл-скрипты, этот навык для него необязателен.
Я это и говорю. Шелл-скрипты хороши для автоматизации, это как раз то и значит, что они почти никому не нужны, потому что почти никому не нужно ничего автоматизировать))
Шелл-скрипты хороши для автоматизации
Я с этим не спорю. Я не согласен с утверждением:
То, что можно сделать с помощью .sh, .bat, make-файлов, не имеет никакой графической альтернативы.
Имеет. Задача пользователя будет решена без использования сценариев, только за счёт графической альтернативы.
Это несёт некоторые временные издержки. Но дальше уже пользователь сам для себя решает, что ему выгоднее, собирать задания в очереди с помощью GUI или освоить программирование в шелл. Кстати, не обязательно в шелл. Можно ведь скрипт на php написать, который также будет дёргать нужные утилиты.
Мне кажется, сейчас с появлением GPT, количество почитателей командной строки должно резко возрасти. Когда решаешь какие-то задачи в ОС с помощью ИИ, гораздо проще получить решение через командную строку. Чем добиваться от GPT помощи по кнопкам интерфейса системы.
Так как разработка интерфейса является самым затратным занятием, мало того, еще и локализации, это дело еще и дорогое и практически бесконечное. Поэтому разработчик, выбирая между простотой разработки и удобством пользователя, останавливается всегда на первом моменте.
Заметьте, диалоговые системы в программах, использующие командную строку, практически отсутствуют. А там, где они есть, это коммерческие продукты.
Командная строка это не про удобство. Разработчик экономит свое время и крадет ваше.
Знаете, что поразительно? До сих пор никто не удосужился стандартизировать набор аргументов командной строки в диалоговом режиме. Всем плевать. Это же надо о пользователе думать. А такое просто не принято в этой сфере.
Диалоговые системы сильно ухудшают возможность строить сложные системы из простых (composability), вынуждая использовать костыли типа expect. Хорошо, когда диалоговая система есть, но плохо, когда её нельзя не использовать.
Про стандартизацию соглашусь. Система даже не назявывает способ разбора флагов - получил argv, и делай, что хочешь. Было бы здорово иметь централизованный реестр типов, описывающий все флаги всех программ (а ещё и форматы ввода и вывода, хотя бы приблизительно), позволяющий делать разбор аргументов и проверку на совместимость ещё до запуска.
Наверное в Автокаде и подобных ему одной клавиатурой не наработаешь, но в таких программах есть и поддержка сочетание клавиш и команд. И если новичк по началу делает все только мышкой, то с опытом работа с клавиатурой становится все более значимой. А скорость работы возрастает. Вот только, может ошибаюсь, перенести эти "наработки" на другое ПО не очень получается.
А, что если добавить некий доп интерфейс. Например планшет с настраиваем меню, ну хотя бы с иконками. Плюс некую интерактивное добавить, например ткнул в команду, а тебе потом её опции предлагают, ещё Т9 грамотный прикрутить чтобы за контекстом следил.
А есть вариант в windows терминале настроить показ языка ввода ? Как в старом добром DOS ?
Спасибо за статью! Невероятно как точно мои идеи в последние несколько лет здесь красиво описаны.
Меня заинтересовала не сама замена графического интерфейса на терминал, а именно палитра комманд.
Тоже писал статьи по этому поводу.
И попытался реализовать подобную палитру комманд.
А здесь сделал веб приложение для поиска собственной информации по тегам как в Гугл поисковике. Ну и на основе алгоритма прикрутил голосового ассистента.
Тоже считаю что за таким подходом будущее. Это даёт возможность человеческим языком написать команду и обойти процесс гугления комманд, как в случае с терминалом.
Толковый CLI всегда перекроет гуй в рутинных операциях повторяемых 1000 раз в час, очевидно жеж, есть ведь биомеханическая выгода .
Никто ведь не притягивает GUI что бы оператор в приложении тыкал мышкой в кейборду что бы набрать "Хило Ворлд" ?! Верно ведь и обратное в автокаде рисовать, гоняя курсор на кейборде - ну можно, но очень не эргономично и производительно.
Так что, надо разделять применения.
К слоdу о CAD-ах, вот помню P-CAD на заре ... занятия вели для пользователей во многом мышкой, но через год разработчики PCB работали преимущественно в две руки, правой - мышь, левая долбила команды. По мне так интерфейс P-CAD-а - практически идеальный пример сочетания.
К слову о CLI-приложениях, когда что бы вывести список команд нужно знатно потыкать:
--help
--?
-h
--h
--?
Если в ОС нет нормально проработанных средств для разработки CLI , а есть getopt - то такое гуано и будет шествовать по жизни.
Отличнейший пример средств для CLI - CLI$ Routines (API) в VAX/VMS, OpenVMS . Там всё единообразно и даже для HELP был HLP$ Routines (API) - пиши просто и понятно всем.
Как то во всех этих статьях, не упоминается как возможно было работать с электронной почтой через командную строку до, приведенная здесь программа относительно новая, тут уж не обойтись без мало-мальского интерфейса, ведь работа с email - основное для множества, сам работал только в dos и писал autoexec-и
автоматизация. всё, что делается через CLI, очень просто встроить через скрипты для выполнения автоматически
Немного странный аргумент про анимации, мол они замедляют работу программистов, поэтому терминал лучше. Анимации проигрываются за доли секунды, плюс их можно отключить если они мешают. Преимущество терминала перед gui в другом. GUI даёт нам фиксированный функционал, который ещё непонятно, как реализован под капотом. В терминале у нас больше возможностей даже у стандартных команд.
Так же есть много инструментов, которые банально не имеют GUI и доступны только в терминале. Ещё 99% серверов не имеют GUI оболочки и настраиваются только через терминал, например при помощи ssh подключения. Ну и как верно многие писали в комментариях, в терминале проще автоматизировать рутинные задачи при помощи тех же bat, sh и т.д. Думаю поэтому терминал так любят гики.
Скрытая сила терминала или почему всем нужно уметь работать через командную строку