Конвертация .bin команды в .sh

Добавлю ещё: убери /bin/bash, скрипты надо /bin/sh писать.

кому надо? пердоликам-перфекционистам?

Если не используешь специальные фишки, которые предоставляет bash, с #!/bin/sh скрипты будут переносимее от системы к системе.

Добавлю ещё: убери /bin/bash, скрипты надо /bin/sh писать.

Как минимум, это дискуссионный вопрос. Например, в Редхатовых /bin/sh – это алиас на баш с --posix. А в Дебиановых – это dash. Т.е. на двух самых распространенных системах мы получаем уже выполнение на двух разных шеллах. Которые совместимы. Как будто бы.

А баш может и не самый быстрый, но он везде один.

С чего это вдруг надо?

В шебанг (#!) вообще указывается интрепретатор, который должен обработать код, написанный ниже и там может быть любой интерпретатор.

К тому же в bash больше фишек, чем просто в sh. Если в скрипте простой вызов команды с параметрами - можно и sh конечно, а если там скрипт с вызовом функций, прочих особенностей - нужно указывать тот интерпретатор, на котором он написан.

правда, по дефолту он не везде есть

Готов гарантировать это? А что если скрипт написан специально под баш, а /bin/sh ссылается на что-то другое и несовместимое?

Во-первых, «скрипт» автора написан не для баша, он подойдёт к любому шеллу.

Во-вторых, не надо писать скрипты «специально под баш»! Это дурной тон и нубство. Надо ставить /bin/sh и пользоваться только posix-синтаксисом.

Это дурной тон и нубство

С чего вдруг? Если скрипт написан для баша и в шебанге прописан баш, то почему бы и нет?

Надо ставить /bin/sh и пользоваться только posix-синтаксисом.

С чего вдруг?(2) Если в системе всё равно есть баш, то почему бы его не использовать?

нашел с кем спорить

Надо ставить /bin/sh

Кому надо и зачем?

У него там абсолютный путь захардкожен, переносимый ты мой.

Штатный нинужнист лор снова на посту :-)

Ты не поверишь, но можно не только /bin/bash, но даже так:

#!/usr/bin/tcc -run

#include <stdlib.h>

main()
{
  system( "/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -Xmx8G -jar paper-1.13.2-657.jar" );
}

Ужас, правда?

С чего вдруг?(2) Если в системе всё равно есть баш

Только в гну системе, у sh охват шире

Ты ничего не понял. Шебанг с tcc - норм, а вот с башем не норм.

Впрочем использовать его как средство только вызвать одно system() конечно не надо.

Потому что если тебе не хватает posix shell то надо не костылить другие шеллы а переходить на что-то принципиально более нормальное.

Какая нахрен разница, для кастомного-то скрипта для личного использования?

Да, в каком-нибудь пакете для массового распространения, причём софтины которая пердназначена для запуска на всём от роутеров с OpenWrt до серваков с десктопами, /bin/bash может и не лучшая идея. Так же как /usr/bin/python3 или там /usr/bin/ruby, ибо баша с питоном и руби может и не быть на целевой системе, но в ОП речь про конкретный локальный костылик чтобы на данной тачке с данным дистром удобненько пускать команду с кучей специфичных для данного юзкейса аргументов.

Такая что не надо создавать проблемы на ровном месте ради ничего. /bin/sh заведомо переносимый и нет причин организовывать диверсии с неожиданностями.

Такая что не надо создавать проблемы на ровном месте ради ничего. /bin/sh заведомо переносимый и нет причин организовывать диверсии с неожиданностями.

И куда же ОП собирается переносить свой скриптик с захардкоженными путями?

Незачем тратить время на рассуждения «а где будет и не будет запускаться скрипт, а ты точно уверен в этом, а то, а сё на 100 лет вперёд» - это трата времени впустую. Просто используй sh везде и всё. Это несложно.

Просто используй sh везде и всё. Это несложно.

Потому что какой-то мимокрокодил так сказал? Ага, щаз.

переходить на что-то принципиально более нормальное

Например, на баш, да. А я о чём и говорю ;)

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

добавь в .bashrc:

export PATH="/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/:$PATH"

Ты ничего не понял. Шебанг с tcc - норм, а вот с башем не норм.

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

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

Или конкретно тебя воротит от конкретно баша и поэтому ты всех пытаешься с него пересадить на что-то «более нормальное»?

Понятно. Значит ты просто не любишь баш, раз даже пайтон, где ломается совместимость от версии к версии, для тебя лучше баша. Вопросов более не имею :)

А ещё можно стоя и в гамаке. Это несложно.

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

Я уже сталкивался с ситуацией, когда нужна конкретная версия пайтона. Например, когда пользовался дженту, у меня их было аж целых 5! Как тебе такое?

питон, генту… ты неправильно все произносишь

Угу. Именно из-за этого не обновляемый пару месяцев проект просто не запускается.

ты неправильно все произносишь

каждый имеет право заблуждаться, иметь предрассудки в тч фирфокс

И rtx-как-то-там и u5er. И на этом остановимся ;)

А, ну раз мы тут все собрались ради удовлетворения базовых потребностей тса, то тогда ладно

Ну, баш много кто не любит и вполне заслуженно

если бы через докер запускал, где версия указана, то запускался бы.там ломающие обновления были между 3.11 и 3.12 когда типы в другие модули перенесли, а cgi.parse_header просто выбросили

Это надо только старым пердунам и биэсдишникам.

А писать надо #!/usr/bin/env bash|zsh|csh|whatever

А в чём он не прав?

Всё правильно скозал.

Прям ультраправ.

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

Т.е. bash’ем ты не пользовался и шел не понимаешь. Интересно, а это не может быть как-то связано?

Не, он любит си и столярова. И хочет обратно в прошлое, где не было мерсских lvm, docker и прочих непонятных вещей

И правильно делает.

Всё правильно скозал.

Чего? Пользовался конечно - как интерактивным шеллом. Он в отличие от sh умеет редактировать командную строку нормально и историей управляет.

И что значит не понимаю? Понимаю конечно. «Непонятная ерунда» расшифрована дальше в той же цитате была - а именно непонятна его ниша применения. Кодить на нём алгоритмы хоть и можно, но такой код выглядит ужасно и в исходнике, и когда понимаешь сколько лишних действий происходит ради какой-то простой операции. Для этого лучше использовать хотя бы пхп. А шелл годится чтобы запустить по очереди несколько прог, возможно с простым конвеером stdio/stdout/stderr между ними и какими-нить тривиальными условиями вида «файл существует», «программа завершилась успешно» и подобное. Даже поптыки сделать простую арифтметику (expr) или сравнения чисел уже смотрятся крайне убого и, хоть их поддерживает даже posix shell (через внешние проги) - лучше в шелле такое не использовать.

Там культура разработки ломающая. Зависимости в PyPi обновились - и больше ничего не запускается. Докер здесь как протез для генетически больных уродов.

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

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

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

в обход пакетных менеджеров

А других способов в 4/5 случаев не предусмотренно, суровый pip install -r requirements_versions.txt. И не работающий - надо через раз идти в issues чтобы найти как чинить очередное ModuleNotFoundError:. ***** ваш питон и софт на нём.

для таких нужно постоянно писать, что пользуйтесь pyenv/asdf в каждой инструкции

pyenv

Думаешь самый умный? Откуда по твоему я это копировал? На словах всё всегда просто.