Удивительно, на на хабре до сих пор нет поста о такой, весьма интересной, замене шеллу как 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)
tchspprt
14.11.2018 19:09+3Основная особенность xonsh в том, что он «магически» угадывает что вы ввели — комманду питона или шелла, и это работает вполне хорошо.
То бишь это Punto Switcher… для боевого оборудования, в котором ТЕОРЕТИЧЕСКИ (!!!) (УТРИРОВАННО И НЕРЕАЛЬНО (!!!)) может сложиться ситуация, при которой моя пайтон-функция rm с аргументами -rf / может восприняться как вызов шелла? Punto Switcher, который может что-то убить? R u kiddin me? Нужно быть самоубийцей, чтобы использовать какую-то динамическую undefinedbehavior-неустойчивую систему без тестирования и дебага на реальных данных!
Годами пытаются закопать незакапываемый шелл… всё тщетно. Годами на хабрах постят знакомства с zsh и IPython в качестве замены якобы неудобного и неприятного стандарта, но IMHO удобнее баша ничего нет и не будет.tchspprt
14.11.2018 19:31+6Ув. минусующий, я по первому гугол-запросу xonsh deleted нашёл github-issue xonsh-репы с названием «rm -rf *; /foo» deletes /foo. Объясни же мне, в чём я неправ? Или тебе нравится использовать своё железо и данные в качестве «подопытного кролика»? Ну поздравляю, у тебя стальные яйца.
firegurafiku
15.11.2018 04:15+1
Думаю, тут неспроста слово «магически» взято в кавычке: ничегоОсновная особенность xonsh в том, что он «магически» угадывает что вы ввели
То бишь это Punto Switcher…
xonsh
не угадывает, а различие между вызовом внешних команд и питоновским кодом однозначно детерминировано грамматикой скриптового языка.
Может сложиться ситуация, при которой моя пайтон-функция rm с аргументами -rf / может восприняться как вызов шелла?
Конкретно такая ситуация сложиться не может. Ваш пример сrm -rf *; /foo
всё же несколько про другое.
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»
То есть я правильно понимаю, что он не может в многопоточность?worldmind Автор
15.11.2018 09:40Да вот непонятно как её измерять, визуально всё работает шустро даже на моих убогих ноутах.
Что подразумевается под «не может многопоточность»?
immaculate
15.11.2018 09:47+1Думаю, что тут дело не в оболочке, а в том, что для проверки того, грязная ветка или нет, надо каждый раз запускать git, который будет оббегать дерево каталогов. Это в любом случае будет очень накладно.
wsf
14.11.2018 19:42+7Все эти 'убийцы шелла' обладают фундаментальным недостатком которого нет у шелла: шелл есть везде, от роутера и умного чайника до распределенного кластера. Вся статья, по сути, набор костылей с целью прикрутить очередного убийцу шелла к системе в которой уже есть шелл. Да, шелл неудобен, он устарел. Но в мире уже имеются сотни миллионов строк написанных на нем, которые прежде чем переписывать на что-то новое, надо запускать и поддерживать. Так что вы убиваете его не с того конца.
tchspprt
14.11.2018 19:55+5Плюсую.
А есть ещё одна проблема — он лучше всех оттестирован и неоф-документирован, и большинство проблем уже решено и решения замечательным образом лежат на стэковерфлоу и подобных ему. И нормальные люди считают это не проблемой, а отсутствием оной. KISS!wsf
15.11.2018 00:40+3Здесь все не так хорошо на самом деле. Проблемы есть и они огромные. Я на шелле пишу уже наверно лет 10 и со временем пришел к мысли что если шелл скрипт разрастается больше чем на 100-300 строк, то это офигенный такой звонок на то чтобы переписать его на чем-то другом, например том-же питоне. Потому что начинают вылезать куча проблем по поддержке и расширению кода. Банально, корректно попарсить входные параметры это целая головная боль. Да, стековерфлоу предлагает кучу вариантов с getopt/getopts/while, но после того как код написан, он выглядит действительно страшно. Как-либо проворачивать данные в шелле это целый ад, ибо требуются сотни грабель с экранированием, кучи проверок, и целые гирлянды из awk/sed/tr и прочих вещей. Каких-либо нормальных структур данных типа тех же списокв/мап шелл не поддерживает, как и форматов, то есть пролетающие json/xml/yaml приходится парсить питоном/jq и еще кучей дополнительных тулов или самописными граблями которые тебя рано или поздно подставляют. Приходится уходить на питон, но там начинается свой головняк с виртуаленвами, пипом и прочими прелестями.
gecube
15.11.2018 00:50+1Полностью согласен, но стоит добавить, что шелл добавляет боли в части разницы между диалектами sh/bash (sh — он типа везде, а bash — не совсем). Еще есть даже разница между разными версиями bash (о, черт!), хотя во всех современных дистрибутивах Линукс он плюс/минус одинаков.
Что еще выморозило: некоторые команды между Linux/MacOS/Win имеют разное поведение. Например, xargs не имеет прекрасного ключа -r при запуске под Mac. А этот ключ, между прочим, позволяет не фильтровать лишний раз ввод. Я представляю себе сколько еще бойлерплейта придется написать, чтобы проверить наличие необходимых фич и сделать переносимый шелл-скрипт.
orion_tvv
15.11.2018 15:53но там начинается свой головняк с виртуаленвами, пипом и прочими прелестями.
Попробуйте pipenv — он облегчает работу, но его правда тоже надо сначала установить
worldmind Автор
15.11.2018 15:56головняк с виртуаленвами, пипом и прочими
Честно говоря я много слышал про какие-то проблемы, но не очень их понимаю, есть pip для тех кто хочет чего-то стандартного и работающего, он умеет и в систему ставить, и в юзера и в виртуальные окружения (что в посте и продемонстрировано), какие проблемы тут у кого возникают?wsf
15.11.2018 17:40Ну например тем, что по дефолту этого нет, соответственно надо писать враппер который готовит окружение, обычно на том же shell :). Так же бывают хитрые ограничения например когда к pip нету доступа, или он через прокси завернут.
worldmind Автор
15.11.2018 17:49Не очень понятно когда такое возможно.
wsf
15.11.2018 18:16Например, в приватном облаке.
worldmind Автор
15.11.2018 18:29вобщем понятнее не стало о какой проблеме речь
wsf
15.11.2018 19:30Конкретный пример: есть код на питоне который обновляется и его по хорошему надо крутить в виртуаленве чтобы отвязать его от конкретной системы, а чтобы крутить его в виртуаленве надо этот виртуаленв поставить, чтобы не ходить и не делать это руками (потому что много разношерстного кода) появляются всякие обертки.
Mingun
14.11.2018 22:35+3Пожалуй самая главная проблема всех этих супер-пупер удобных, мощных, выразительных, и тэ дэ и тэ пэ в том, что эту безумную дыру ничем не заткнуть, буде понадобится. Нет песочницы, кто угодно может подключить себе что угодно и делать что угодно (это кстати и ко многим встраиваемым языкам относится, единственный, где об этом подумали — Lua). Удобство не должно мешать контролю. А то как-то читал статью, где пытались ограничить встраиваемые возможности питона — сколько там дыр, чтоб вылезти из песочницы и импортнуть то, чего импортировать не положено. Прям напоминает бородатую историю со входом в винду через справку
worldmind Автор
15.11.2018 09:45Всё так, но это не значит, что нет шансов на изменение, когда-то легаси начинает отмирать, вот когда-то перл был везде и много чего на нём было написано, где он теперь? Во freebsd например давно из базовой поставки выпилили.
sub31
14.11.2018 20:02+1Неудобство vi убивается его изучением. Милейший редактор.
Неудобство sh убивается его изучением.
Неудобство от милейшей поделки испытаете в режиме восстановления не зная shell и не имея своей поделки под рукой.tchspprt
14.11.2018 20:11+1Тут разные проблемы, вы потеряли причинно-следственную связь.
Неудобство vi превращается в удобство vi после его изучения. Аякобынеудобство sh остаётсяякобынеудобством sh в сравнении сякобыудобством Python.loltrol
14.11.2018 20:25+3Абсолютно никакая причинно-следственная связь не избавит нас от факта что sh, bash и компания устарели и являются куском теплой массы. Даже, кто бы мог подумать, PowerShell является более удобной и современной заменой. Ну а то что sh не будет заменен в ближайшее будущее, потому что он уже плотно пустил корни везде (до недавнего времени даже init системы были на баше; хотя ярые противники systemd сейчас будут говорить что раньше было лучше) — это уже совсем другая история.
tchspprt
14.11.2018 21:05-4Системди не юниксвейный (хотя у него куча преимуществ, отрицать не буду), инит простой и умещается в кармашек (переносимость ПО даёт возможность более лёгкой миграции сферы деятельности в IoT из SRE или наоборот, в общем универсальный инструмент всегда лучше) а PoSh — это отврат. И вообще… бытует мнение, что лучшим *nix-админом становится BSD-админ. Я не проверял и не разу не трогал фрю, но почему-то верю на слово. А значит… может «трава» действительно «была зеленее»?
KevlarBeaver
14.11.2018 20:25Но ведь нужно сначала изучить питон… ))
tchspprt
14.11.2018 20:57+2Считается, что это является более простой задачей относительно изучения баша (если отбрасывать тех ребят, которые с двухтысячного пишут на перле и просто принципиально отметают всё новое — так оно и есть). Хотя для меня питон слишком уж… красивый. Да, наверное он крут тем, что с помощью него можно быстрее всего выразить мысль, но… запрет смешивания табов и пробелов и подобная джавоподобная корпоративщина немного сковывают в рамки.
worldmind Автор
15.11.2018 09:52+1Питон изучать намного проще и полезнее, он логичный и применяется очень широко.
gecube
15.11.2018 09:58bash тоже применяется очень широко. Те же пайплайны, инит-скрипты и прочее. Но за пределами этой утилитарщины — нет, bash особо не нужен, в отличие от python. На котором реально можно сложные программные системы создавать.
sub31
15.11.2018 04:11Python хорош в нормально функционирующей системе где можно сказать, что каждый из отдельных кусочков этого интерпретатора и его библиотек не нуждается в проверке.
Shell монолитен. Он либо работает, либо не работает. Если не работает шелл, то надо посмотреть в другом режиме или другим экземпляром.
Мне к сожалению часто попадают системы в которых нет необходимых библиотек для функционирования той или иной прикладной программы. К прикладным я отношу и python, как язык программирования с огромным набором модулей.
Griboks
14.11.2018 21:51Поскольку статья ни о чём, могу только заметить, что питон полностью не подходит на роль командной оболочки.
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.»
Кажется, что это классическое «я не осилил, поэтому придумал свое». Сколько уже фреймворков, языков и библиотек было создано по этой причине.bogolt
15.11.2018 01:44Особенно если мы говорим о пайпинге. Ведь на баше это `ls | grep abc` а вот на питоне будет морока та еще.
worldmind Автор
15.11.2018 09:56вы путаете shell и unix tools, от второго никто не предлагает отказаться.
gecube
15.11.2018 09:59и зачем они нужны (в python)? subprocess check_call и поехали? А ничего, что там накладные расходы будут даже больше, чем в случае использования шелла напрямую?
worldmind Автор
15.11.2018 10:01не распарсил, поясните мысль
gecube
15.11.2018 10:03Расшифрую.
Если мы коммитимся на использование python окружения — нам не нужны пайплайнинги, т.к. пайтон на батарейках и умеет почти все из коробки (листинг директорий, поиск текстов и т.п.).
Если же пытаться использовать сторонние утилиты через вызов subprocess.check_call, то можно задействовать пайплайнинг, но накладные расходы все равно выше, чем при попытке утрамбовать такую конструкцию в однострочник bash. Не говоря уже о зависимостях от внешних бинарей. Либо, если руками собирать pipe, то там столько бойлерплейта будет, что проще вздернуться.worldmind Автор
15.11.2018 10:20Не согласен, все-таки unix tools это специализированный инструмент, который конечно же удобнее в простых случаях и накладные расходы тут настолько мизерные, что нет смысла их обсуждать, я когда ввожу ls в xonsh не вижу никаких накладных расходов которые бы заставили меня писать
даже если import бужет сделан заранее.import os; os.listdir('.')
Не говоря уже о более продвинутых тулзах типа tree если продолжать пример со списокм файлов.
Die_Gelassenheit
15.11.2018 10:27> поиск текстов
И тут мне вспоминается этот пост: adamdrake.com/command-line-tools-can-be-235x-faster-than-your-hadoop-cluster.html
worldmind Автор
15.11.2018 09:56Но это не означает автоматически, что получилось плохо/хуже.
Die_Gelassenheit
15.11.2018 10:24+1Автоматически — нет. Но авторы первым аргументом приводят то, что им они не осилили баш, а не то, что у него есть фундаментальные недостатки, которые они нашли, как исправить. Кажется, что решения в духе «чот там слишком сложно, там же должно быть просто, щас все по-быстрому накидаем» чаще оказываются скорее плохими, чем хорошими.
worldmind Автор
15.11.2018 10:28-1Ну с моей точки зрения про баш это оправдано, вопрос ведь не в том, что его нельзя осилить, вопрос в том нужно ли тратить усилия на такое уродство?
gecube
15.11.2018 10:32Предложите альтернативы.
Как говорится, «лучше старый проверенный друг, чем два новых».
И «старый конь борозды не испортит» (в плане того, что все эти bash/unix tools отлажены десятилетиями).worldmind Автор
15.11.2018 14:20Так сей пост и описывает альтернативу.
gecube
15.11.2018 16:05-1Вы сейчас шутите? xonsh — альтернатива?
А можно что-то нормальное?worldmind Автор
15.11.2018 16:07А что в вашем понимании «нормальное»?
gecube
15.11.2018 16:14Ну, не знаю. Что может стать стандартом де-факто.
Например, zsh/fish — еще куда ни шло.
/молодцы минусовать, если мнение не нравится. Видимо есть только два мнения -мое и неверное? толерантнее надо быть/worldmind Автор
15.11.2018 16:47Да тут никого ваше мнение не интересует, может интересовать аргументированная позиция, но пока с аргументами у вас никак.
iig
15.11.2018 17:15Кому надоело ездить на работу на лошади — вот наша альтернатива —
питонверблюд. Какую из доальтернативных задач эта альтернатива решает, никто не может внятно обьяснить.worldmind Автор
16.11.2018 09:20Ну если кому-то кажется что с шелом всё нормально, то конечно ему ничего менять не нужно, с моей же точки зрения шелл и его синтаксис это лишняя сущность, лишний, причём с очень уродливым ситнтаксисом, язык, при том, что есть, повсеместно применяемый скриптовый язык с очень хорошо выглядящим синтаксисом.
iig
16.11.2018 10:13Уродливый синтаксис это дело вкуса. Верблюд ведь красивше лошади? ;)
КМК основная задача шелла типа bash — удобно запускать разные другие программы, с этим у него все нормально. А для программирования есть много других языков.gecube
16.11.2018 11:41Я вообще не понимаю почему нужно менять специализированное решение (shell + unix tools + возможности расширениями утилитами, которые работают через консоль и консольные аргументы) ОБЩИМ решением, которым является python.
Возможно, что нужно попытаться поменять мировоззрение и пытаться не засунуть вызовы этих внешних утилит в python (что действительно неудобно), а пользоваться уже существующими примитивами в python. Т.е. примеры:
— хотим получить список файлов и сделать операцию над ними — пользуемся модулем os (listdir и поехало)
— хотим скачать страницу из интернета -пользуем requests или/и urllib
Но фишка в том, что в простых случаях проще дернуть curl, чем писать простыни шаблонного кода на python.
Короче — такое себе.
А вообще, конечно, вспоминаю себя, когда я пытался в консоли DOS на Spectrum'е ввести 2+2 и мне оболочка говорила, что команда не найдена. Расстройство было жуткое — какие же компьютеры глупые )))) а всего лишь нужно было немного изучить командный язык.worldmind Автор
16.11.2018 11:54Так никто и не предлагает заменять unix tools, речь только об отказе от шелла как языка программирования автоматизации.
gecube
16.11.2018 12:19worldmind просто нужно разделять котлеты и мух. Серьезную автоматизацию — никто на баше и не предлагает делать. Видимо, критерии серьезности у всех свои. Вот те же ETL (работа с БД, обработка данных и пр.) меня не обламывает писать на python, но я готов брать на себя поддержку среды, в которой они выполняются.
А условный скрипт запуска сервиса, проверки наличии файла, переконвертации из формата в формат, скачивания сайта рекурсивно и пр. — проще наговнякать на баше.
Нужно подбивать подходящий тулинг.
А самое милое дело — хорошо написанные скрипты на python практически ничем не отличаются от консольных утилит и точно так же интегрируются с другими unix tools (pipelining, коды возврата и пр. пр.). Но как бы есть определенная разница с однострочниками на xonsh
immaculate
15.11.2018 04:52Я использую уже около года fish. Правда сам не могу объяснить почему. Вроде и удобная оболочка, но по некоторым вещам из bash/zsh до сих пор скучаю.
По теме: всегда не понимал bash/zsh. Мне кажется, что и язык и реализация этих оболочек какие-то архаичные и эклектичные. Скрипты на bash/zsh кажутся слепленными из палок и изоленты — чуть тронь в любом месте, и все развалится (часто так и происходит). Я знаю, что на shell писались (возможно, пишутся до сих пор) проекты размером в сотни тысяч строк, но это сущий кошмар в поддержке.
Странно, что до сих пор никто не сделал нормальный shell с нормальным читаемым языком внутри… Fish, мне кажется, ближе всех подошел, но и в нем остаются недостатки, кроме того, он не очень популярен.
RumataEstora
15.11.2018 09:27+1Синтаксис шелла ужасен с точки зрения малознакомого с синтаксисом шелла. Как и любой язык он обладает большими и малыми недостатками.
Аналогично синтаксис Питона ужасен с точки зрения человека, малознакомого с Питоном. Наверняка Питон тоже обладает большими и малыми недостатками. Чего стоит его зависимость алгоритма от количества пробелов.
Более важно, что шелл есть везде, Питон — нет.
gecube
15.11.2018 09:40Все еще хуже. Шелл есть везде, и как выше заметили — монолитен. Он либо работает, либо нет.
Python — он уже есть как минимум двух несовестимых версий. И требует рабочего окружения. А оно запросто может быть или сломано (например, я сталкивался с таким — stackoverflow.com/questions/47197083/python-pip-error-just-after-fresh-install ), или вам нужны модули какой-то определенной версии, которые или не установлены, или НЕ МОГУТ быть установлены в рамках одного, системного окружения.
worldmind Автор
15.11.2018 09:49-2Аналогично синтаксис Питона ужасен с точки зрения человека, малознакомого с Питоном.
Как раз на мой взгляд синтаксис питона для незнакомых с ним наиболее понятен
xgbaggins
16.11.2018 00:06>Аналогично синтаксис Питона ужасен с точки зрения человека, малознакомого с Питоном
Уж лучше питон чем перл
Nitrofen
15.11.2018 09:34а вообще каждая тулза должна юзатся для определенной нужды, и если есть возможность пользоватся одной тулзой с модулями которые позволят выполнять работу для других сред то зачем заменять эту же тулзу? я вот например в баше могу вызвать и повершел и еще кучку всякого разного и спокойно выполнить нужные мне задачки. тоже самое и в повершелке. как бы можно писать что вот вам тулза которая похоронит остальное и она будет крутая, но зачем такое писать не пойму. Если есть гайка и к ней ключ которым ее закручивать то это не значит что болгарка выполнит эту задачу лучше… исправьте если я не прав
xgbaggins
16.11.2018 00:17Пользуюсь xonsh в guake (выездной консоли) — очень удобно, и шелл и калькулятор (мой основной use case питона) всегда под рукой по одному и тому же hot key, можно заранее прогрузить все модули которые часто использую, numpy, pandas и пр.
Заметил только что xonsh иногда призадумывается секунд на 2-3 после долгого простоя — никто не сталкивался с таким явлением, как оно лечится?worldmind Автор
16.11.2018 09:22В смысле задумывается? Не сразу выезжает консоль? Это скорее не в xonsh дело.
IvanNochnoy
А если я хочу выполнить ad-hoc команду в консоли в одну строку, синтаксис Python тоже прекрасен? Кстати, там пайплайн все ещё текстовый, а не объектный?
worldmind Автор
Давайте примеры команды, посмотрим.
KevlarBeaver
Я вообще надеялся в статье увидеть примеры того, как в «стандартных» шеллах всё плохо и как в xonsh всё это исправляет. Цикл — слишком слабенький пример. Пока что то, что Вы описали, больше похоже на сублимацию NIH-синдрома.
IvanNochnoy
Допустим у меня есть каталог с файлами *.xml следующего формата
Я хочу найти все файлы с аттрибутом date > 2015 года и увеличить значение года в этом аттрибуте на 3, после чего записать файл под тем же именем но с добавлением расширения ".new". Вот решение на PowerShell (да, PowerShell кроссплатформенный, если кто не знает). Внимание! Это не скрипт это запись в коммандной строке, типа, сделал и забыл. А как оно на Python? Табы не мешают?
gecube
как бы такая себе задача для шелл-скриптинга, но уверен, что ее можно решить однострочником, возможно привлекая внешние утилиты (типа jq/yq).
На пайтоне тоже решаться должно достаточно легко, но может не в одну строчку — и самое главное, что там с зависимостями? Не придется ли ставить что-то из доп. модулей?
legolegs
Повершелла не знаю, но за лёгкую работу с XML и датами ему зачёт. А вот считать логику трудно. Например, неясно, создаётся ли файл .new если он выходит идентичным оригиналу.
В линуксах я обычно делаю что-то такое:
Плюсы: обработка файлов любого размера с минимум затрат памяти, можно уловить логику даже не знаю awk.
Минусы: xml не валидируется, xml должен быть отформатирован как в примере.
Скорость работы: 25мб/сек на моём некропк.
gecube
Да, кстати, очень вряд ли, что приведенный выше ПаверШелл сниппет будет давить больше, чем 25МБ/сек, т.к. там используется пайпинг.
kvaps
challenge accepted!
sub31
Круто! Цикл for и имена файлов с пробелами.
kvaps
Ну можно на
заменить, там по ходу задачи уже подстроить можно, главное не забывать про кавычки :)
gecube
Цикл for легко заменить на вызов xargs или find. -name
kvaps
кстати bash без проблем имена с пробелами переваривает:
thatsme
Тоже самое для bash:
hapylestat
не, не очень… представляю вашему вниманию ";", ":", "\"
anonymous
Я вам завидую, если вы такое в powershell вбиваете не глядя как однострочник, который еще и без ошибок выполняется и делает то, что было задумано :)
worldmind Автор
С моей точки зрения это как раз скрипт, просто записанный зачем-то в одну строчку.
iig
Единоразовую задачу я бы сделал в 4 прохода, подставляя каждый раз другой год, неправильным однострочником вида
и забыл.
legolegs
Если у вас там 29 февраля где-то было, то оно бы вам о себе потом напомнило.
gecube
А решение на PowerShell выше, по-Вашему, корректно отработает?
Я думаю, что проблема в постановке задачи, т.к. мы не знаем с какой целью делаем +3 года (можно придумать минимум три способа обработки ситуации 29 февраля).