аналог «ps | grep» в студию.

ps w* - найдет процессы, начинающиеся на w. но это понятно предусмотренный вариант работы, если через пайп то будет ps | ? {$_ -match pattern}

конечно, никто не мешает сделать себе grep p = ? {$_ -match pattern}

Я утверждаю, что в типичные для пользовательского шела задачи ближе к «обработай мне то, не знаю что».

Типичные пользовательские задачи вообще неудобно решать в шелле. Их удобно решать тыканьем мышки (конечно, когда разработчик ОС позаботился о наличии нормального интерфейса).

ipython намного лучше. У меня дома он в качестве стандартного шела.

И почему я не удивлён, что слышу это от системдешника.

Если обернуть эквиваленты coreutils в коммандлеты — почему не напишу?

И ты, кажется, не понял, что я для краткости опустил десяток аргументов к find и grep, реализовывать которые на питоне будет крайне неудобно и достаточно проблематично.

Потому что в нормальном скрипто-языке нельзя просто так взять и запустить дочерний процесс или организовать конвейер без бойлерплейта

sorrymak@trisquel ~ $ echo intelfx | perl -e '$_ = `grep -o fx`; print'
fx

В Perl можно. Или я тебя неправильно понял.

Перл уродлив, хотя технически подходит, да.

Действительно, ничего удивительного.

Медленно же.

Учитывая, что всю ту хрень я писал, чтобы перепаковать кучку 7z-архивов zip, то такое замедление не будет заметным, но теперь буду знать, что это «форк».

А ещё твой код ломается на приведённых мною примерах.
FILE=«mydir/-n.txt»

а это ещё что? в смысле, "-n" имя или параметр?

FILE=«mydir/ foo bar.txt»

пробелы в начале имени вообще допустимы?

FILE=$'mydir/foo\n\n\nbar.txt'

ну ты и садюга :)

Работает с любыми именами файлов вообще.

Спасибо, теперь буду знать ещё один способ.

Первоначально у меня была куча каталогов с 7z-архивами, мне нужно было пробежаться по этим каталогом и перепаковать каждый архив в zip-архив, без удаления первого. Ещё поищу как распаковку перенаправлять сразу в zip, впрочем, после распаковки файлы всё равно перемещаются в новый архив. Так уж получилось, что сначала я писал bat'ник, кусок которого был в примере, а потом переписывал его на bash.

Но первоначально пример был приведён в том смысле, что у cmd (у PS скорее всего тоже) для for есть встроенные операции подстановки ссылок из-за чего ссылки на файлы можно обрабатывать используя встроенные средства цикла.

Тогда я тебя напугаю — в Slackware slackpkg и плагин к нему — slackpkg+ — написаны на шелле :)

1) Автодополнение и там работает.

2) Есть бесплатная и по моему даже свободная ide . Вполне приличная.

а это ещё что? в смысле, "-n" имя или параметр?

«Каждому — своё».

user@hostname:~$ mkdir mydir
user@hostname:~$ touch mydir/-n.txt
user@hostname:~$ for FILE in mydir/*.txt; do echo $(TMP=${FILE##*/};echo ${TMP%.*}); done

user@hostname:~$ # где, где он???
user@hostname:~$ for FILE in mydir/*.txt; do echo $(basename "$FILE" .txt); done
user@hostname:~$ # ммм?

пробелы в начале имени вообще допустимы?

Допустима вообще любая последовательность байт, не содержащая / и \0.

Но первоначально пример был приведён в том смысле, что у cmd (у PS скорее всего тоже) для for есть встроенные операции подстановки ссылок из-за чего ссылки на файлы можно обрабатывать используя встроенные средства цикла.

Угу. zsh в этом плане лучше (просто пример, echo там тоже с подводными камнями):

for f in mydir/*.txt; echo $f:t:r

Многие программы работающие с файлами могут воспринимать "-" в начале имени файла как параметр, поэтому не стоит его использовать в начале. Как говорят в таких случаях:«счастливой отладки». В windows проводник в начале имени пробел просто не даст поставить - обрежет, но допускаю, что в linux'овых файловых менеджерах такое возможно. Но я бы в случае обнаружения таких файлов их переименовывал.

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

ps | ? {$_ -match pattern}

О! ? { $ _ } - мусор, и его больше, чем полезной нагрузки почти в 2 раза.

PS: Поскольку, к несчастью, language referrence мне найти не удалось, а, к счастью, винды дома нет, не могу проверить эквивалентность этого кода. Но если он делает то, что «ps | grep» - ПС явные укурки писали.

конечно, никто не мешает сделать себе grep

Мешает ограниченный объём памяти в черепе. Команд и так слишком много.

Их удобно решать тыканьем мышки

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

Предлагаю впилить это вместо баша в мейнстримные дистрибутивы. Серьёзно. В связке с системди будет отличная система для работы.

...ну да.
...как новость, про то что microsoft что-то открыла, так сразу обсуждение на десять страниц и недоумение для чего это?

В арче makepkg и pacaur тоже написаны на шелле, и у меня самого около 5к строк кода околоадминских вещей и прототип сборочной системы написаны на шелле. Но это не отменяет того, что шелл говно для таких задач.

На Баше тоже можно

Нет, нельзя. Сделай-ка мне листинг софтварных рейдов, созданных в системе, без парсинга /proc/mdstat и вызова (с последующим парсингом) mdadm.

В арче makepkg и pacaur тоже написаны на шелле, и у меня самого около 5к строк кода околоадминских вещей и прототип сборочной системы написаны на шелле. Но это не отменяет того, что шелл говно для таких задач.

Тогда зачем ты пишешь прототип сборочной системы на шелле? Мазохист штоле?

Про автодополнение знаю.

Мне powershell не нравится тем, что запускается секунд 10. Понять не могу, че так можно долго запускать.

Мне powershell не нравится тем, что запускается секунд 10. Понять не могу, че так можно долго запускать.

.NET

Ну нихрена вы тут нафлудили за сутки! Хотя для такой новости мало нафлудили. Лор уже не торт.

Английский знаю не особо хорошо, но вроде оно может и вместо ssh работать.

Да у тебя тяжелый случай неосиляторства, оказывается. Ты чего, про PYTHONSTARTUP никогда не слышал? Если это твоя действительно единственная и самая серьёзная претензия к Python, и если бы это было не так, ты использовал бы его как шелл, так сделай себе startup-файл, где к subprocess будут лежать парубуквенные алиасы... в 3.5 с тем, что предлагается вообще всё шикарно.

Я сначала написал прототип, а потом уже понял, что шелл всё-таки говно.

Я не хочу руками писать заменители всех команд из coreutils/util-linux. К тому же это как раз не самая большая претензия, их действительно можно один раз сесть и написать. Гораздо хуже то, что в python нет настолько же выразительных средств работы с файлами, строками и конвейерами, как в шелле.

xonsh уже советовали?

Да, советовали. Посмотрю на него обязательно.

Поддерживаю!

Я когда с powershell'om начал работать боль с лица ушла, когда дело доходило до автоматизации.

И ты, кажется, не понял, что я для краткости опустил десяток аргументов к find и grep

Тебе не нужны никакие грепы, пайпы и прочее говно. Тебе вообще ничего этого в питоне не нужно. Любую задачу можно решить питоновскими средствами: re, filter, map и прочими либами, функции из которых тебе вернут структурированные данные: структуры, списки, словари и проч., с которыми удобно работать.

Сложную задачу проще решить на питоне без awk изврата, а простое — на баше. Простые инструменты для простого, сложные — для сложного. Покажи, какие у тебя там адские скрипты с аргументами, уверен, на пистоне они будут проще и приятнее выглядеть и читаться.

Видел тред на восьми страницах.

А для меня только 4-ая :D

Это еще ничо.

Я его для управления office365 использую. Там запуск секунд 30 и иногда с третьей попытки.

По коментариям сложилось впечатление что главный козырь ps - структурированные данные. а если добавить json ввод/вывод ко всем coreutils и в баш? Не должно быть сложно

Я бы уже давно перешёл на Python или Lua в качестве системного шелла, но я не хочу писать run.me.a.process("...").wait() каждый раз, когда я хочу запустить ссаный греп (и в три раза больше кода, когда я хочу построчно считать и обработать вывод ссаного грепа).

Есть такая штука: http://xon.sh

Я не хочу руками писать заменители всех команд из coreutils/util-linux.

Не знаю как лучше, но я для этого использую plumbum (в связке с ipython). Выглядит так:

from plumbum.cmd import ls, sudo, grep, ... (и так с любой командой в $PATH).

Ага, мне уже дважды её посоветовали. Видимо, действительно стоит попробовать.

Я не хочу руками писать заменители всех команд из coreutils/util-linux

Приведи уже код в студию. Мне даже интересно стало.

закройте это немедленно!

Тупой гуглёж приносит «About 14,700,000 results (0.40 seconds)».

Нет, это тупорылые макаки которые делают rm `find`

Дадада, 40 лет пропихиваем буковки сквозь xargs | perl | awk, натыкаясь на argument list too long

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

Типизированность упрощает многие вещи: там, где в bash-е надо парсить вывод команды каким-нибудь awk-ом и sed-ом, тут достаточно просто обратиться к конкретному полю

Никто не мешает пропихивать через stdin/stdout бинарные данные, в виде упакованных/сериализованных структур. Да хотя бы JSON.

Никто не мешает пропихивать через stdin/stdout бинарные данные, в виде упакованных/сериализованных структур. Да хотя бы JSON.

У объекта кроме полей есть ещё и методы, т.е. надо пропихивать текст полноценных JavaScript-обектов в таком случае. Т.к. текст функций может быть большой, его разумно не пропихивать каждый раз, а хранить где-то в одном месте, а пропихивать только название класса. Помимо этого надо не забыть про то, что может быть несколько версий класса с одним названием. Реализовывать интерпретатор JS в каждой программе глупо, поэтому нужно будет сделать отдельную библиотеку, которая будет реализовывать этот самый JS. Не забыть про безопасность и изоляцию. Так и вырисовывается весь .NET :)

Хотя, конечно, даже просто JSON гонять будет куда лучше текста. Но в любом случае надо писать отдельный язык вместо убогого *sh, нужно писать обёртки ко всем стандартным программам, которые будут адаптировать их к этому sh и уговаривать миллионы людей переходить на этот самый jsonsh. PowerShell уже всё это сделал. Вряд ли у кого-то ещё получится, хотя если тот же Леннарт сделает хорошую альтернативу и RedHat её пропихнёт в качестве стандарта, может и получиться.

и методы

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

xon.sh

В ней все еще не работает ls, если объявить переменную ls?

А это кому нибудь нужно?

Текст это 50-е, 60-е. Структуры это 70-е. А вот полноценный ООП, т.е. структуры + методы + полиморфизм, наследование, инкапсуляция это уже почти 80-е. Если эволюционировать, то побыстрее, не?

PowerShell уже всё это сделал.

Ничего он не сделал из этого. Они просто создали параллельную инфраструктуру. Использовать помершель в качестве шелла невозможно из-за слишком громоздкого синтаксиса, а для написания скриптов чем она лучше пайтона? Команды все по сути свои, те же пайтоновские функции и библиотеки.

Если эволюционировать

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

Программерский мир уходит от объединения кода и данных, удивительно, что существуют еще ооп-макаки, которые пытаются тащить эту несомненно вредную идею.

Это щель, код должен быть коротким и легко скейлиться. Функции и данные легко скейлятся, городить же иерархии объектов в шелл скрипте... Ну удачи.

Кстати, цепочка из >>= в шелл гораздо органичнее бы вписалась, чем ооп лапша. Может, и правда стоит кому-то монадный шелл запилить?

Использовать помершель в качестве шелла невозможно из-за слишком громоздкого синтаксиса

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

для написания скриптов чем она лучше пайтона

Тем, что это специализированный язык. Там проще запускать программы, перенаправлять их, парсить вывод и тд. Т.е. тем же, чем bash, например, лучше пайтона. Насколько это нужно — зависит от скрипта. Если он запускает одну программу и потом на 1000 строчек логики, тогда можно и Python, а ещё лучше что-то вроде Java. Если же весь скрипт состоит из запусков программ и манипуляций с файлами с небольшой примесью логики, на пайтоне это скорее всего будет выглядеть не очень хорошо.