tcl как кроссплатформенная замена bash

Ты конкретно напиши, как будет.

А смысл? Фанатики всё равно будет клепать на мёртвом языке.

Одному либу нужно для обхода дерева каталогов, другому ls -l нечитаемый, подавай портянку. Питонщики как всегда жгут напалмом.

Я понял. Ты не осилил.

ls -l
*.so

Где тут кроссплатформенность?

Для чего-то может быть достаточно такого:

import os
f = open("abc", "w")
f.write("\n".join([x for x in os.listdir() if x.endswith(".so")]))
f.close

Впрочем тут все зависит от того что считать «заменой bash». Замена командной оболочки? Или замена скриптовому языку?

python не подходит для первого, но подходит для второго.

А вот в bash-скриптах имеется куча граблей.

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

А можно чуть большее сложный пример:

ls -l *.so | grep my-file > abc

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

grep my-file

if x.endswith(".so")

Добавь сюда and x.find("my-file") > -1. (но тут всё же ls -1, а не ls -l)

чем в том же баш-скрипте.

Эпичные ошибки в скриптах:

Из недавнего: В Red Hat и Fedora выявлена удалённая root-уязвимость в DHCP-клиенте (root-уязвимость в dhclient: пропущен -r у read)
[bleeding edge][github] rm -rf / ([:||||||:] bumblebee)

+ все скриптописатели периодически забывают вставлять кавычки..

___
Уязвимости в самом Bash:

Уязвимость в bash и множественные уязвимости в APT
Обнаружены новые уязвимости в bash

Например, можно забыть закрыть файл.

и.. это скорее всего не приведет к негативным последствиям - файл будет закрыт по завершению работы скрипта или сборщиком мустора во время выполнения.

Это где его нет?

Где security решили, что он не нужен.

noname бинарь на 10 метров vs текстовый файл на 10 строк

Т.е. у тебя в инфре можно класть любые скрипты и никто не заметит?

https://www.python.org/dev/peps/pep-0471/

Да и лучше на го или хаскелле запилить бинарник, он точно везде будет работать так как надо.
security

/0

Т.е. у тебя в инфре можно класть любые скрипты и никто не заметит?

Я не сисадмин. Но на тех серверах, к которым у меня был доступ, всегда был python 3.

Например, можно забыть закрыть файл.

Если использовать современный питон - нельзя:

import os

with open('abc', 'w') as f:
    f.write("\n".join([x for x in os.listdir() if x.endswith(".so")]))

Если у тебя такие задачи, то тебе уже не Python, тебе xonsh нужен. На нем, кстати, это записывается как ls -l *.so > abc

Посмотри xonsh, там справились.

Например, можно забыть закрыть файл.

Он, кстати, и забыл =D

Он, кстати, и забыл =D

o_O. Не забыл.. Но и не закрыл, да. ()

Ну в 2-3 раза быстрее сделали ок, это я помню. Listdir тоже вполне работал. Всё равно диск тормозить выполнение будет.

надо было менеджер использовать, вот зачем выделывался многострочностью?

Добавь сюда and x.find(«my-file») > -1

Не. Это не конвейер. Конвейер обрабатывает данные по мере поступления. Вместо ls -l может быть «cat 10000Gb-file» или «прочти-безконечные-данные-из-сети-и-напечатай-в-stdout». Конвейер можно ли сделать в Питоне?

Эпичные ошибки в скриптах:

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

и.. это скорее всего не приведет к негативным последствиям

Слушай, ну даже не смешно.

xonsh

А там конвейер настоящий? Есть ли аналог запуска в фоне (&) ?

lovesan, фас!

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

Ты можешь асинхронно сбрасывать данные из гвидобейсика, хоть в
пайп, хоть в сокет, хоть куда.

Палочка создаёт анонимный «пайп», существующий ровно столько, сколько надо. Ты предлагаешь мне вручную создавать эти пайпы, давать им имена, управлять временем их жизни?

Да, да.

Дисков уже нигде нет, только ssd

Поэтому нужно смотреть не на недостатки баша, а на его достоинства.

Это ответ на

питоновом скрипте граблей вряд ли меньше, чем в том же баш-скрипте

Слушай, ну даже не смешно.

Серьезно. Забыть закрыть файл - это скорее «warning», чем «error». Потенциально в некотороых случаех оно может и к реальным проблемам привести. Но не в приведенном примере.

В баше же легко делаются реальные ошибки:

#!/bin/bash
FILE="$1"
FILE_BAK="$FILE.bak"
cp "$FILE" "$FILE_BAK"
# ...
rm -f $FILE_BAK

$ touch foo
$ touch bar
$ touch foo\ bar
$ ./script foo\ bar
$ ls -1 *foo*
'foo bar'
'foo bar.bak'

Не. Это не конвейер. Конвейер обрабатывает данные по мере поступления.

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

Если это cat 10Tb-file - для каких-то задач тебе подойдет построчная обработка файлов. В python есть yield, который в 90% случаях заменит твои пайпы.

Я же тут не пропагандирую баш, а как раз ищу ему замену. Но - хорошую замену.

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

Все мои знакомые win-программисты используют python для того же, для чего я использовал бы bash.

bash сам по себе умеет не так много, его удобство в использовании POSIX-окружение, которое ни коим боком не является «кроссплатформенным».

Для каждой задачи нужно искать подходящее решение в зависимости от выбранного инструмента

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

В python есть yield, который в 90% случаях заменит твои пайпы.

Заменит какой ценой? Писать циклы построчной обработки руками? В баше это не нужно.

Все мои знакомые win-программисты используют python для того же, для чего я использовал бы bash.

Почему не нодку, кстати? В js тоже есть асинхронщина, отношение её к вебу неоспоримо, в отличие от питона, а по скорости она рвёт питон, как тузик грелку, и она уже задействована в разных там webpack-ах.

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

Нет. Тут есть два динамических параметра:

1. инструмент
2. способ решения

Ты рассматриваешь способ решения конкретной задачи на bash (используя пайпы) и хочешь использовать то же самое на python (рассматриваешь вариант).

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

Писать циклы построчной обработки руками?

Что значит «руками»? Есть готовый lazy-генератор построчного чтения.

with open("bigfile") as file:
    for x in file:
        x = x.strip()
        if x.endswith(".so") and x.find("rt") > -1:
            print(x)

Почему не нодку, кстати? ... а по скорости она рвёт питон, как тузик грелку

нодку скорее с PyPi надо сравнивать.

Только Perl, браток. Дух старой школы. Нескучный язык.

нодку скорее с PyPi надо сравнивать.

Так ты мне предлагаешь пользоваться для замены баша Python или PyPi? С тем и надо сравнивать.

Perl проиграл. И мне он концептуально никогда не нравился, уж прости.

Ты рассматриваешь способ решения конкретной задачи на bash (используя пайпы)

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

Так ты мне предлагаешь пользоваться для замены баша Python или PyPi? С тем и надо сравнивать.

Опечатался, имел ввиду PyPy.
python язык, PyPy - реализация python-интерпретатора с JIT-компилятором. В node тоже JIT-компиляция используется.

для замены баша
по скорости

Серьезно?

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

Потому что пайпы - это круто, нужно и полезно.
Инструмент, в котором конвейер записывается в 5 строк

Да, пайпы - это удобно, но..

1. пайпами ты соединяешь обычно ввод вывод сторонних программ. Т.е. тебе нужно окружение (платформа) состоящее из них. Что ты тогда всё же имеешь ввиду под кроссплатформенностью?

2. мы говорим про скрипты, а не про командную оболочку.

___

Пусть есть задача: «на стандартном вводе даны построчно числа, взять из них четные и посчитать их сумму».

Вариант кривого решения на bash через пайпы:

grep -E "[02468]$" | sed 's/$/+/' | tr -d '\n' | sed 's/\+$/\n/' | bc

Вариант на python:

import fileinput
def grep_even(lines):
    for line in lines:
        n = int(line)
        if n % 2 == 0:
            yield n

print(sum(grep_even(fileinput.input())))

Т.е. тебе нужно окружение (платформа) состоящее из них. Что ты тогда всё же имеешь ввиду под кроссплатформенностью?

stdin, stdout и stderr есть у множества переносимых программ. У питона, у нодки, у wget, у git, у make. Т.е. вопрос запустить два питона и склеить их конвейером актуален (удивительно, что это приходится обосновывать - по-моему, это совершенно очевидно должно быть).

мы говорим про скрипты, а не про командную оболочку.

Да, и что?

Вариант на python:

Я не такой уж знаток bash, но на 99% уверен, что в таком стиле можно сделать и на баше. Специально подобранные варианты, для которых конвейер плохо подходит, не обосновывают преимущества Python. Впрочем, мы можем не тратить время - мне уже указали xonsh. Про Python в чистом виде я так понял, что он не годится - отсутствие просто вызываемых конвейеров ну никак не подходит.

С тобой никто не играл. Но что касается философии, то да, нужно иметь доброе и храброе сердце. Не всем дано.

Он проиграл не мне, а другим языкам. Зря ты обиделся. Всё же по сравнению с CL большинство языков выглядят пластмассовыми игрушками. Перл - не исключение. Но CL тоже проиграл и обижаться тут не на кого.

Ты где обиду увидел? Ни в коем разе. У меня стиль размовления такой. Успехов тебе всяческих на пути поиска языка.

Оки. Гранд мерси!