Удивительно, на на хабре до сих пор нет поста о такой, весьма интересной, замене шеллу как 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 упрощает откат назад, можно просто удалить папку), чтобы понять всё ли там есть лично для вас, может это то, что вы искали, но боялись установить.

Комментарии (88)


  1. IvanNochnoy
    14.11.2018 18:59

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

    А если я хочу выполнить ad-hoc команду в консоли в одну строку, синтаксис Python тоже прекрасен? Кстати, там пайплайн все ещё текстовый, а не объектный?


    1. worldmind Автор
      14.11.2018 19:02

      Давайте примеры команды, посмотрим.


      1. KevlarBeaver
        14.11.2018 20:23
        +4

        Я вообще надеялся в статье увидеть примеры того, как в «стандартных» шеллах всё плохо и как в xonsh всё это исправляет. Цикл — слишком слабенький пример. Пока что то, что Вы описали, больше похоже на сублимацию NIH-синдрома.


      1. IvanNochnoy
        14.11.2018 20:25
        +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') }
        


        1. gecube
          14.11.2018 20:38

          как бы такая себе задача для шелл-скриптинга, но уверен, что ее можно решить однострочником, возможно привлекая внешние утилиты (типа jq/yq).
          На пайтоне тоже решаться должно достаточно легко, но может не в одну строчку — и самое главное, что там с зависимостями? Не придется ли ставить что-то из доп. модулей?


        1. legolegs
          14.11.2018 22:29
          +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мб/сек на моём некропк.


          1. gecube
            15.11.2018 00:55

            Да, кстати, очень вряд ли, что приведенный выше ПаверШелл сниппет будет давить больше, чем 25МБ/сек, т.к. там используется пайпинг.


        1. kvaps
          15.11.2018 02:58
          +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


          1. sub31
            15.11.2018 03:59

            Круто! Цикл for и имена файлов с пробелами.


            1. kvaps
              15.11.2018 04:16

              Ну можно на


              ls -1 | while read i; do

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


              1. gecube
                15.11.2018 08:16
                +1

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


            1. kvaps
              15.11.2018 17:50

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


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


        1. thatsme
          15.11.2018 09:18

          Тоже самое для 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


        1. hapylestat
          15.11.2018 09:36

          не, не очень… представляю вашему вниманию ";", ":", "\"


        1. anonymous
          15.11.2018 09:36
          +1

          Я вам завидую, если вы такое в powershell вбиваете не глядя как однострочник, который еще и без ошибок выполняется и делает то, что было задумано :)


        1. worldmind Автор
          15.11.2018 10:51

          С моей точки зрения это как раз скрипт, просто записанный зачем-то в одну строчку.


        1. iig
          15.11.2018 13:41
          +3

          Единоразовую задачу я бы сделал в 4 прохода, подставляя каждый раз другой год, неправильным однострочником вида

          for f in *.xml; do sed -e 's/^<yml_catalog date="2018-/<yml_catalog date="2021-/' $f > $f.new; done

          и забыл.


          1. legolegs
            16.11.2018 20:40

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


            1. gecube
              16.11.2018 20:50

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


  1. tchspprt
    14.11.2018 19:09
    +3

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

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

    Годами пытаются закопать незакапываемый шелл… всё тщетно. Годами на хабрах постят знакомства с zsh и IPython в качестве замены якобы неудобного и неприятного стандарта, но IMHO удобнее баша ничего нет и не будет.


    1. tchspprt
      14.11.2018 19:31
      +6

      Ув. минусующий, я по первому гугол-запросу xonsh deleted нашёл github-issue xonsh-репы с названием «rm -rf *; /foo» deletes /foo. Объясни же мне, в чём я неправ? Или тебе нравится использовать своё железо и данные в качестве «подопытного кролика»? Ну поздравляю, у тебя стальные яйца.


    1. firegurafiku
      15.11.2018 04:15
      +1

      Основная особенность xonsh в том, что он «магически» угадывает что вы ввели
      То бишь это Punto Switcher…
      Думаю, тут неспроста слово «магически» взято в кавычке: ничего xonsh не угадывает, а различие между вызовом внешних команд и питоновским кодом однозначно детерминировано грамматикой скриптового языка.

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


  1. myxo
    14.11.2018 19:27

    А что с производительностью? Мне тут сказали, что некоторое время назад все было очень плохо.

    Бегло посмотрел документацию, сильно смутило в 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»
    То есть я правильно понимаю, что он не может в многопоточность?


    1. worldmind Автор
      15.11.2018 09:40

      Да вот непонятно как её измерять, визуально всё работает шустро даже на моих убогих ноутах.
      Что подразумевается под «не может многопоточность»?


    1. immaculate
      15.11.2018 09:47
      +1

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


  1. wsf
    14.11.2018 19:42
    +7

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


    1. tchspprt
      14.11.2018 19:55
      +5

      Плюсую.
      А есть ещё одна проблема — он лучше всех оттестирован и неоф-документирован, и большинство проблем уже решено и решения замечательным образом лежат на стэковерфлоу и подобных ему. И нормальные люди считают это не проблемой, а отсутствием оной. KISS!


      1. wsf
        15.11.2018 00:40
        +3

        Здесь все не так хорошо на самом деле. Проблемы есть и они огромные. Я на шелле пишу уже наверно лет 10 и со временем пришел к мысли что если шелл скрипт разрастается больше чем на 100-300 строк, то это офигенный такой звонок на то чтобы переписать его на чем-то другом, например том-же питоне. Потому что начинают вылезать куча проблем по поддержке и расширению кода. Банально, корректно попарсить входные параметры это целая головная боль. Да, стековерфлоу предлагает кучу вариантов с getopt/getopts/while, но после того как код написан, он выглядит действительно страшно. Как-либо проворачивать данные в шелле это целый ад, ибо требуются сотни грабель с экранированием, кучи проверок, и целые гирлянды из awk/sed/tr и прочих вещей. Каких-либо нормальных структур данных типа тех же списокв/мап шелл не поддерживает, как и форматов, то есть пролетающие json/xml/yaml приходится парсить питоном/jq и еще кучей дополнительных тулов или самописными граблями которые тебя рано или поздно подставляют. Приходится уходить на питон, но там начинается свой головняк с виртуаленвами, пипом и прочими прелестями.


        1. gecube
          15.11.2018 00:50
          +1

          Полностью согласен, но стоит добавить, что шелл добавляет боли в части разницы между диалектами sh/bash (sh — он типа везде, а bash — не совсем). Еще есть даже разница между разными версиями bash (о, черт!), хотя во всех современных дистрибутивах Линукс он плюс/минус одинаков.
          Что еще выморозило: некоторые команды между Linux/MacOS/Win имеют разное поведение. Например, xargs не имеет прекрасного ключа -r при запуске под Mac. А этот ключ, между прочим, позволяет не фильтровать лишний раз ввод. Я представляю себе сколько еще бойлерплейта придется написать, чтобы проверить наличие необходимых фич и сделать переносимый шелл-скрипт.


          1. wsf
            15.11.2018 01:09

            Это вы еще под solaris не писали :).


        1. orion_tvv
          15.11.2018 15:53

          но там начинается свой головняк с виртуаленвами, пипом и прочими прелестями.

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


        1. worldmind Автор
          15.11.2018 15:56

          головняк с виртуаленвами, пипом и прочими

          Честно говоря я много слышал про какие-то проблемы, но не очень их понимаю, есть pip для тех кто хочет чего-то стандартного и работающего, он умеет и в систему ставить, и в юзера и в виртуальные окружения (что в посте и продемонстрировано), какие проблемы тут у кого возникают?


          1. wsf
            15.11.2018 17:40

            Ну например тем, что по дефолту этого нет, соответственно надо писать враппер который готовит окружение, обычно на том же shell :). Так же бывают хитрые ограничения например когда к pip нету доступа, или он через прокси завернут.


            1. worldmind Автор
              15.11.2018 17:49

              Не очень понятно когда такое возможно.


              1. wsf
                15.11.2018 18:16

                Например, в приватном облаке.


                1. worldmind Автор
                  15.11.2018 18:29

                  вобщем понятнее не стало о какой проблеме речь


                  1. wsf
                    15.11.2018 19:30

                    Конкретный пример: есть код на питоне который обновляется и его по хорошему надо крутить в виртуаленве чтобы отвязать его от конкретной системы, а чтобы крутить его в виртуаленве надо этот виртуаленв поставить, чтобы не ходить и не делать это руками (потому что много разношерстного кода) появляются всякие обертки.


                    1. worldmind Автор
                      16.11.2018 09:28

                      Так а что/кто мешает поставить venv?


    1. Mingun
      14.11.2018 22:35
      +3

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


      1. worldmind Автор
        15.11.2018 09:46

        Ну это касается также и традиционных shell'ов.


    1. worldmind Автор
      15.11.2018 09:45

      Всё так, но это не значит, что нет шансов на изменение, когда-то легаси начинает отмирать, вот когда-то перл был везде и много чего на нём было написано, где он теперь? Во freebsd например давно из базовой поставки выпилили.


  1. sub31
    14.11.2018 19:45
    -1

    busybox — «is a ...»


  1. sub31
    14.11.2018 20:02
    +1

    Неудобство vi убивается его изучением. Милейший редактор.
    Неудобство sh убивается его изучением.
    Неудобство от милейшей поделки испытаете в режиме восстановления не зная shell и не имея своей поделки под рукой.


    1. tchspprt
      14.11.2018 20:11
      +1

      Тут разные проблемы, вы потеряли причинно-следственную связь.
      Неудобство vi превращается в удобство vi после его изучения. А якобы неудобство sh остаётся якобы неудобством sh в сравнении с якобы удобством Python.


      1. loltrol
        14.11.2018 20:25
        +3

        Абсолютно никакая причинно-следственная связь не избавит нас от факта что sh, bash и компания устарели и являются куском теплой массы. Даже, кто бы мог подумать, PowerShell является более удобной и современной заменой. Ну а то что sh не будет заменен в ближайшее будущее, потому что он уже плотно пустил корни везде (до недавнего времени даже init системы были на баше; хотя ярые противники systemd сейчас будут говорить что раньше было лучше) — это уже совсем другая история.


        1. tchspprt
          14.11.2018 21:05
          -4

          Системди не юниксвейный (хотя у него куча преимуществ, отрицать не буду), инит простой и умещается в кармашек (переносимость ПО даёт возможность более лёгкой миграции сферы деятельности в IoT из SRE или наоборот, в общем универсальный инструмент всегда лучше) а PoSh — это отврат. И вообще… бытует мнение, что лучшим *nix-админом становится BSD-админ. Я не проверял и не разу не трогал фрю, но почему-то верю на слово. А значит… может «трава» действительно «была зеленее»?


      1. KevlarBeaver
        14.11.2018 20:25

        Но ведь нужно сначала изучить питон… ))


        1. tchspprt
          14.11.2018 20:57
          +2

          Считается, что это является более простой задачей относительно изучения баша (если отбрасывать тех ребят, которые с двухтысячного пишут на перле и просто принципиально отметают всё новое — так оно и есть). Хотя для меня питон слишком уж… красивый. Да, наверное он крут тем, что с помощью него можно быстрее всего выразить мысль, но… запрет смешивания табов и пробелов и подобная джавоподобная корпоративщина немного сковывают в рамки.


        1. worldmind Автор
          15.11.2018 09:52
          +1

          Питон изучать намного проще и полезнее, он логичный и применяется очень широко.


          1. gecube
            15.11.2018 09:58

            bash тоже применяется очень широко. Те же пайплайны, инит-скрипты и прочее. Но за пределами этой утилитарщины — нет, bash особо не нужен, в отличие от python. На котором реально можно сложные программные системы создавать.


      1. gecube
        14.11.2018 20:36

        sh универсален. Python — нет. Тем более третий. Вот когда в каждом чайнике и кофеварке будет python — тогда и поговорим.


        1. tchspprt
          14.11.2018 20:49

          Вы не мне это говорите, я на Вашей стороне. :)


      1. sub31
        15.11.2018 04:11

        Python хорош в нормально функционирующей системе где можно сказать, что каждый из отдельных кусочков этого интерпретатора и его библиотек не нуждается в проверке.
        Shell монолитен. Он либо работает, либо не работает. Если не работает шелл, то надо посмотреть в другом режиме или другим экземпляром.
        Мне к сожалению часто попадают системы в которых нет необходимых библиотек для функционирования той или иной прикладной программы. К прикладным я отношу и python, как язык программирования с огромным набором модулей.


  1. Griboks
    14.11.2018 21:51

    Поскольку статья ни о чём, могу только заметить, что питон полностью не подходит на роль командной оболочки.


  1. saipr
    14.11.2018 21:53
    +1

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


  1. Die_Gelassenheit
    14.11.2018 23:31
    +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.»

    Кажется, что это классическое «я не осилил, поэтому придумал свое». Сколько уже фреймворков, языков и библиотек было создано по этой причине.


    1. bogolt
      15.11.2018 01:44

      Особенно если мы говорим о пайпинге. Ведь на баше это `ls | grep abc` а вот на питоне будет морока та еще.


      1. worldmind Автор
        15.11.2018 09:56

        вы путаете shell и unix tools, от второго никто не предлагает отказаться.


        1. gecube
          15.11.2018 09:59

          и зачем они нужны (в python)? subprocess check_call и поехали? А ничего, что там накладные расходы будут даже больше, чем в случае использования шелла напрямую?


          1. worldmind Автор
            15.11.2018 10:01

            не распарсил, поясните мысль


            1. gecube
              15.11.2018 10:03

              Расшифрую.
              Если мы коммитимся на использование python окружения — нам не нужны пайплайнинги, т.к. пайтон на батарейках и умеет почти все из коробки (листинг директорий, поиск текстов и т.п.).
              Если же пытаться использовать сторонние утилиты через вызов subprocess.check_call, то можно задействовать пайплайнинг, но накладные расходы все равно выше, чем при попытке утрамбовать такую конструкцию в однострочник bash. Не говоря уже о зависимостях от внешних бинарей. Либо, если руками собирать pipe, то там столько бойлерплейта будет, что проще вздернуться.


              1. worldmind Автор
                15.11.2018 10:20

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

                import os; os.listdir('.')
                даже если import бужет сделан заранее.
                Не говоря уже о более продвинутых тулзах типа tree если продолжать пример со списокм файлов.


              1. Die_Gelassenheit
                15.11.2018 10:27

                > поиск текстов
                И тут мне вспоминается этот пост: adamdrake.com/command-line-tools-can-be-235x-faster-than-your-hadoop-cluster.html


    1. worldmind Автор
      15.11.2018 09:56

      Но это не означает автоматически, что получилось плохо/хуже.


      1. Die_Gelassenheit
        15.11.2018 10:24
        +1

        Автоматически — нет. Но авторы первым аргументом приводят то, что им они не осилили баш, а не то, что у него есть фундаментальные недостатки, которые они нашли, как исправить. Кажется, что решения в духе «чот там слишком сложно, там же должно быть просто, щас все по-быстрому накидаем» чаще оказываются скорее плохими, чем хорошими.


        1. worldmind Автор
          15.11.2018 10:28
          -1

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


          1. gecube
            15.11.2018 10:32

            Предложите альтернативы.
            Как говорится, «лучше старый проверенный друг, чем два новых».
            И «старый конь борозды не испортит» (в плане того, что все эти bash/unix tools отлажены десятилетиями).


            1. worldmind Автор
              15.11.2018 14:20

              Так сей пост и описывает альтернативу.


              1. gecube
                15.11.2018 16:05
                -1

                Вы сейчас шутите? xonsh — альтернатива?
                А можно что-то нормальное?


                1. worldmind Автор
                  15.11.2018 16:07

                  А что в вашем понимании «нормальное»?


                  1. gecube
                    15.11.2018 16:14

                    Ну, не знаю. Что может стать стандартом де-факто.
                    Например, zsh/fish — еще куда ни шло.

                    /молодцы минусовать, если мнение не нравится. Видимо есть только два мнения -мое и неверное? толерантнее надо быть/


                    1. worldmind Автор
                      15.11.2018 16:47

                      Да тут никого ваше мнение не интересует, может интересовать аргументированная позиция, но пока с аргументами у вас никак.


                      1. iig
                        15.11.2018 17:15

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


                        1. worldmind Автор
                          16.11.2018 09:20

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


                          1. iig
                            16.11.2018 10:13

                            Уродливый синтаксис это дело вкуса. Верблюд ведь красивше лошади? ;)
                            КМК основная задача шелла типа bash — удобно запускать разные другие программы, с этим у него все нормально. А для программирования есть много других языков.


                            1. gecube
                              16.11.2018 11:41

                              Я вообще не понимаю почему нужно менять специализированное решение (shell + unix tools + возможности расширениями утилитами, которые работают через консоль и консольные аргументы) ОБЩИМ решением, которым является python.

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

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

                              А вообще, конечно, вспоминаю себя, когда я пытался в консоли DOS на Spectrum'е ввести 2+2 и мне оболочка говорила, что команда не найдена. Расстройство было жуткое — какие же компьютеры глупые )))) а всего лишь нужно было немного изучить командный язык.


                              1. worldmind Автор
                                16.11.2018 11:54

                                Так никто и не предлагает заменять unix tools, речь только об отказе от шелла как языка программирования автоматизации.


                                1. gecube
                                  16.11.2018 12:19

                                  worldmind просто нужно разделять котлеты и мух. Серьезную автоматизацию — никто на баше и не предлагает делать. Видимо, критерии серьезности у всех свои. Вот те же ETL (работа с БД, обработка данных и пр.) меня не обламывает писать на python, но я готов брать на себя поддержку среды, в которой они выполняются.

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

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

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


  1. immaculate
    15.11.2018 04:52

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


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


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


    1. dr_duke
      16.11.2018 09:17

      PowerShell же.


  1. RumataEstora
    15.11.2018 09:27
    +1

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


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


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


    1. gecube
      15.11.2018 09:40

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


    1. worldmind Автор
      15.11.2018 09:49
      -2

      Аналогично синтаксис Питона ужасен с точки зрения человека, малознакомого с Питоном.

      Как раз на мой взгляд синтаксис питона для незнакомых с ним наиболее понятен


    1. xgbaggins
      16.11.2018 00:06

      >Аналогично синтаксис Питона ужасен с точки зрения человека, малознакомого с Питоном

      Уж лучше питон чем перл


  1. Nitrofen
    15.11.2018 09:34

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


  1. xgbaggins
    16.11.2018 00:17

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

    Заметил только что xonsh иногда призадумывается секунд на 2-3 после долгого простоя — никто не сталкивался с таким явлением, как оно лечится?


    1. worldmind Автор
      16.11.2018 09:22

      В смысле задумывается? Не сразу выезжает консоль? Это скорее не в xonsh дело.


  1. vaniacer
    16.11.2018 13:49

    Баш прекрасен!)
    image