Вы ругаетесь на проблемы, которые были в V6 (1975 год) и V7(1979 год)?

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

Не очень удачный пример — конструкция $(...) появилась именно для того, чтобы быть нагляднее и решать конкретно этот случай, когда вам нужно вложить подстановку внутри подстановки, в остальном они равноправны.

Точно так же как $@ появилась чтобы решить проблему с использованием позиционных аргументов в кавычках, собственно. И также как [[ … ]] появился чтобы решиьть прблемы с [ … ]. Но при этом старые, «проблемные» механизмы никуда не делись, и, собственно, узнать о том, как нужно делать «правильно» зачастую неоткуда. Потому что в том же мануале описана разница между `…` и $(…), но вот зачем эта разница нужна — ничего не сказано.

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

Проблема не билд-системе.

Я могу ошибаться, но можно переходить на современные системы типа maven и всех проблем избежать.

Интересная идея. У тебя спрашивают — как пользоватьтся вашим компилатором, а ты и отвечаешь «да никуда не годятся все ваши GNU Make, Ninja и прочие SCONS'ы, если вы хотите возпользоваться нашим чудо-компилятором — то maven и только maven, там всё будет работать».

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

Если брать именно os-related язык, то bash — гораздо лучше чем cmd/powershell и другие подобные языки.

Однако python (если его можно использовать) — ещё лучше!

Не понимаю, с чего вы взяли что нужно $*?

Потому что только так и можно было использовать переменные в V6. Внутри кавычек они не раскрывались, а для передачи аргументов (до 9) нужно было писать $1 $2 $3 $4 $5 $6 $7 $8 $9 — почти как в DOS.

А в V7 вспомнили про то, что в именах файлов бывают пробелы и сделали так, что позиционные аргументы стали раскрываться не только вне кавычек, но и внутри. Но при этом "$*" вместо DOS-стиля "$1" "$2" "$3" "$4" "$5" "$6" "$7" "$8" "$9" — использовать оказалось нельзя, так как все аргументы сливались в кучу. Появился первый костыль — в добавление к простому, понятному, но не всегда работающему $* — сделали ещё и "$@".

Что же касается кавычек, то это и понятно — вы хотите, чтобы встреченные wildcards были раскрыты в вашем скрипте, или во время выполнения команды?

Во время исполнения команды wildcards не раскрываются в Unix.

ВСЕ логично

Нелогично то, что любая задача решается 5-10 способами, причём первые 3-7 самых простых — работают не всегда. Такая, немножко иезуинткая логика: «а вы не забыли, что в именах файлов могут быть пробелы? ага — а тут у нас костылик надо использовать! а про то, что имена файлов могут начинаться с дефиса не забыли? ну как же — ещё один костылик нужен! а про перевод каретки в имени файла? ну как же без 3го костылика-то?»

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

Вдумчивое чтение документации позволяет вам достаточно уверенно решать ребусы, которыми являются bash-скрипты. Но не делает написание этих скриптов простым занятием всё равно.

Простейший пример: $(…) — это всего лишь замена на `…`? И вроде как их пожно просто заменять друг на друга? Да? Но ведь нет:

$ echo "`echo "\\\\"`"
\
echo "$(echo "\\\\")"
\\

«Вдумчивое чтение документации», конечно, обьяснит в чём разница — но логичней всю эту коллекцию костылей не сделает…