Comments 72
Ну про чужой опыт крайне интересно почитать.
По крайней мере, для меня это выглядит очень странно, потому что, если Вы не понимаете зачем Вам, как программисту, гибкий инструмент автоматизации, то я уж и не знаю зачем вообще заниматься программированием.
У меня, как у программиста, уже есть гибкий инструмент автоматизации — тот язык на котором я пишу.
Не знаю на чём Вы пишите, но я применяю разные инструменты для разных задач
И все эти задачи требуют использования shell'a? И если нет, то вам так трудно представить себе что у других людей все задачи не требуют использования shell'a или как минимум спокойно решаются без его использования?
Многие задачи и так решаются без использования компьютера. Вам так сложно представить, что у других людей все задачи решаются без его использования?
Нет не сложно. Поэтому я и не утверждаю что "для людей всех профессий компьютер так же необходим, как умение читать" или ещё что-то в этом роде.
Если вам для работы необходим shell, то это ваше дело и ничего плохого в этом нет. Но это не значит что он необходим абсолютно всем айтишникам без исключения.
если Вы не понимаете зачем Вам, как программисту, гибкий инструмент автоматизации,
Объясняю: программируя, я решаю какие-то конкретные задачи. Для каждой задачи есть какие-то свои инструменты. Некоторые оптимальные, некоторые не очень. Некоторые универсальные, некоторые специализированные. И у меня есть удобные мне, и я бы сказал, оптимальные инструменты для всех моих задач.
И, соответственно, мне не нужен гибкий инструмент автоматизации, если 99% этих задач и так давно автоматизированы в IDE, а оставшийся 1% встречается в практике раз в несколько лет, и автоматизация их скриптами шелла никогда в жизни не окупит время, потраченное на чтение манов и потом на собственно написание скриптов. Тем более, что я всё это могу сделать, просто набросав утилитку непосредственно на языке программирования.
И я не ошибусь, если скажу, что у подавляющего большинства программистов ситуация такая же, как и у меня: нет там никаких задач, которые нужно дополнительно автоматизировать за пределами IDE. А просто так изучать инструмент, потому что он прикольный? Ну, у всех разные хобби бывают. Я предпочитаю это время потратить в своей мастерской, например. Там я сделаю что-то куда более интересное для меня, чем изучить командный язык очередной софтины, которой мне не придётся пользоваться.
Интересно Вы интерпретируете данные, если дата регистрации указана - 16 июня
если 99% этих задач и так давно автоматизированы в IDE
Основная задача таких вещей как shell или powershell или bat — это автоматизация задач на енвайрнментах, а не в IDE. И в небольших проектах, где не нужен свой сисдамин и команда, которая поддерживает инфраструктуру, это падает на разработчика. Или вы прямо из IDE деплоите в продакшен?
Или вы прямо из IDE деплоите в продакшен?
Вы так говорите, будто бы в этом что-то плохое :) Если проект настолько небольшой, что там нет ни девопса, ни даже админа, а деплоем занимается непосредственно разработчик, то почему бы не из IDE? Прогнал тесты, переключил в IDE профиль деплоя с теста на прод — и отправил.
И опять же таки, для того, чтобы запустить сборку и потом отправить файлы, знать shell не нужно. Это можно успешно сделать, даже увидев его первый раз в жизни, и не читая манов.
Ну как бы для того чтобы деплоить тоже есть свои IDE и UI. И это совсем не обязательно делать через shell. Тот же Visual Stuido вполне себе имеет достаточно функциональности чтобы "простой разработчик" мог более менее комфортно работать с майкрософтофским TFS и не заморачиваться shell'ом. И вроде бы обещают добавить такую же функциональность и для гита.
То есть для админа/девопса этого однозначно мало. Если ты просто коммитишь, делаешь ревью и деплоишь, то хватает за глаза и за уши.
А как вы парсите json в конвейере?
Как решаете такую проблему: нужно найти текст в выведенном тексте консоли, или в редактор командной строки нужно вставить слово из выведенного в консоли текста?
На каких языках пишете в Vim?
В саблайме вим мод хорошо сделан, повторение команд воспроизведет действия саблайма, чего не будет в идее, да и при работе с несколькими курсорами все отработает как ожидаешь. Ну и да, если добавить маппинг русских букв, то они будут работать так как от них ожидаешь. А Идее мапинг можно добавить но ChangeAllWord на русской раскладке не сработает.
Jq тоже такая себе утилита, ее нужно учить. Где-то была утилитка позволяющая парсить json так как будто вы в js. Вспомнить бы ее название… Иначе если не изучать появляются кадавры
curl someapi | jq '.tickets | map(select(.assigned_displayname=="MyNameOnApi"))' | jq '.[] | "\(.id) \(.title) \t \(.description)\n"' | sed #some after jq prettifying 
Для парсинга json есть jq. На Vim можно писать на многих языках программирования, поддерживается подсветка синтаксиса и автокомлит путем до настройки его
найти текст в выведенном тексте консоли
Если текст уже выведен - средствами терминала. А так, вывести в лог,и как обычно, grep.
А как вы парсите json в конвейере?
смотря что парсить.
очень простые вещи можно вообще тупо грепнуть регуляркой.
Если надо распарсить правильно — стандартная утилита jq
нужно найти текст в выведенном тексте консоли
Если вывод консоли больше экрана, то выполняешь еще раз конвеер, добавляя grep на то, что нужно искать. Это же самое простое.
или в редактор командной строки нужно вставить слово из выведенного в консоли текста?
Обычно я работаю под виндой, и коннекчусь к удаленным линукс серверам через ssh клиент, где отлично работает выделение мышкой, следовательно все очень просто.
Ну и если командная строка слишком сложная, ESC v
(предварительно set -o vi и VISUAL=vi в .profile)
Текст в консольном выводе удобно искать в том же vim, который с версии 8.1 любезно предоставляет :terminal для запуска консоли.
На скриншоте кстати i3wm, очень гибкий и приятный тайловый оконный менеджер, рекомендую
Поскольку автор оригинальной статьи Drew DeVault, то на скриншоте, скорее всего, sway, автором которго он тоже является.
Это всё очень хорошо и здорово работает в маленьких проектах. А когда любой поиск grep начинает выдавать over 9000 строк результата, то становится ясно, что без инструментов, понимающих синтаксис языка - никуда. И ни grep, ни vim этим похвастаться не могут
А я вот использую питон вместо sh. Примерно тоже самое, но еще есть типизация и много прикольных библиотек, которые отсутстсвуют в консольном интерфейсе.
А в чем проблема? Половина операционки на питоне с перлом крутится.
Если исполнение программы на Питоне доберётся до конца — с чего бы процессу остаться висеть?
А что должно произойти с stdout/stdin дочернего процесса?
У bash своя уличная магия, у питона своя ;) На С тоже нужно использовать магию, чтобы зомби не образовались. Вряд ли кто-то использует питон как интерактивную оболочку. А внутри программы можно просто импортировать модуль, где эта магия уже реализована.
Ну так можно перенаправить же. Всё ещё не понимаю где тут проблема может быть.
В bash можно запустить процесс в фоне через & и ни о чем не беспокоиться. В других языках нужно сделать несколько приседаний.
Не уверен что банальное subprocess.popen([параметры], stdin=subprocess.DEVNULL, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL) является особо сложными приседаниями.
& выглядит немного короче ;)
Объект процесса можно сохранить в переменную и проверять её. Это если из логики программы почему-то не следует был ли субпроцесс запущен ранее безо всяких проверок.
Так скрипт запустился, запустил дочерний процесс и умер. Это переменную-объект нужно куда-то сохранять и потом загружать?
А как вы эту проблему на баше решаете? Что мешает поступить так же и на питоне?
тем, что на баше это решается или хранением PID подпроцесса в файле, или вызовом ряда команд типа ps/grep. Но для питона, вызов внешних команд - некрасивое решение, ибо смысл использовать питон, чтобы вызывать другие консольные команды?
Я не говорю, что на питоне это нельзя сделать, просто задача обеспечить запуск только одного экземпляра в одно время - это одна из самых частых, и хотелось бы увидеть как вы решаете эту проблему.
а как в питон сделать проверку, что субпроцесс уже был запущен ранее?
Как и в любом другом языке. Глобальным флажком внутри программы, например.
В файле директории которой происходит правка лежит скрипт f2.sh компиляции и запуска.
Запускается как может быть понятно из названия по клавише f2
map <F2> <Esc>:w<CR>:!bash f2.sh<CR>
vnoremap <F2> :w<CR>:!bash f2.sh<CR>Для правки скрипта автозапуска есть команда сразу в vim :sp f2.sh сохраняем результаты :wq
Сидел на линуксе с 2005 года, генту, потом арч, вот это всё. Neovim с килограммом плагинов (даже сейчас стоит neovide), emacs <s> с педалями </s>. Сейчас сижу под виндой в идее, делаю всё, что и раньше делал. Да, пользуюсь иногда всем линуксовым тулсетом, на велосипеде ездить не разучишься. Но и без него можно найти, как выполнить задачу, главное ее правильно поставить.
Прелесть IDE в том, что тебе не надо ее изобретать, можно сразу работать работу. А если нравится изобретать - так это совсем другое дело! Кстати, изобретать можно и поверх IDE, многие это позволяют.
Я вовсе не утверждаю, что знать шелл бесполезно или вредно, бесполезных знаний не бывает. Но дико бесят такие вот эксперты, как автор оригинального текста. Как правило, это еще присыпают сверху сказками про какую-то мифическую «производительность», как будто программист, это машинист клавиатуры, и его эффективность определяется тем, сколько текста он в день набирает. А в качестве примеров дикого перформанса дают то, что нам в статье было явлено:
Воспроизведение 50 самых новых видео в папке при помощи mpv… Я постоянно использую эту команду.
офигеть какой полезный скрипт, как я жил то без него!
В общем, у меня такие статьи вызывают негодование. Это не спорю с высказыванием выше, просто кипит
Имхо, сама идея того, что приложения обмениваются данными в виде голого неструктурированного текста, устарела. Чтобы заставить одно приложение принять на вход то, что другое дает на выходе, периодически приходится устраивать приседания с регулярками и опциями, уникальным образом настраивающими вывод для данного приложения.
Гораздо удобнее было бы обмениваться объектами, как это делает PowerShell или NuShell.
— при выполнении массовых операций с файлами, например, переместить файлы из пачки папок в одну папку (на уровень выше) или переименовать по определенному шаблону;
— при поиске в куче файлов, разбросанным по папкам, определенного текста (значительно быстрее, чем это сделал бы проводник);
— при копировании файлов с удаленной машины и синхронизации + автоматизации ручных бекапов и т.д.
Так что, продвинутым пользователям Виндовс знание UNIX тоже может пригодиться.
Не проще ли powershell запустить чем WSL для таких задач ставить?
~ ~> find `pwd` -type f -name \*.txt -exec grep "^ABI" {} \; -print
ABIRVALG
/root/qq.txtВ выдаче должна быть строка с совпадением и полный путь к файлу.
Ну и плюс, ЕМНИП, нет удобного дополнения команд и путей табуляцией.
Вообще-то есть.
А еще нет того же grep, find, stat… или есть?
Всё есть: grep называется Select-String, find называется Get-ChildItem, stat доступен как свойства файла.
Вот, например, как это изобразить на powershell?
Проще всего вот так:
Select-String -Path *.txt -Pattern ^ABI | Select-Object Path, LineНо если вам хочется увидеть именно как аналог find работает — то вот:
Get-ChildItem *.txt | %{
$file = $_
Get-Content $file -Encoding UTF8 | Select-String ^ABI | %{
New-Object psobject -Property @{
Path = $file.FullName
Line = $_
}
}
}P.S.
Второй пример, кстати, работает абсолютно так же, как эта строчка:
Select-String -Path *.txt -Pattern ^ABI | Select-Object Line, PathТак какой в нем смысл? К чему он был?
P.P.S.
find называется Get-ChildItem
Меня всегда удивляли люди, умеющие такое придумывать.
Не вижу связи.
Спасибо что изменили свой комментарий после моего ответа, теперь мой прошлый ответ смотрится глупо.
Второй пример, кстати, работает абсолютно так же, как эта строчка:
Разумеется, он и должен работать так же. Точно так же как и ваш однострочник, если я не ошибаюсь, можно заменить на grep -r "^ABI" .
Но вы зачем-то декомпозировали задачу, отделив перебор файлов от поиска по файлу — и я подумал что от примера на powershell вы ожидаете того же.
Меня всегда удивляли люди, умеющие такое придумывать.
Ничего удивительного в этом названии нет, оно одно из самых понятных в powershell. Файлы в powershell являются частным случаем абстракции под названием "item", команда get-childitem получает, собственно, дочерние айтемы.
Судя по этому примеру, в powershell все ключевые слова длинные. Однострочник на bash получается короче.
В повершелл все работает через объекты, и надо работать не с текстом, а с объектами, что не позволяет по-быстрому написать алгоритм.
Скажем так. Можно знать bash плохо и автоматизировать нужные вещи довольно быстро.
А вот повершелл знать плохо нельзя, надо или знать его хорошо, чтобы писать хоть что-то, либо искать уже готовые решения, не всегда понимая как они работают.
При наличии автодополнения меряться длиной команд как-то глупо.
Get-ChildItem *.txt | %{
$file = $_
Get-Content $file -Encoding UTF8 | Select-String ^ABI | %{
New-Object psobject -Property @{
Path = $file.FullName
Line = $_
}
}
}
Для программиста shell так же необходим, как умение читать