xonsh — python как замена shell

    Удивительно, на на хабре до сих пор нет поста о такой, весьма интересной, замене шеллу как xonsh (github), с моей точки зрения синтаксис всяких shell'ов ужасен и не вижу никаких оснований сохранять его в 21 веке, а Python, в свою очередь, обладает прекрасным синтаксисом и массой других преимуществ, поэтому, на мой взгляд, он и должен быть языком автоматизации по умолчанию, чего и пытаеся достичь xonsh.


    Какое-то время использую xonsh, поэтому думаю, что могу рассказать о нём достаточно для того, чтобы начать пользоваться.


    Оговорки:


    • xonsh это только про Python 3, но это норма.
    • xonsh ещё не релизнулся (версия 0.8.3 на момент написания), видимо по мнению разработчиков ещё не все желаемые фичи реализованы, но по моим ощущениям всё работает (если разобраться с отличиями, о чём ниже).

    Основная особенность xonsh в том, что он "магически" угадывает что вы ввели — команду питона или шелла, и это работает вполне хорошо.


    Вставлять питонные код в команды шелла можно с помощью собаки.


    Не буду подробно останавливаться, на том, какие есть возможности в xonsh, это понятно и наглядно описано в документации и всяких статьях, достаточно уже того, что вы можете получить нормальный синтаксис циклов в шелле:


    worldmind@x ~ $ for i in range(3): 
    ...............     echo $SHELL 

    Поэтому я постараюсь сосредоточиться на том, что не описано или описано плохо.


    Установка


    Я буду описывать установку (для Debian/Ubuntu) не требующую права суперпользователя, хотя я только недавно перешёл на такую схему, раньше я ставил в системные папки, прописывал его в /etc/shells и менял шелл командой chsh, но на первый взгляд всё работает также и при новом способе и он мне кажется более правильным, не хочется засорять систему пакетами не из репозиториев, но тут каждый решает для себя сам.


    Ставим pip если ещё не:


    sudo apt-get install python3-pip

    Ставим venv если хотим пользоваться соответствующим функционалом (см. далее про vox):


    sudo apt-get install python3-venv

    Ставим xonsh (без sudo), я привожу команду которая устанавливает все опциональные зависимости, чтобы получить все плюшки задуманные авторами, если кто-то хочет минимальную установку, то можно удалить квадратные скобки с содержимым:


    pip3 install --user xonsh[ptk,pygments,proctitle,linux]

    Скорее всего у вас уже, где-нибудь в .profile в PATH добавляются пути к локальной папке с бинарниками $HOME/.local/bin, но они добавляются только при их наличии, поэтому нужно перезапустить терминал, чтобы этот код отработал и бинарник xonsh можно было запустить и посмотреть.


    venv


    Всякие venv заточены под конкретные шеллы, поэтому xonsh предлагает свою обёртку называемую vox, но для комфортного использования стоит устанавливать расширение avox:


    pip3 install --user xontrib-avox

    Запуск


    Теперь у нас всё установлено и осталось сделать xonsh шеллом, для того, чтобы не менять ничего вне юзерской папки я использую следующий код (по мотивам SO) добавленный в .bashrc, если у вас другой шелл, то вы знаете что делать, только не стоит добавлять в .profile, случится зацикливание т.к. xonsh его тоже читает:


    # set default shell without editing /etc/shells
    if [ "${XONSH_VERSION:-unset}" = "unset" ] ; then
        export SHELL=$HOME/.local/bin/xonsh
        exec $HOME/.local/bin/xonsh -l
    fi

    Перезапускаем шелл и, если всё прошло удачно, вы уже в xonsh т.е. по сути в питон консоли и можете например производить вычисления прямо в командной строке, например узнать сколько будет 2+2.


    Настройка


    Прежде чем начать пользоваться, стоит создать конфигурационный файл .xonshrc:


    aliases['g'] = 'git'
    
    import os
    local_bin = '{}/.local/bin'.format($HOME)
    if os.path.isdir(local_bin):
        $PATH.append(local_bin)
    
    xontrib load vox
    $PROJECT_DIRS = ["~/projects"]
    xontrib load avox

    Перезапускам шелл для применения новых настроек.


    Стоит обратить внимание на человеческую модель данных — алиасы это словарь, пути это список, вроде очевидно, но почему-то не всегда оно так.
    Также, мы в конфиге импортировали модуль osэто значит что он уже будет доступен в нашем шелле, таким образом можно наимпортить нужный модулей и получить своё, удобное окружение.


    Начало приведённого файла больше для демонстрации возможностей, а вот последние три строки позволяют удобно использовать виртуальные окружения, пример использования которых далее.


    Использование виртуальных окружений


    Создаём папку проекта:


    mkdir -p projects/test

    Создаём виртуальное окружение для этого проекта:


    vox new test

    Благодаря настроенному дополнению avox нам достаточно перейти в папку проекта чтобы активировать виртуальное окружение, никаких странных source ./bin/activate выполнять не нужно:


    worldmind@x ~ $ cd projects/test/
    (test) worldmind@x ~/projects/test $ pip install see
    ...
    (test) worldmind@x ~/projects/test $ python -c 'import see'

    По выходу из папки виртуальное окружение деактивируется:


    (test) worldmind@x ~/projects/test $ cd
    worldmind@x ~ $ python3 -c 'import see' err>out | fgrep 'NotFound'
    ModuleNotFoundError: No module named 'see'

    Заодно можно увидеть более человеческую работу с перенаправлением потоков ввода-вывода, кто никогда не забывал как это делать во всяких башах пусть первым кинет в меня коментом.


    Для полноты картины хотело бы, чтобы в этих виртуальных окружениях можно было бы использовать произвольную версию питона, например установленную через pyenv, но пока не срослось, а самому подкостылить руки не дошли.


    Грабли


    Единственное на что я накнулся это отличия в эскейпинге:


    find . -name data.txt -exec echo {} \;

    не будет работать, ибо эскейпинг обратным слэшем не работает в xonsh и фигурные скобки имеют специальное значение, нужно использовать кавычки, например так:


    find . -name .xonshrc -exec echo '{}' ';'

    некоторые отличия от bash есть в виде таблицы в документации.


    Вывод


    Мне кажется, что xonsh это хорошой претендент на нормальный шелл будущего для всех, а особенно он должен понравиться питонистам. Начните пользоваться (установка без sudo упрощает откат назад, можно просто удалить папку), чтобы понять всё ли там есть лично для вас, может это то, что вы искали, но боялись установить.

    Поделиться публикацией

    Похожие публикации

    Комментарии 91
      0
      с моей точки зрения синтаксис всяких shell'ов ужасен и не вижу никаких оснований сохранять его в 21 веке, а Python, в свою очередь, обладает прекрасным синтаксисом

      А если я хочу выполнить ad-hoc команду в консоли в одну строку, синтаксис Python тоже прекрасен? Кстати, там пайплайн все ещё текстовый, а не объектный?
        0
        Давайте примеры команды, посмотрим.
          +6
          Я вообще надеялся в статье увидеть примеры того, как в «стандартных» шеллах всё плохо и как в xonsh всё это исправляет. Цикл — слишком слабенький пример. Пока что то, что Вы описали, больше похоже на сублимацию NIH-синдрома.
            +2
            Допустим у меня есть каталог с файлами *.xml следующего формата

            <yml_catalog date="2018-11-14 12:34">
              <shop>
            </yml_catalog>
            


            Я хочу найти все файлы с аттрибутом date > 2015 года и увеличить значение года в этом аттрибуте на 3, после чего записать файл под тем же именем но с добавлением расширения ".new". Вот решение на PowerShell (да, PowerShell кроссплатформенный, если кто не знает). Внимание! Это не скрипт это запись в коммандной строке, типа, сделал и забыл. А как оно на Python? Табы не мешают?

            ls *.xml | % { @{ xml = [xml](Get-Content $_); file = $_.FullName } } | ? { ([DateTime] $_.xml.yml_catalog.date).Year -gt 2015 } | % { $_.xml.yml_catalog[1].SetAttribute('date', ([DateTime] $_.xml.yml_catalog.date).AddYears(3).ToString('yyyy-MM-dd HH:mm')); $_ } | % { $_.xml.Save($_.file + '.new') }
            
              0
              как бы такая себе задача для шелл-скриптинга, но уверен, что ее можно решить однострочником, возможно привлекая внешние утилиты (типа jq/yq).
              На пайтоне тоже решаться должно достаточно легко, но может не в одну строчку — и самое главное, что там с зависимостями? Не придется ли ставить что-то из доп. модулей?
                +2
                Повершелла не знаю, но за лёгкую работу с XML и датами ему зачёт. А вот считать логику трудно. Например, неясно, создаётся ли файл .new если он выходит идентичным оригиналу.
                В линуксах я обычно делаю что-то такое:
                gawk -F\" '
                BEGINFILE {
                  of=FILENAME ".new";
                  changed=0
                }
                /yml_catalog date/ && $2>2015 {
                  "date +\"%F %R\" -d \"" $2 " 3 years\"" | getline $2;
                  changed=1
                }
                {
                  print>of
                }
                ENDFILE {
                  if(!changed)
                    system("unlink " of);
                  close(of)
                }' *.xml

                Плюсы: обработка файлов любого размера с минимум затрат памяти, можно уловить логику даже не знаю awk.
                Минусы: xml не валидируется, xml должен быть отформатирован как в примере.
                Скорость работы: 25мб/сек на моём некропк.
                  0
                  Да, кстати, очень вряд ли, что приведенный выше ПаверШелл сниппет будет давить больше, чем 25МБ/сек, т.к. там используется пайпинг.
                  +2

                  challenge accepted!


                  for i in *.xml; do DATE=$(xmlstarlet sel -t -m /yml_catalog -v @date $i); [ "$(date +%s -d"$DATE")" -gt "$(date +%s -d2015-01-01)" ] && xmlstarlet ed -u /yml_catalog/@date -v "$(date -d"$DATE 3 years" "+%F %H-%M")" $i > $i.new; done
                    0
                    Круто! Цикл for и имена файлов с пробелами.
                      0

                      Ну можно на


                      ls -1 | while read i; do

                      заменить, там по ходу задачи уже подстроить можно, главное не забывать про кавычки :)

                        +1
                        Цикл for легко заменить на вызов xargs или find. -name
                        0

                        кстати bash без проблем имена с пробелами переваривает:


                        $ touch 1.xml 2.xml '3 4.xml'
                        $ for i in *.xml; do echo "-$i-"; done
                        -1.xml-
                        -2.xml-
                        -3 4.xml-
                      0

                      Тоже самое для bash:


                      for i in $(egrep -l 'yml_catalog date="201[5-8]'  *.xml); do   let j=( $(grep date $i | awk -F\" '{print $2}' |awk -F"-" '{print $1}') + 3 );   sed -e "s/yml_catalog date=\"201[5-8]/yml_catalog date=\"${j}/g" $i > ${i}.new ; done
                        0
                        не, не очень… представляю вашему вниманию ";", ":", "\"
                          +1
                          Я вам завидую, если вы такое в powershell вбиваете не глядя как однострочник, который еще и без ошибок выполняется и делает то, что было задумано :)
                            0
                            С моей точки зрения это как раз скрипт, просто записанный зачем-то в одну строчку.
                              +3
                              Единоразовую задачу я бы сделал в 4 прохода, подставляя каждый раз другой год, неправильным однострочником вида
                              for f in *.xml; do sed -e 's/^<yml_catalog date="2018-/<yml_catalog date="2021-/' $f > $f.new; done

                              и забыл.
                                0

                                Если у вас там 29 февраля где-то было, то оно бы вам о себе потом напомнило.

                                  0
                                  А решение на PowerShell выше, по-Вашему, корректно отработает?
                                  Я думаю, что проблема в постановке задачи, т.к. мы не знаем с какой целью делаем +3 года (можно придумать минимум три способа обработки ситуации 29 февраля).
                          +3
                          Основная особенность xonsh в том, что он «магически» угадывает что вы ввели — комманду питона или шелла, и это работает вполне хорошо.

                          То бишь это Punto Switcher… для боевого оборудования, в котором ТЕОРЕТИЧЕСКИ (!!!) (УТРИРОВАННО И НЕРЕАЛЬНО (!!!)) может сложиться ситуация, при которой моя пайтон-функция rm с аргументами -rf / может восприняться как вызов шелла? Punto Switcher, который может что-то убить? R u kiddin me? Нужно быть самоубийцей, чтобы использовать какую-то динамическую undefinedbehavior-неустойчивую систему без тестирования и дебага на реальных данных!

                          Годами пытаются закопать незакапываемый шелл… всё тщетно. Годами на хабрах постят знакомства с zsh и IPython в качестве замены якобы неудобного и неприятного стандарта, но IMHO удобнее баша ничего нет и не будет.
                            +6
                            Ув. минусующий, я по первому гугол-запросу xonsh deleted нашёл github-issue xonsh-репы с названием «rm -rf *; /foo» deletes /foo. Объясни же мне, в чём я неправ? Или тебе нравится использовать своё железо и данные в качестве «подопытного кролика»? Ну поздравляю, у тебя стальные яйца.
                              +1
                              Основная особенность xonsh в том, что он «магически» угадывает что вы ввели
                              То бишь это Punto Switcher…
                              Думаю, тут неспроста слово «магически» взято в кавычке: ничего xonsh не угадывает, а различие между вызовом внешних команд и питоновским кодом однозначно детерминировано грамматикой скриптового языка.

                              Может сложиться ситуация, при которой моя пайтон-функция rm с аргументами -rf / может восприняться как вызов шелла?
                              Конкретно такая ситуация сложиться не может. Ваш пример с rm -rf *; /foo всё же несколько про другое.
                              0
                              А что с производительностью? Мне тут сказали, что некоторое время назад все было очень плохо.

                              Бегло посмотрел документацию, сильно смутило в faq
                              «computing branch names and colors (i.e. if the branch is dirty or not), can be a pretty slow operation. This is bad news because xonsh can try to compute these each time it formats the $PROMPT»
                              То есть я правильно понимаю, что он не может в многопоточность?
                                0
                                Да вот непонятно как её измерять, визуально всё работает шустро даже на моих убогих ноутах.
                                Что подразумевается под «не может многопоточность»?
                                  +1

                                  Думаю, что тут дело не в оболочке, а в том, что для проверки того, грязная ветка или нет, надо каждый раз запускать git, который будет оббегать дерево каталогов. Это в любом случае будет очень накладно.

                                  +7
                                  Все эти 'убийцы шелла' обладают фундаментальным недостатком которого нет у шелла: шелл есть везде, от роутера и умного чайника до распределенного кластера. Вся статья, по сути, набор костылей с целью прикрутить очередного убийцу шелла к системе в которой уже есть шелл. Да, шелл неудобен, он устарел. Но в мире уже имеются сотни миллионов строк написанных на нем, которые прежде чем переписывать на что-то новое, надо запускать и поддерживать. Так что вы убиваете его не с того конца.
                                    +5
                                    Плюсую.
                                    А есть ещё одна проблема — он лучше всех оттестирован и неоф-документирован, и большинство проблем уже решено и решения замечательным образом лежат на стэковерфлоу и подобных ему. И нормальные люди считают это не проблемой, а отсутствием оной. KISS!
                                      +3
                                      Здесь все не так хорошо на самом деле. Проблемы есть и они огромные. Я на шелле пишу уже наверно лет 10 и со временем пришел к мысли что если шелл скрипт разрастается больше чем на 100-300 строк, то это офигенный такой звонок на то чтобы переписать его на чем-то другом, например том-же питоне. Потому что начинают вылезать куча проблем по поддержке и расширению кода. Банально, корректно попарсить входные параметры это целая головная боль. Да, стековерфлоу предлагает кучу вариантов с getopt/getopts/while, но после того как код написан, он выглядит действительно страшно. Как-либо проворачивать данные в шелле это целый ад, ибо требуются сотни грабель с экранированием, кучи проверок, и целые гирлянды из awk/sed/tr и прочих вещей. Каких-либо нормальных структур данных типа тех же списокв/мап шелл не поддерживает, как и форматов, то есть пролетающие json/xml/yaml приходится парсить питоном/jq и еще кучей дополнительных тулов или самописными граблями которые тебя рано или поздно подставляют. Приходится уходить на питон, но там начинается свой головняк с виртуаленвами, пипом и прочими прелестями.
                                        +1
                                        Полностью согласен, но стоит добавить, что шелл добавляет боли в части разницы между диалектами sh/bash (sh — он типа везде, а bash — не совсем). Еще есть даже разница между разными версиями bash (о, черт!), хотя во всех современных дистрибутивах Линукс он плюс/минус одинаков.
                                        Что еще выморозило: некоторые команды между Linux/MacOS/Win имеют разное поведение. Например, xargs не имеет прекрасного ключа -r при запуске под Mac. А этот ключ, между прочим, позволяет не фильтровать лишний раз ввод. Я представляю себе сколько еще бойлерплейта придется написать, чтобы проверить наличие необходимых фич и сделать переносимый шелл-скрипт.
                                          0
                                          Это вы еще под solaris не писали :).
                                          0
                                          но там начинается свой головняк с виртуаленвами, пипом и прочими прелестями.

                                          Попробуйте pipenv — он облегчает работу, но его правда тоже надо сначала установить
                                            0
                                            головняк с виртуаленвами, пипом и прочими

                                            Честно говоря я много слышал про какие-то проблемы, но не очень их понимаю, есть pip для тех кто хочет чего-то стандартного и работающего, он умеет и в систему ставить, и в юзера и в виртуальные окружения (что в посте и продемонстрировано), какие проблемы тут у кого возникают?
                                              0
                                              Ну например тем, что по дефолту этого нет, соответственно надо писать враппер который готовит окружение, обычно на том же shell :). Так же бывают хитрые ограничения например когда к pip нету доступа, или он через прокси завернут.
                                                0
                                                Не очень понятно когда такое возможно.
                                                  0
                                                  Например, в приватном облаке.
                                                    0
                                                    вобщем понятнее не стало о какой проблеме речь
                                                      0
                                                      Конкретный пример: есть код на питоне который обновляется и его по хорошему надо крутить в виртуаленве чтобы отвязать его от конкретной системы, а чтобы крутить его в виртуаленве надо этот виртуаленв поставить, чтобы не ходить и не делать это руками (потому что много разношерстного кода) появляются всякие обертки.
                                                        0
                                                        Так а что/кто мешает поставить venv?
                                                          +1
                                                          C 2012 года (Python 3.3) virtualenv ставить не обязательно. См. docs.python.org/3/library/venv.html
                                            +3

                                            Пожалуй самая главная проблема всех этих супер-пупер удобных, мощных, выразительных, и тэ дэ и тэ пэ в том, что эту безумную дыру ничем не заткнуть, буде понадобится. Нет песочницы, кто угодно может подключить себе что угодно и делать что угодно (это кстати и ко многим встраиваемым языкам относится, единственный, где об этом подумали — Lua). Удобство не должно мешать контролю. А то как-то читал статью, где пытались ограничить встраиваемые возможности питона — сколько там дыр, чтоб вылезти из песочницы и импортнуть то, чего импортировать не положено. Прям напоминает бородатую историю со входом в винду через справку

                                              0
                                              Ну это касается также и традиционных shell'ов.
                                              0
                                              Всё так, но это не значит, что нет шансов на изменение, когда-то легаси начинает отмирать, вот когда-то перл был везде и много чего на нём было написано, где он теперь? Во freebsd например давно из базовой поставки выпилили.
                                              –1
                                              busybox — «is a ...»
                                                +1
                                                Неудобство vi убивается его изучением. Милейший редактор.
                                                Неудобство sh убивается его изучением.
                                                Неудобство от милейшей поделки испытаете в режиме восстановления не зная shell и не имея своей поделки под рукой.
                                                  +1
                                                  Тут разные проблемы, вы потеряли причинно-следственную связь.
                                                  Неудобство vi превращается в удобство vi после его изучения. А якобы неудобство sh остаётся якобы неудобством sh в сравнении с якобы удобством Python.
                                                    +3
                                                    Абсолютно никакая причинно-следственная связь не избавит нас от факта что sh, bash и компания устарели и являются куском теплой массы. Даже, кто бы мог подумать, PowerShell является более удобной и современной заменой. Ну а то что sh не будет заменен в ближайшее будущее, потому что он уже плотно пустил корни везде (до недавнего времени даже init системы были на баше; хотя ярые противники systemd сейчас будут говорить что раньше было лучше) — это уже совсем другая история.
                                                      –4
                                                      Системди не юниксвейный (хотя у него куча преимуществ, отрицать не буду), инит простой и умещается в кармашек (переносимость ПО даёт возможность более лёгкой миграции сферы деятельности в IoT из SRE или наоборот, в общем универсальный инструмент всегда лучше) а PoSh — это отврат. И вообще… бытует мнение, что лучшим *nix-админом становится BSD-админ. Я не проверял и не разу не трогал фрю, но почему-то верю на слово. А значит… может «трава» действительно «была зеленее»?
                                                      0
                                                      Но ведь нужно сначала изучить питон… ))
                                                        +2
                                                        Считается, что это является более простой задачей относительно изучения баша (если отбрасывать тех ребят, которые с двухтысячного пишут на перле и просто принципиально отметают всё новое — так оно и есть). Хотя для меня питон слишком уж… красивый. Да, наверное он крут тем, что с помощью него можно быстрее всего выразить мысль, но… запрет смешивания табов и пробелов и подобная джавоподобная корпоративщина немного сковывают в рамки.
                                                          +1
                                                          Питон изучать намного проще и полезнее, он логичный и применяется очень широко.
                                                            0
                                                            bash тоже применяется очень широко. Те же пайплайны, инит-скрипты и прочее. Но за пределами этой утилитарщины — нет, bash особо не нужен, в отличие от python. На котором реально можно сложные программные системы создавать.
                                                          0
                                                          sh универсален. Python — нет. Тем более третий. Вот когда в каждом чайнике и кофеварке будет python — тогда и поговорим.
                                                            0
                                                            Вы не мне это говорите, я на Вашей стороне. :)
                                                            0
                                                            Python хорош в нормально функционирующей системе где можно сказать, что каждый из отдельных кусочков этого интерпретатора и его библиотек не нуждается в проверке.
                                                            Shell монолитен. Он либо работает, либо не работает. Если не работает шелл, то надо посмотреть в другом режиме или другим экземпляром.
                                                            Мне к сожалению часто попадают системы в которых нет необходимых библиотек для функционирования той или иной прикладной программы. К прикладным я отношу и python, как язык программирования с огромным набором модулей.
                                                          0
                                                          Поскольку статья ни о чём, могу только заметить, что питон полностью не подходит на роль командной оболочки.
                                                            +1

                                                            По мне так лучше tcl нету скриптового языка. А если иметь ввиду еще и expect ...

                                                              +1
                                                              Авторы в первом же абзаце в ридми на гитхабе пишут:

                                                              «The idea for xonsh first struck while I was reviewing the Bash chapter (written by my co-author Katy Huff) of Effective Computation in Physics. In the book, we spend a bunch of time describing important, but complex ideas, such as piping. However, we don’t even touch on more ‘basic’ aspects of the Bash language, such as if-statements or loops. Even though I have been using Bash for well over a decade, I am not even sure I know how to add two numbers together in it or consistently create an array. This is normal.»

                                                              Кажется, что это классическое «я не осилил, поэтому придумал свое». Сколько уже фреймворков, языков и библиотек было создано по этой причине.
                                                                0
                                                                Особенно если мы говорим о пайпинге. Ведь на баше это `ls | grep abc` а вот на питоне будет морока та еще.
                                                                  0
                                                                  вы путаете shell и unix tools, от второго никто не предлагает отказаться.
                                                                    0
                                                                    и зачем они нужны (в python)? subprocess check_call и поехали? А ничего, что там накладные расходы будут даже больше, чем в случае использования шелла напрямую?
                                                                      0
                                                                      не распарсил, поясните мысль
                                                                        0
                                                                        Расшифрую.
                                                                        Если мы коммитимся на использование python окружения — нам не нужны пайплайнинги, т.к. пайтон на батарейках и умеет почти все из коробки (листинг директорий, поиск текстов и т.п.).
                                                                        Если же пытаться использовать сторонние утилиты через вызов subprocess.check_call, то можно задействовать пайплайнинг, но накладные расходы все равно выше, чем при попытке утрамбовать такую конструкцию в однострочник bash. Не говоря уже о зависимостях от внешних бинарей. Либо, если руками собирать pipe, то там столько бойлерплейта будет, что проще вздернуться.
                                                                          0
                                                                          Не согласен, все-таки unix tools это специализированный инструмент, который конечно же удобнее в простых случаях и накладные расходы тут настолько мизерные, что нет смысла их обсуждать, я когда ввожу ls в xonsh не вижу никаких накладных расходов которые бы заставили меня писать
                                                                          import os; os.listdir('.')
                                                                          даже если import бужет сделан заранее.
                                                                          Не говоря уже о более продвинутых тулзах типа tree если продолжать пример со списокм файлов.
                                                                            0
                                                                            > поиск текстов
                                                                            И тут мне вспоминается этот пост: adamdrake.com/command-line-tools-can-be-235x-faster-than-your-hadoop-cluster.html
                                                                    0
                                                                    Но это не означает автоматически, что получилось плохо/хуже.
                                                                      +1
                                                                      Автоматически — нет. Но авторы первым аргументом приводят то, что им они не осилили баш, а не то, что у него есть фундаментальные недостатки, которые они нашли, как исправить. Кажется, что решения в духе «чот там слишком сложно, там же должно быть просто, щас все по-быстрому накидаем» чаще оказываются скорее плохими, чем хорошими.
                                                                        –1
                                                                        Ну с моей точки зрения про баш это оправдано, вопрос ведь не в том, что его нельзя осилить, вопрос в том нужно ли тратить усилия на такое уродство?
                                                                          0
                                                                          Предложите альтернативы.
                                                                          Как говорится, «лучше старый проверенный друг, чем два новых».
                                                                          И «старый конь борозды не испортит» (в плане того, что все эти bash/unix tools отлажены десятилетиями).
                                                                            0
                                                                            Так сей пост и описывает альтернативу.
                                                                              –1
                                                                              Вы сейчас шутите? xonsh — альтернатива?
                                                                              А можно что-то нормальное?
                                                                                0
                                                                                А что в вашем понимании «нормальное»?
                                                                                  0
                                                                                  Ну, не знаю. Что может стать стандартом де-факто.
                                                                                  Например, zsh/fish — еще куда ни шло.

                                                                                  /молодцы минусовать, если мнение не нравится. Видимо есть только два мнения -мое и неверное? толерантнее надо быть/
                                                                                    0
                                                                                    Да тут никого ваше мнение не интересует, может интересовать аргументированная позиция, но пока с аргументами у вас никак.
                                                                                      0
                                                                                      Кому надоело ездить на работу на лошади — вот наша альтернатива — питон верблюд. Какую из доальтернативных задач эта альтернатива решает, никто не может внятно обьяснить.
                                                                                        0
                                                                                        Ну если кому-то кажется что с шелом всё нормально, то конечно ему ничего менять не нужно, с моей же точки зрения шелл и его синтаксис это лишняя сущность, лишний, причём с очень уродливым ситнтаксисом, язык, при том, что есть, повсеместно применяемый скриптовый язык с очень хорошо выглядящим синтаксисом.
                                                                                          0
                                                                                          Уродливый синтаксис это дело вкуса. Верблюд ведь красивше лошади? ;)
                                                                                          КМК основная задача шелла типа bash — удобно запускать разные другие программы, с этим у него все нормально. А для программирования есть много других языков.
                                                                                            +1
                                                                                            Я вообще не понимаю почему нужно менять специализированное решение (shell + unix tools + возможности расширениями утилитами, которые работают через консоль и консольные аргументы) ОБЩИМ решением, которым является python.

                                                                                            Возможно, что нужно попытаться поменять мировоззрение и пытаться не засунуть вызовы этих внешних утилит в python (что действительно неудобно), а пользоваться уже существующими примитивами в python. Т.е. примеры:
                                                                                            — хотим получить список файлов и сделать операцию над ними — пользуемся модулем os (listdir и поехало)
                                                                                            — хотим скачать страницу из интернета -пользуем requests или/и urllib
                                                                                            Но фишка в том, что в простых случаях проще дернуть curl, чем писать простыни шаблонного кода на python.

                                                                                            Короче — такое себе.

                                                                                            А вообще, конечно, вспоминаю себя, когда я пытался в консоли DOS на Spectrum'е ввести 2+2 и мне оболочка говорила, что команда не найдена. Расстройство было жуткое — какие же компьютеры глупые )))) а всего лишь нужно было немного изучить командный язык.
                                                                                              0
                                                                                              Так никто и не предлагает заменять unix tools, речь только об отказе от шелла как языка программирования автоматизации.
                                                                                                0
                                                                                                worldmind просто нужно разделять котлеты и мух. Серьезную автоматизацию — никто на баше и не предлагает делать. Видимо, критерии серьезности у всех свои. Вот те же ETL (работа с БД, обработка данных и пр.) меня не обламывает писать на python, но я готов брать на себя поддержку среды, в которой они выполняются.

                                                                                                А условный скрипт запуска сервиса, проверки наличии файла, переконвертации из формата в формат, скачивания сайта рекурсивно и пр. — проще наговнякать на баше.

                                                                                                Нужно подбивать подходящий тулинг.

                                                                                                А самое милое дело — хорошо написанные скрипты на python практически ничем не отличаются от консольных утилит и точно так же интегрируются с другими unix tools (pipelining, коды возврата и пр. пр.). Но как бы есть определенная разница с однострочниками на xonsh
                                                                    0

                                                                    Я использую уже около года fish. Правда сам не могу объяснить почему. Вроде и удобная оболочка, но по некоторым вещам из bash/zsh до сих пор скучаю.


                                                                    По теме: всегда не понимал bash/zsh. Мне кажется, что и язык и реализация этих оболочек какие-то архаичные и эклектичные. Скрипты на bash/zsh кажутся слепленными из палок и изоленты — чуть тронь в любом месте, и все развалится (часто так и происходит). Я знаю, что на shell писались (возможно, пишутся до сих пор) проекты размером в сотни тысяч строк, но это сущий кошмар в поддержке.


                                                                    Странно, что до сих пор никто не сделал нормальный shell с нормальным читаемым языком внутри… Fish, мне кажется, ближе всех подошел, но и в нем остаются недостатки, кроме того, он не очень популярен.

                                                                      0
                                                                      PowerShell же.
                                                                      +1

                                                                      Синтаксис шелла ужасен с точки зрения малознакомого с синтаксисом шелла. Как и любой язык он обладает большими и малыми недостатками.


                                                                      Аналогично синтаксис Питона ужасен с точки зрения человека, малознакомого с Питоном. Наверняка Питон тоже обладает большими и малыми недостатками. Чего стоит его зависимость алгоритма от количества пробелов.


                                                                      Более важно, что шелл есть везде, Питон — нет.

                                                                        0
                                                                        Все еще хуже. Шелл есть везде, и как выше заметили — монолитен. Он либо работает, либо нет.
                                                                        Python — он уже есть как минимум двух несовестимых версий. И требует рабочего окружения. А оно запросто может быть или сломано (например, я сталкивался с таким — stackoverflow.com/questions/47197083/python-pip-error-just-after-fresh-install ), или вам нужны модули какой-то определенной версии, которые или не установлены, или НЕ МОГУТ быть установлены в рамках одного, системного окружения.
                                                                          –2
                                                                          Аналогично синтаксис Питона ужасен с точки зрения человека, малознакомого с Питоном.

                                                                          Как раз на мой взгляд синтаксис питона для незнакомых с ним наиболее понятен
                                                                            0
                                                                            >Аналогично синтаксис Питона ужасен с точки зрения человека, малознакомого с Питоном

                                                                            Уж лучше питон чем перл
                                                                            0
                                                                            а вообще каждая тулза должна юзатся для определенной нужды, и если есть возможность пользоватся одной тулзой с модулями которые позволят выполнять работу для других сред то зачем заменять эту же тулзу? я вот например в баше могу вызвать и повершел и еще кучку всякого разного и спокойно выполнить нужные мне задачки. тоже самое и в повершелке. как бы можно писать что вот вам тулза которая похоронит остальное и она будет крутая, но зачем такое писать не пойму. Если есть гайка и к ней ключ которым ее закручивать то это не значит что болгарка выполнит эту задачу лучше… исправьте если я не прав
                                                                              +1
                                                                              Пользуюсь xonsh в guake (выездной консоли) — очень удобно, и шелл и калькулятор (мой основной use case питона) всегда под рукой по одному и тому же hot key, можно заранее прогрузить все модули которые часто использую, numpy, pandas и пр.

                                                                              Заметил только что xonsh иногда призадумывается секунд на 2-3 после долгого простоя — никто не сталкивался с таким явлением, как оно лечится?
                                                                                0
                                                                                В смысле задумывается? Не сразу выезжает консоль? Это скорее не в xonsh дело.
                                                                                  0
                                                                                  Нет тормозит именно xonsh, начинаешь печатать, а эхо от него только через пару секунд появляется, c bash такой проблемы не было
                                                                                    0
                                                                                    Я с таким не сталкивался, версия самая новая?
                                                                                +1
                                                                                Баш прекрасен!)
                                                                                image

                                                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                Самое читаемое