LINUX.ORG.RU

Ищу удобную альтернативу Bash

 , ,


1

3

Навеяно недавними новостями.

Собственно, я ищу примитивный, башеподобный язык для написания скриптов вида: выполнить n команд с парой условий.

Bash и его производные настолько ужасны, что тут даже обсуждать нечего. Легаси в 3-м поколении.

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

# запуск процесса
run(['ls', '-l'])
# получение расширения файла
splitext("text.txt")[1][1:]
# конкатенация путей
join('/home', 'user')
И это с реэкспортом функций, что не канон.

Fish выглядит самым адекватным решением, но работа с переменными просто ужасна. Например создание списка: set -l mylist 1 2 3. Или инкремент счётчика set i (math "$i + 1"). Зато условия пофиксили.

Поэтому ищу или удобный скриптовый язык или либы для питона.

PS: Ещё интересно было бы услышать что в Bash у вас вызывает самую сильную боль. Я бы, например, не отказался бы от встроенной фичи для проверки существования субкоманд, типа require grep

★★★★★

Последнее исправление: RazrFalcon (всего исправлений: 1)

Я бы, например, не отказался бы от встроенной фичи для проверки существования субкоманд, типа require grep

which grep. Не встроенная, но не вижу проблемы.

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

Python слишком многословен, особенно для запуска процессов и работы с путями.

Есть xonsh, в котором нет как минимум первого минуса. В качестве interactive shell непригоден из-за перемешивания порядка stderr и stdout, но для скриптинга я лучше ничего не нашёл.

f1u77y ★★★★
()
Последнее исправление: f1u77y (всего исправлений: 1)
Ответ на: комментарий от f1u77y

which grep. Не встроенная, но не вижу проблемы.

command -v grep (стандарт согл. 1003.1-2008). Хватит советовать говно.

d_a ★★★★★
()
Ответ на: комментарий от f1u77y

А xonsh выглядит действительно вкусно

Aswed ★★★★★
()
Ответ на: комментарий от d_a

говно

А чем оно хуже кроме того, что может быть не установлено (чего я на практике ещё не встречал)?

f1u77y ★★★★
()
Ответ на: комментарий от f1u77y

Например тем что это не shell builtin, след-но, с другими shell builtin, функциями, алиасами она работает никак или через жопу.

d_a ★★★★★
()
Ответ на: комментарий от d_a

работает никак или через жопу

Что это значит? Иначе говоря, в какой конкретно ситуации оно будет менее удобно, чем command -v?

f1u77y ★★★★
()
Ответ на: комментарий от f1u77y

в какой конкретно ситуации оно будет менее удобно, чем command -v?

/usr/bin/git перекрыт одноимённой функцией, для облегчения работы с ключами от ssh. which знает только о /usr/bin/git, command -v знает о функции.

d_a ★★★★★
()
Последнее исправление: d_a (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

Он везде по-разному работает

type, не? bash-only, ну так ты по башу ж вопрос задаешь и внешний which/whereis не подходит...

Pinkbyte ★★★★★
()
Ответ на: комментарий от KennyMinigun

type -t grep. [which — не стандартизирована]

Я не вижу чтобы в стандарте у type был ключ -t. У меня например, его нет.

d_a ★★★★★
()
Ответ на: комментарий от d_a

Ну вот, а надо арийский GNU Bash 4. Например такой:

$ bash --version
GNU bash, version 4.4.19(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

KennyMinigun ★★★★★
()
Последнее исправление: KennyMinigun (всего исправлений: 2)
Ответ на: комментарий от d_a

И type с ключами это настолько же нестандарт, как и which & co.

О каком стандарте речь? GNU Bash — единственный «стандарт» Bash. Тред о Bash.

POSIX Shell — для тех, кто хочет кровавых стражданий чтоб ублажить BDSM *BSD-шников.

И кстати:

$ type type
type is a shell builtin

Т.е. type — базовая функциональность баша в отличии от внешнего which:

$ type which
which is /usr/bin/which

$ dpkg -S $(readlink -e /usr/bin/which) 
debianutils: /bin/which

KennyMinigun ★★★★★
()
Последнее исправление: KennyMinigun (всего исправлений: 3)
Ответ на: комментарий от d_a

POSIX.2: Shell and Utilities.

Ну вот, GNU Bash умеет в такую совместимость.

Стандарты нужны (в большей мере) для обеспечения совместимости между альтернативами. Which имеет альтернативы на разных системах, но стандарта нет. GNU Bash — один. И если в скрипте написано #!/bin/bash (или более милосердно #!/usr/bin/env bash) то значит что не надо пытаться запускать скрипт этими вашими «реализициями» POSIX Shell. Bash == GNU Bash.

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

KennyMinigun ★★★★★
()
Ответ на: комментарий от KennyMinigun

И если в скрипте написано #!/bin/bash [...]

А если ничего не написано и это сорсится из профиля, будучи например частью софтины, то type без ключей сработает, т.к. это настоящий стандарт, а type с ключами нет, так как это воображаемый гнутый "стандарт".

это когда приходят бздуны с плачем «ниработает скрипт» и наотрез отказываются ставить Bash.

А я и не бздун. Но даже на гну/линуксе mksh это просто глоток свежего воздуха после гну/баш.

d_a ★★★★★
()
Ответ на: комментарий от d_a

Но даже на гну/линуксе mksh это просто глоток свежего воздуха после гну/баш.

вроде «process substitution» только планируется, а без него уныло немного

anonymous
()
Ответ на: комментарий от KennyMinigun

моя наибольшая боль в Bash — это когда приходят бздуны с плачем «ниработает скрипт» и наотрез отказываются ставить Bash

Ну если ты пишешь скрипты с претензией на переносимость, то сам понимаешь наверно кто в этой ситуации мудак.

anonymous
()
Ответ на: комментарий от d_a

mksh это просто глоток свежего воздуха после гну/баш.

Вообще-то нет. Переписываешь скрипт под этот ksh и думашь - «ну нафига им были эти понты?».

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Ну если ты пишешь скрипты с претензией на переносимость, то сам понимаешь наверно кто в этой ситуации мудак.

Претендую на переносимость в границах доступности #!/bin/bash. Однако временами приходится страдать с написанием «более переносимых» скриптов. Но только за деньги или серьезные причины. Я даже на работе за такое не берусь просто так.

KennyMinigun ★★★★★
()
Последнее исправление: KennyMinigun (всего исправлений: 1)
Ответ на: комментарий от anonymous

Так правильный вариант только один.

А если кто-то хочет протестировать совместимость which? :) No single truth.

Использование type вместо which/whereis — скорее из раздела «best practices».

KennyMinigun ★★★★★
()
Ответ на: комментарий от RazrFalcon

Bash - это собирательное имя. То есть любой shell.

Не делай так. Bash — это Bash. А shell — это POSIX Shell. (как котлеты и мухи).

Другое дело — Bash популярен, ибо по умолчанию. Но в то же время Bash — надмножество POSIX Shell.

KennyMinigun ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.