Comments 77
Ну хоть напишите чем он вам нравится и какие есть фишки.
А легко.
нормальное автодополнение - оно есть
встроенный ии помощник, которому можно позадавать вопросы и проконсультироваться по дальнейшим командам или даже напряму дать ему выполнить. не надо лезть в браузер или куда-то еще или костылить cli-йками
он вполне красивый, но это вкусовщина
на расте, тут конечно кому плюс кому минус, но как минимум мультиплатформенный, что, очевидно, плюс
работает из коробки, не надо настраивать, как всякие zsh и проч или конфиги качать, чтобы получить тот же функционал
касательно коммента ниже про то что он отжирает место на мониторе - извините в каком это месте отжирает? он ровно так же как терминал по полезной площади. и да ТАМ МОЖНО ПРОЛИСТАТЬ ВВЕРХ колесиком если вдруг надо и настроить шрифт, что вам еще надо? Может вам стоит монитор покрупнее купить или научиться вкладками пользоваться в терминале?
И да, если вы думаете что я рекламирую и т д , то нет, я просто поделился инструментом, который понравился и может быть понравится кому-то еще.
Но сверхразумы сразу наставили дизов.
Впрочем, не удивительно, что при такой плотности коммунистов на 1 квадратный метр комментов на хабре, что тут столько обиженок, которые к чужое мнение в принципе не способны переварить.
при такой плотности коммунистов на 1 квадратный метр комментов на хабре, что тут столько обиженок
Кармическое самоубийство 😅 К моменту прочтения мной у коммента было всего несколько минусов, можно было и не раздувать... Но поздно
Ну, тем не менее, право на мнение я имею.
Те, кто ставят минусы просто за мнение, которое им не подходит, причем в основном избегая дискуссии - ну извините, они дискредитируют сами себя и смешны. Я вот ни единого минуса не поставил за все время существования аккаунта, даже на тейки самых нехороших на мой взгляд радикалов. В этом нет никакого смысла и более того, даже эти люди имеют возможность высказаться, хотя строго говоря порою это граничит с экстремизмом в большинстве стран мира.
В то время как разного рода (в основном левые, так уж сложилось) аж не успевают минусить мои комменты.
Если меня забанят из-за сгоревшей з*дницы какого-нибудь ресентиментального сверхразума - ну да и ладно, не беда, получается, проиграл совкоцензуре)
Минусы ставят не за мнение, а за форму подачи...
Почему-то за хамство в мою сторону от коммунистов не ставят дизы и причем это происходит систематически но это уже лирика)
И да, что не так в моей подаче касательно первого комента? Я сказал, что мне нравится инструмент name, вот ссылка.
Я кому-то хамил? оскорблял? я кому-то мешал? не нравится инструмент или что? ссылку не надо было добавлять, чтобы не переспрашивали что за терминал? Что не понравилось? Обязан детально расписывать плюсы и минусы или что? Может быть стоит спросить нормально, в чем я вижу плюсы, а не дизить? Это при том что я ответил на вопросы касательно того почему мне нравится тот терминал первому комментатору
Но почему тогда не дизят коменты вроде:
Держите нас в курсе! Нам очень интересно!
Тут, надо полагать, больше конкретики и объективности или как?
PS:
Если вас укусила собака, не обязательно кусать ее в ответ. Большинство дискуссий на Хабре вполне себе можно вести культурно, не прибегаю к оскорблениям.
Я согласен, можно.
Но мне не слишком нравится, что почему-то дизят вполне специфичные коментарии и есть закономерности. Любая условно "правая" и даже не радикальная, да даже просто "центристская" реплика и человек улетает в бан с кучей дизов. Тут даже притензия не то что бы к хабру как таковому, а скорее дело в специфике идеологий людей работающих в разных сферах. И IT тоже имеет свои особенности и профдеформации. Ну и айти это классически "левое" поприще
Да впрочем, смысл с ними спорить
Если вас укусила собака, не обязательно кусать ее в ответ. Большинство дискуссий на Хабре вполне себе можно вести культурно, не прибегаю к оскорблениям.
Я конечно по взглядам одобряю лолы и кеки над коммунистами, но тут это просто вообще не месту, типа - вот вообще не понятно как это приплетено
И да, что не так в моей подаче касательно первого комента? Я сказал, что мне нравится инструмент name, вот ссылка.
Я кому-то хамил? оскорблял? я кому-то мешал? не нравится инструмент или что? ссылку не надо было добавлять, чтобы не переспрашивали что за терминал? Что не понравилось? Обязан детально расписывать плюсы и минусы или что? Может быть стоит спросить нормально, в чем я вижу плюсы, а не дизить? Это при том что я ответил на вопросы касательно того почему мне нравится тот терминал первому комментатору
а потом эмоционально не сдержались и начали какой-то непонятный хейтспич про каких-то обиженок и коммунистов, видимо за это и залетают минуса. У вас в прочих комментариях тоже что-то подобное возникает. Как будто вы не очень умеете контролировать свои эмоции
Диз поставил потому что это, имхо, мимо кассы - warp же просто еще один эмулятор терминала, а тут речь о шелле внутри терминала. Я его пробовал давно, году в 22м - снес как только он начал настойчиво просить авторизацию, т.е. почти сразу, но пожалуй надо дать еще один шанс (хотя еще ничего для меня не лучше wezterm)
UPD: пришла в голову аналогия, что для меня warp в мире терминалов, это как windows 11 в мире операционных систем - кругом из всех щелей "эйай-эйай-эйай", чтобы плюшки работали "sign in or sign up", а под капотом все тот же старый win32 bash и тонны телеметрии, зато красивое
тут столько обиженок
читая коммент выше - сложилось впечатление, что это вы обиделись))
Зашел в профиль, глянул прочие ваши комменты... с таким уровнем тряски - неудивительно, что вам столько минусов ставят, я бы даже сказал - закономерно.
ПС: я не минусил)
Держите нас в курсе! Нам очень интересно!
Больше создает визуального мусора и не эффективно использует и так ограниченное пространство терминала
Я считаю, что есть шелл получше всех вышеперечисленных и вот почему:
Nushell
Nushell появился в 2019 году как попытка переосмыслить консольный интерфейс, сделав его более современным, мощным и универсальным для работы с табличными, структурированными данными. Проект стартовал с позиции: «shell для XXI века», главными разработчиками выступили Yehuda Katz и команда энтузиастов из Rust-сообщества, вдохновлённые гибкостью языков данных и недовольные устаревшими подходами Bash и Zsh. Основан на языке Rust, что обеспечивает высокую производительность и кроссплатформенность.
Установка Nushell:
Установка Nushell стандартна для большинства Linux-дистрибутивов, macOS и Windows:
Linux (Debian/Ubuntu):
sudo apt update sudo apt install nushellМожно также собрать из исходников — для фанатов Rust:
cargo install numacOS:
brew install nushellWindows:
choco install nushellДля вышеперечисленных и других систем доступны бинарные релизы на GitHub.
После установки версия проверяется:
nu --versionЧтобы сделать nushell оболочкой по умолчанию:
chsh -s $(which nu)Временный запуск — просто выполнить nu из любого терминала.
Настройка Nushell
Конфигурация хранятся (начиная с nu 0.60+) в каталоге ~/.config/nushell/, главные файлы:
Настройка максимально проста и понятна: переменные, псевдонимы, функции и оформление задаются декларативно. Для глубокого тюнинга доступна встроенная система плагинов, поддержка тем оформления, а также редактор табличных представлений прямо в терминале.
Для интерактивной настройки можно отредактировать переменную окружения ($env.config), а большая часть новых функций работает «из коробки» без необходимости ручного конфигурирования.
Сложность работы и синтаксис
Nushell отличается от классических shell «табличным» мышлением: большинство команд возвращает структурированные данные (таблицы, списки, записи), которые можно фильтровать, группировать и преобразовывать встроенными командами — по аналогии с SQL или DataFrame в Python(sqlite и polars также поддерживаются, первый из коробки, второй ставится в виде плагина, который можно подключить).
Основные особенности синтаксиса:
Все переменные и данные — типизированные объекты, а не строки.
Пайпы (|) работают как конвейер преобразования данных, а не передачи потоков строк.
Есть встроенные команды для работы с JSON, YAML, TOML, файлами, HTTP, git и др.
Параметры передаются логично: например,
ls | where size > 100kb | sort-by modified— и результат мгновенно фильтруется и сортируется.
Есть поддержка пользовательских команд, функций, псевдонимов и мощнейший парсер выражений.
Поиск по истории: через встроенную команду (history) либо стандартные стрелки.
Возможности Nushell
Встроенная поддержка табличных, структурированных данных (JSON, YAML, CSV, TSV, TOML, Parquet).
Явная типизация (int, string, table, record и др.), что снижает количество ошибок.
Автодополнение, контекстные подсказки, синтаксическая подсветка прямо в терминале.
Встроенные плагины для git, расширенной поддержки форматов, построения запросов(query), агрегаций и аналитики(polars).
Расширяемость через плагины (которые, к слову можно писать не только на расте, но и на других языках, например Python) и темы.
Совместимость с POSIX
Nushell НЕ является POSIX-совместимой оболочкой. Классические shell-скрипты Bash, Zsh, Fish работать в nushell не будут — потребуется адаптация под этот shell. Но всегда можно запустить bash -с "команда" и обработать stdout уже в nu.
Плюсы Nushell
Современная архитектура (Rust, быстрое выполнение).
Работа с табличными, структурированными и бинарными данными из коробки.
Встроенные автоматизации, мощные возможности по управлению файлами, сетями, пакетами.
Отличная поддержка автодополнения, подсветки, поиска, встроенная система help.
Простота расширения и кастомизации.
Кроссплатформенность без гемора — работает на Linux, macOS, Windows.
Огромная документация и активное сообщество (Discord, GitHub).
Минусы Nushell
Не совместим с POSIX (старые скрипты требуют переписывания).
Молодое сообщество (меньше готовых решений и примеров, чем у Bash/Zsh).
Некоторые плагины и интеграции ещё в стадии разработки.
Не всегда доступен прямо на минимальных rescue-системах.
Вывод:
Nushell — единственная оболочка из рассмотренных, которая сочетает «человеко-читабельный» синтаксис, работу с табличными и структурированными данными, производительность Rust и ультра-модульность. Bash остаётся стандартом для совместимости; Zsh — коктейлем автоматизации и тем, а Fish — уютом для новичка. Но Nushell — это новый класс shell, где возможности современных языков объединены с простотой и гибкостью командной строки.
Для инженера, программиста, дата-аналитика, DevOps или хакера — Nushell может заменить старые скрипты автоматизацией в разы проще и нагляднее. Если хочется настоящего «shell будущего», стоит попробовать именно nushell: быстро, удобно, красиво и функционально сразу «из коробки», без костылей и устаревших подходов.
За последние годы улучшений, nu превратился в полноценный скриптовой язык программирования.
Сам я пользуюсь им уже много лет и имею множество самописных модулей, которыми пользуюсь каждый день, а некоторые из них работают на проде.
Я вот им довольно много пользуюсь, но вот есть ряд неудобств
В сети много руководств, где надо команды в терминале запускать и они обычно в лоб не работают в nu
Тоже самое касается нейронок, их можно попросить адаптировать, но это не всегда хорошо работает
Все же башовый export, unset иногда удобнее $env
Там иначе сделаны multiline строки и это путает
Но вот скрипты на nu приятнее писать, чем на другом шелле, это реально полноценный язык программирования.
А вот возможность просто скопировать строчку из найденного в Сети рецепта дорогого стоит, если торопишься или если не очень понимаешь то, с чем приходится работать. Например, был у меня ТВ-тюнер и настройки к нему я искал в Сети. Поскольку постоянно подобными устройствами не пользовался и потому мало что в них понимал, приходилось доверять таким рецептам. А если бы пришлось ещё и переписывать скрипты... Остался бы без фильмов, которые тогда ещё можно было смотреть без крови из глаз. То же самое можно сказать и про кучу других областей.
Можно, конечно, просто запустить bash и в него вставлять те же самые строки, но это уже костыль.
Тоже пользуюсь nushell - очень удобная оболочка. Перешел на нее с zsh и не жалею
Судя по этому описанию, очень похоже на PowerShell.
nushell имхо действительно похож на powershell в своей идее "передаем осмысленные объекты, а не просто строки", но с гораздо более приятным синтаксисом комманд - командлеты в powershell каждый раз напоминают мне FuzzBuzzEnterpriceEdition своими именами
Проблема в том, что у командлетов PowerShell есть чёткая номенклатура и стиль именования - практически 80% командлетов угадываются на лету, а у nu-shell оно как будто "автор так решил", нет никакой системы, что в итоге напоминает попытку сделать тот же PowerShell, но с привкусом Unix-way'я... Никогда не угадаешь, какую команду автор придумал у себя в голове на этот раз, приходится слишком уж часто RTFM'ить. Для пошера вынужден признать эксперимент с nu-shell проваленным. Логики бы туда добавить и гайдлайнов побольше - а, ну тогда PowerShell и получается, хех.
практически 80% командлетов угадываются на лету
Сначала не понял
Для пошера
А потом кааак понял:)
Просто я настолько много писал на bash/zsh и насколько мало на powershell, что у меня вообще никак не происходит угадывания. Всякий раз, понимая что сейчас надо писать Get-ChildItem вместо ls думаю "на баше яб уже давно все сделал"
Спасибо за инфу. Как часто бывает, комментарий принёс более ценную информацию, чем статья.
что то в этом есть, но когда мне вместо |grep надо нписать
-o json | from json | get items | flatten | я как то начинаю сомневаться удобности этого решения для моих целей
Судя по описанию и комментариям ниже, это не то, что мне нужно. Но спасибо за очень подробное и упорядоченное описание.
В обзорах часто пишут про производительность. Выше про nushell тоже это подчеркивается. Со своей стороны, работая много с zsh/bash, не замечал ни тормозов, ни разницы в скорости работы. Как это вообще почуствовать, что шел тормозит?
В больших скриптах с многократным повторением действий, особенно если одни скрипты вызывают другие. В таких случаях условный dash действительно быстрее bash, но только в случаях хорошо оптимизированных скриптов. Иначе разумнее сначала провести оптимизацию (убрать лишние вызовы, переделать парсинг на использование read, гирлянду из grep’ов/sed'ов заменить на одну команду) и может всё уже будет работать достаточно быстро, что не будет смысла лишать себя расширений bash)
"Провести оптимизацию", "переделать"... А может, проще тогда написать скрипт на Python или TCL? Потому что суть оболочки не в том, чтобы делать всё самостоятельно, а в том, чтобы быть "клеем" между программами, присутствующими в системе? Собственно, TCL (Tool Command Language — «командный язык инструментов») изначально для такого делался, а Python позволяет сделать всё "внутри себя", но у обоих есть возможности, до которых оболочке далеко. Просто не стоит скрещивать бульдога с носорогом, пусть каждый инструмент используется для своих целей.
Ну, возможности есть. А уж как ими распорядиться - дело каждого. Особенно если это вопрос личного использования, а не продакшена.
В целом, да. Вопрос только в том, чтобы понимать, когда стоит остановиться в оптимизации и начать писать программу на полноценном языке. Потому что скрипты на Bash, как и на языке любой другой оболочки, это вопрос быстрого написания. А главное - связывания нескольких программ в конвейер. Если логика оказывается слишком сложной, то лучше перейти на более удобный инструментарий.
Если жить на маке, то вообще никак - там любой шелл будет тормозить.
Для остальных - запустить какой-нибудь скрипт расчёта факториала, например. Ну или симуляцию nbody.
Да там и интерфейс тормозит и ускорить его почти невозможно. Причём торможение - это фишка: "И пусть весь мир подождёт". Пока Mac OS медленно рисует окно, на топовом процессоре с максимумом ОЗУ.
Читал информацию, что у них там какие-то проблемы с IO системных вызовов, потому "ради защиты" оно там через три песочницы ходит, поэтому всё безбожно тормозит. Переезд на alacritty с дефолтного терминала примерно вдвое ускоряло работу с ним, но всё равно работало медленно.
Нет, это просто задержки для показа "мультиков". Я с этим маялся в 2013 года. Тогда удалось частично убрать задержку настройками в интерфейсе, частично - страшным не очевидным колдуством через какие-то утилиты командной строки, но до конца это так и не убралось и в итоге мой нетбук на N570 (1.66 ГГц) c 2Гб ОЗУ b Fedora 18 открывал терминал быстрее, чем Mac-mini c процессором 2,5 ГГц (если правильно помню) и 10 Гб. А впервые я с продукцией Apple познакомился ещё в начаел 1995 года. И вот с тех пор лучше не стало. У что точно не умеет делать Apple, так это интерфейсы.
Нет, это просто задержки для показа "мультиков"
не знаю за какие мультики речь, но анимации интерфейса выключались при первой же настройке и это всё не могло влиять на скорость вызова ls в домашней директории, что было одним из способов замера производительности. Диск хоть и шифрованный, но в директории с тремя элементами такая команда отрабатывала почти секунду. echo вывод давало с диким разбросом за 100-500мс, grep по килобайту текста вообще печально. Оно и на linux не сказать чтобы прям шустрым было (в сравнении с ripgrep конечно же), но на маке там прям очень печальные цифры всплывали.
Ну мне тогда отключить не удалось. Ни самостоятельно, ни с помощью человека, который фанател от Apple и нашёл какой-то рецепт для сокращения анимации.
Ещё убивает то, что разворачивание окна на полный экран создаёт для него ещё один рабочий стол. Логика там и рядом не проходила. И изменить ничего нельзя. В Windows анимация отключалась в одно действие ещё в Win95, нормальный переключатель рабочих столов я ставил ещё на WinXP (начиная с Win10 он есть встроенный), а тут... Как сделали, так и пользуйся. Если что, я, когда это чудо (множественные рабочие столы) увидел впервые, сразу сделал вараинт 2*2 и уже почти четверть века такой конфигурацией и пользуюсь. И в WinXP пользовался. А в Mac OS - фиг вам, ходите строем по протоптанным Джобсом дорожкам и не смейте снимать наручники.
Как это вообще почуствовать, что шел тормозит?
Например, в контексте zsh, поставить (ИМХО) б-гмерзкий oh-my-zsh и все в нем поставить на ВКЛ - prompt-lag и command-lag будут ощутимы
У меня как-раз oh-my-zsh с 2-3 плагинами. Как-то тормозов не замечал
Ну так это 2-3, т.е. разумное количество (хотя я же не знаю что за плагины у вас включены)
У меня используется 7, и иногда лаг заметен (в основном из-за git-aware, но и в целом есть очень много мест, где можно улучшить конфиг), но когда эти же плагины использовал вместе с oh-my-zsh лаг был не "иногда"
Из фреймворков для zsh, как будто powerlevel10k выглядит наименьшим из зол
Я использую z, fzf, timer и самописный плагин для vcs (у нас не git, но что-то очень похожее). Вот от него поначалу притормаживало, пока не пофиксил.
Вместо z могу порекомендовать zoxide - то же назначение, только не плагин, а самостоятельная утилита
Забыли упомянуть ohmybash https://github.com/ohmybash/oh-my-bash
При этом Bash поддерживает и расширения, выходящие за пределы POSIX. Например: массивы, арифметика (( )), конструкции [[ ... ]], а также расширенные параметры команд.
синтаксис интерпретатора не имеет отношения к POSIX. POSIX регламентирует только набор утилит и наличие некоторого командного интерфейса, но не синтаксис скриптинга. Bash совместим с синтакисом Shell, который в своё время был частью Unix.
Оболочка настраивается через ~/.bashrc и переменную PS1
А что же стало с PS0 или PS2? И это не просто переменные, а переменные окружения. Коих в том же мануале bash описано с полсотни, а то и больше.
Bash остаётся наиболее универсальным решением.
наиболее универсальным решением остаётся sh, т.к. многие ОС и дистрибутивы не включают bash в поставку от слова совсем. Попробуйте, например, побашить в дефолтном FreeBSD. Без установки баша ручками - нифига не выйдет. В отличие от обычного /bin/sh.
Полной POSIX-совместимости у Zsh нет,
всё есть, но синтаксис интерпретатора может отличаться от sh/bash. Оно вроде как и bash является супернабором над синтаксисом шелла.
и оболочка запомнила это навсегда, без перезагрузок
перезагрузка есть, просто вы не делаете её вручную. И это всё те же переменные окружения.
Fish не соответствует стандарту POSIX
Опять же - соотвествует, хоть и частично. Синтаксис интерпретатора не регламентируется. Но совместимости синтаксиса с другими скриптами нет от слова совсем.
На Linux все три оболочки доступны и легко устанавливаются через менеджеры пакетов
Debian != Linux. Не каждый дистрибутив линукса включает в себя менеджер пакетов.
В WSL на Windows стандартной является Bash
целиком и полностью зависит от установленного дистрибутива, коих под WSL не сказать чтобы много.
синтаксис интерпретатора не имеет отношения к POSIX. POSIX регламентирует только набор утилит и наличие некоторого командного интерфейса, но не синтаксис скриптинга. Bash совместим с синтакисом Shell, который в своё время был частью Unix.
Это неправда. Стандарт IEEE 1003.1-2024 / Shell & Utilities / Shell Command Language определяет синтаксис интерпретатора в точности.
с полсотни, а то и больше
Стало любопытно, поэтому вырезал список переменных, натравил grep и посчитал: 113 имён. Хотя некоторые обозначают одну и ту же сущность, так что на деле их немного меньше.
Чисто на глазок из мануала считал. Там одних только локалей 6 штук, что уже больше 1.
Извините, а при чём тут локали? Я писал о количестве переменных окружения, которыми управляется Bash, как и комментатор, которому я отвечал. Я про локали вообще ничего не писал.
всякие LC_ALL, LC_TIME и прочие переменные относятся к переменным окружения для управлением интернационализации - то что я назвал локалями (LC буквально LOCALE). В стандарте приводится список из 76 штук переменных - из них 6 начинаются с префикса LC_. Когда считал количество переменных в мане, то бросил примерно на 20 и дальше сделал небольшую аппроксимацию из чего и получилось больше полусотни.
Ну и вы вроде мне (комментатору) это и писали.
А ничего, что речь шла об управлении ИМЕННО Bash, а не системой в целом? Упомянутые Вами переменные относятся к управлению всей системой. То есть, нельзя установить отдельно локаль именно для Bash, а потом запускать из него другие программы с другими локалями, не устанавливая из явным образом, так же как до этого это было сделано для Bash. А те переменные, которые упоминал я, влияют ТОЛЬКО на Bash, потому что это переменные, которые создавались именно для оболочки. А переменные локали влияют на библиотеки и утилиты вроде gettext и прочие подобные.
А переменные локали влияют на библиотеки и утилиты вроде gettext и прочие подобные
Ну, логично, что если кто-то переменную использует, на того она и будет влиять. Тот же PS1 волне может зависеть и от других переменных окружения.
Может зависеть, а может и не зависеть. Эта переменная настраивает формат приглашения оболочки. Именно оболочки, каковой является Bash. А переменные LC_* настраивают локаль любой программы запускаемой в системе, то есть, по сути, настраивают систему. А обсуждались именно переменные, специфичные для Bash или хотя бы для оболочки.
насколько мне известно, export LC_* работает как и прочие переменные окружения только в пределах конкретной shell сессии. Открой рядом соседний терминал и он будет с тем, что в системе настроено по-умолчанию и не будет обращать внимания на формат, который ты установил в первом терминале. Если его в какие-нибудь персистентные конфиги не выносить, естественно - profile/bashrc или какие-нибудь глобальные сеттеры конфигурации.
Разумеется, но это то, что устанавливается для всей системы. Для всей системы разом. Для всех программ, начиная с самых первых демонов. А Переменные из мануала Bash настраивают только Bash. Конечно, какие-то ещё программы могу ими пользоваться, но это уже их личное дело, потому что создавались эти переменные именно для Bash. Ну или для Shell, наследником которого является Bash и потому использует эти переменные. LC_* влияют не только на вывод в консоль, но и на вывод в логи, потому что влияют на gettext, который на основании значений этих переменных вытаскивает из системы локализации нужные строчки в указанной локали. И дальше эти строчки могут как попасть в stdout и stderr, так и в логи, записываемые каким-то иным путём.
Опять же - соотвествует, хоть и частично.
Строго говоря, "соответствует" означает "соответствует полностью". Иначе надо писать "частично соответствует". Иначе получается, что наличие одного совпадения достаточно для употребления слова "соответствует".
Попробую набросить. А почему бы не пользоваться powershell под Linux? Он ведь уже давно доступен. На мой взгляд, передача через конвеер списка объектов вместо списка строк это ОЧЧЕНЬ удобно.
Он не такой лаконичный, как bash или zsh в консоли.
А для развесистых скриптов проще, ИМХО, python использовать.
Обычно на linux системах он уже есть (я знаю, что не везде, но те системы, что я смотрел, уже имели python "из коробки").
Разница в том, что языки оболочек позволяют легко связывать программы, тогда как в Python для этого приходится либо строить достаточно сложные конструкции, либо запускать оболочку со скриптом в качестве внешнего процесса. Если что, у меня такое используется в парсерах для рандомизации версии браузера в заголовках. Так что Python - это для тех случаев, когда нужно сделать какие-то довольно сложные операции. Например, перелопатить массив, проведя с ним какие-то вычисления или ещё что-то в этом роде. А если надо связывать утилиты, имея какие-то дополнительные возможности, то тут лучше вспомнить про TCL. Тем более, что летом (если правильно помню) у этого языка вышла версия 9.0 и она уже доступна в дистрибутивах Linux.
Ну, тут соглашусь. Но есть пара нюансов:
Во-первых, кто во что умеет, кому что нравится, вкус, цвет, фломастеры, вот это все. Мне нравится Python, я его и на Windows ставлю, и мой колхозный мониторинг на костылях сделан на Python скриптах. PowerShell удобен, знать его Windows администратору совершенно необходимо, но Python нравится намного больше. Возможно, дело в синтаксисе и привычке.
Во-вторых, надо думать о тех, кто будет поддерживать твои системы после/вместо тебя. Людей, знающих Python, как мне кажется, намного больше, чем знающих TCL. Я вот с ним вообще не знаком, и только после вашего комментария вспомнил,что где-то упоминание о нем видел.
А вообще, - инструмент выбирается под задачу. Чем проще решение частной проблемы, тем лучше.
Дело в разных концепциях ОС. В UNIX и UNIX-подобных ОС "всё есть файл" и именно вокруг этого строились и строятся синтаксисы Shell, Bash, Zch, а так же command.com и cmd.exe. Так вот, stdout и stdin, как и любые другие потоки - это тоже файлы, поэтому конвейеры так весело шуршат в Linux и прочих *nix. А в Windows "всё есть объект" и именно на этом строится синтаксис PowerShell, а так же комплектации JScript и VBScript, которые были основными языками скриптования довольно долгое время. Не знаю, как сейчас, поскольку с Windows в последнее время мало работаю. Поэтому Bash в Windows работал со скрипом - для Windows pipeline - чужеродная концепция, которую приходится втискивать с помощью костылей. И поэтому же PowerShell с не меньшим скрипом должен работать в *nix. С первым случаем вынужден был иметь дело в течении некоторого времени и всё было печально: в Linux те же конструкции работали куда бодрее. По поводу второго могу только предполагать по аналогии. Хотя, конечно, заявляется, что Windows до какой-то степени поддерживает POSIX, но делается эта поддержва, судя по ощущениям от работы с этой частью ОС, именно что костылями, адаптирующей прослойкой.
Слишком большой массив всего, что связано с sh/bash/zsh/etc. чтобы начать пользоваться pwsh вне windows среды. Это и тонны мануалов, гайдов, хаков, плагинов, и огромное комьюнити, и большая временая фора.
Вот и получаем, что "экосистемы нет, потому что комьюнити нет, а комьюнити нет - потому что привлечь никого не могут, а привлечь никого не могут - потому что экосистемы нет".
Хотя сама идея в основе - "оперировать не строками, а объектами", лично мне импонирует.
Сижу на zsh туеву кучу лет. Но это на дома. На работе bash, ибо не вижу смысла ставить на 70к серверов.
А у меня одного ощущение, что статью нейросеть писала?
Она мне обычно так же отвечает: максимаььно общими фактами, с кратким содержанием своего ответа в конце.
Только эмоджи в тексте недостаточно.
Я реально не понимаю зачем нужны проекты вроде fish/nushell и прочие попытки переизобрести шел. Основное преимущество POSIX совместимых шелов в том что скрипты работают везде из коробки, на любой POSIX системе. Меня тоже страшно корёжит от POSIX шела но в этом плане он практически безальтернативен.
В ином случае, если не нужна POSIX совместимость, то есть если вы можете просто поставить любое нужное рантайм окружение на целевую машину типа fish, то почему бы не использовать нормальный язык программирования вместо всего этого зоопарка?
ИМХО sh прекрасно справляется с однострочниками и ужасно со всем остальным, зато переносимо. Если переносимость не нужна то просто пишите на питоне, там всё уже придумано и не нужно учить очередной чудной синтаксис.
Кстати отдельного упоминания заслуживает powershell, который по умолчанию на Винде и прекрасно ставится на Линукс. Неиронично один из лучших современных шелов, на порядок удобнее POSIX совместимых.
Перешел на ghostty после того как iterm2 встроили браузер 🤷♂️
Странно что упомянут Oh My Zsh, а про аналог Oh My Bash ни слова. Украшатель промпта (зачем-то обрзванный тулчейном) Starship есть, а Power10k не упомянут. Промпт agnoster выделен в отдельный тул, а про atuin ни слова. И т.д.
Выше сетовали на неудобство работы с пайпами в python. Любопытно что не упомянули xonsh. Я на него с интересом просматриваю. Но плотно пока не пробовал.
Терминальное противостояние: Bash, Zsh и Fish — что выбрать сисадмину