ПОЧЕМУ SH ТАК ПЛОХ

ПОЧЕМУ SH ТАК ПЛОХ

Его проектировали лепили в те времена, когда ещё динозавры были живы.

export $1=$2, потом export $3=$4, export $5=$6, и так далее

Это очень важно! Не сдавайся!

Задача заключается в том, чтобы угадать последовательность? Ставлю на https://oeis.org/A005940, например.

Может надо в eval завернуть?

Ты там shift изобретаешь или что?

А ты хочешь где-то остановиться или соорудить что-то типа замыкания? В bash, кстати, с какой-то версии завезли рекурсивные функции. Возможно, тебе нужны именно они.

Какой набор слов. А во второй части гвозди гнутся при одном лишь виде твоих микроскопов.

В bash есть shift.

Может надо в eval завернуть?

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

желаю, чтобы это работало как export $1=$2

Может как 1=$2, т.е. сдвинуть параметры? Для этого есть shift (им нельзя присваивать), как уже сказали. Совсем новый список параметров устанавливается через set -- ....

ПОЧЕМУ SH ТАК ПЛОХ

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

НИчего лучше еще не придумали.

когда ещё динозавры были живы

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

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_26

«отцы-изобретатели» сделали его ради лулзов, они и подумать не могли что кто-то станет этим пользоваться на серьёзных щах

«отцы-изобретатели» сделали его ради лулзов,

Нет. Тогда было очень тяжелое ограничение 64к на всё про всё. Но стандарт образовался и теперь мы имеем bash на 2 Мб, но и с совместимостью и с расширениями типа ${!var}, что и требуется автору, если б он разрешил не sh 50-летнего стандарта.

я шутил

Что-то похоже на shift было бы, если бы ТС не хотел ″export″. Какой сакральный смысыл в:

export $1 

Собственно, от этого они и вымерли. От смеха при его виде.

Никакого, из чего можно смело заключить, что ТС не хочет export.

желаю, чтобы это работало

Дидам нассать что ты там желаешь, они давно умерли. :3

А если серьёзно, то всё равно нассать как ты желаешь, есть стандарт, читай его и желай как там написано!

но в те времена уже были лишпы, ML, SASL и куча более других языков, например

я подозреваю, что в Bell labs брали на работу исключительно альтернативно одарённых программистов: Unix, C, Bourne Shell …

Нет. Тогда было очень тяжелое ограничение 64к на всё про всё.

в 64к можно уместить гораздо более приличные вещи

а учитывая, что переписать на нормальный язык нельзя - сижу мучаюсь.

кто мешает?

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

Раньше за инклюзивность никто не заморачивался и про проблемы особенных людей никто не думал соответственно. Считали что средний пользователь будет нормисом.

ну не всратее, чем виндовый cmd, там вообще сплошная боль

Бледноглазые просто вовремя поняли, что это тупиковый путь >_>

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

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

Такой фанатизм тоже не лишен недостатков. Внезапно, есть вещи, которые на шелле пишутся быстрее и выглядят лаконичнее, в частности если весь скрипт представляет из себя последовательность вызовов программ с определенными параметрами, редиректами, пайпами и минимальными логическими связками (&&, ||) между ними. Такое даже на perl будет многословнее, если конечно не написать то же самое бэктиков.

Бывают вещи, которые просто нельзя сделать на другом языке, например, если результатом работы скрипта должен быть экспорт переменных в текущую шелл-сессию, или изменение ulimit, или что-то в таком духе. Еще бывает, что шелл входит в условие задачи, например у тебя есть embedded-система, и из скриптовых языков на ней только то, что есть в busybox (awk, конечно, язык замечательный, но только в пределах своей узкой ниши)

С JCL не страдали ещё?

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

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

потому что диды так делали и ты так делай. чё умный самый чтоле?

Ты неправильно ставишь вопрос. Правильный вопрос - почему люди пишут скрипты на sh в 2021 году.

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

Ну так есть же божественный xonsh.

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

Слишком толсто

Об..док твой аипи сломается с перескокиванием на другой пихон , руби , нпм , ноду , а баш в отличии от (хочу версию моднее жтк4 по выше это веслело) не сломается если муда..ки ссылки конечно оригиналов оставят и не изменят имена программ для вызова , но даже и тут чуть чуть подправить если что.

Ты бы уважал людей и написал бы что ты хочешь, чтобы тебя поняли. А то мало ли какую байду ты тут выдал.

pf за что их уважать то упал со стула что ли ? За то что bash фаилы заворачивают в библиотеку которая gedit более не прочитается хотя это обычный текстовый баш

Внезапно, есть вещи, которые на шелле пишутся быстрее

и ломаются так же быстро

и выглядят лаконичнее

только если в однострочнике не больше 3-5 элементов, потом получается «что хотел сказать автор?» с отладкой каждого шага

в частности если весь скрипт представляет из себя последовательность вызовов программ с определенными параметрами, редиректами, пайпами и минимальными логическими связками (&&, ||) между ними.

есть скриптоязыки, в которых «вызовы программ с определёнными параметрами» можно с лёгкостью заменить на гораздо более читабельные (чем посиксоподелия) и консистентные библиотечные функции

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

даже для этого достаточно простого дедовского < ./myprettyenv.bb

Еще бывает, что шелл входит в условие задачи, например у тебя есть embedded-система, и из скриптовых языков на ней только то, что есть в busybox

берём генератор шеллскрипта на нормальном языке, пишет на нормальном языке, транспилим

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

А ты на чём пишешь?

Сейчас везде /bin/sh - симлинк на баш! Ну и зачем тебе эти мучения?

На sh, иногда на bash. Но bash особо ничего не даёт к sh, поэтому стараюсь не увлекаться.

На OpenBSD точно нет. Вроде на ubuntu одно время был dash, не знаю, как сейчас.

sh кстати posix стандарт, на нём стоит писать уже только из-за этого. Многие пишут на csh, вот это мне непонятно, зачем?

и ломаются так же быстро

Бугага

только если в однострочнике не больше 3-5 элементов, потом получается «что хотел сказать автор?» с отладкой каждого шага

Однострочники и скрипты - вещи взаимоисключающие. В скрипте должно быть нормальное форматирование и комментарии.

есть скриптоязыки, в которых «вызовы программ с определёнными параметрами» можно с лёгкостью заменить на гораздо более читабельные (чем посиксоподелия) и консистентные библиотечные функции

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

берём генератор шеллскрипта на нормальном языке, пишет на нормальном языке, транспилим

Гораздо более вменяемый способ - написать шеллскрипт и проверить shellcheck’ом. Так как проверять и отлаживать результат генерации на целевом устройстве все равно придется

Но bash особо ничего не даёт к sh, поэтому стараюсь не увлекаться.

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

sh кстати posix стандарт, на нём стоит писать уже только из-за этого.

Так себе аргумент.

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

Однострочники и скрипты - вещи взаимоисключающие. В скрипте должно быть нормальное форматирование и комментарии.

и нормальный язык

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

ахахаха, у юниксовых программ не может быть явных параметров, оно всё неконсистентное друг с другом и даже, зачастую, само с собой. Например, хелпа к аргументам типичной CLI утилиты может описываться в куче мест: собственно парсер аргументов, man, –help, многочисленные плагины к интерактивным шеллам итдтп.

В библиотечных функциях (нормального языка) у тебя есть докстринги и описания параметров прямо в редакторе.

Гораздо более вменяемый способ - написать шеллскрипт и проверить shellcheck’ом. Так как проверять и отлаживать результат генерации на целевом устройстве все равно придется

генератор пишется, условно говоря, один раз, и его можно просто покрыть тестами любой глубины и сложности, в случае с shellcheck - ты ограничен shellcheck-ом, и тебе всё равно приходится жрать убогий bourne shell каждый раз.

ахахаха, у юниксовых программ не может быть явных параметров, оно всё неконсистентное друг с другом

Понятно, пациент живет в своем манямирке. В реальном мире люди пользуются вполне конкретными программами, и им нужно их автоматизировать их вызов с определенными аргументами. Для чего ты тебе докстринги понадобились, чтобы вызвать cp path1 path2 && make -j4?

Например, хелпа к аргументам типичной CLI утилиты может описываться в куче мест: собственно парсер аргументов, man, –help, многочисленные плагины к интерактивным шеллам итдтп.

Посмотреть ман один раз или искать где-то самодокументирующийся скриптовый модуль для вызова ifconfig? Сложный выбор

В библиотечных функциях (нормального языка) у тебя есть докстринги и описания параметров прямо в редакторе.

А, еще и редактор нужен отдельный для это барахла.

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