Вышел free-classic-ng 0.0.2.

Затем, что тут не личный сайт этого firkax'а. Тут всё равно кто кого осуждает, тем более что на вкус и цвет товарищей нет.

62.7256851196289

Как же хорошо, что в дебиане этого говна никогда не будет.

Ты недооцениваешь ТСа)))

Я с ним на ЛОРе уже 17 лет, я могу точно сказать, что ни DM ни DD ему в ближайшие полвека не светят.

Я с ним на ЛОРе уже 17 лет

Подмигни два раза, если тебя удерживают насильно

Я ж не Rasputin, который подмигивает.

free-classic-ng.pl

т.е. вместо того, что бы набрать cat /proc/meminfo, ну в крайнем случае обернуть в баш скрипт, вы предлагаете для того что бы узнать сколько свободной памяти запускать перл. А чего не на жабе тогда?

...-season-pass-bundle

Это когда Perl 5 успел стать тяжёлым как Java? Он всегда был легковесным, не случайно его синтаксис во многом похож на Си. Поэтому на нём исторически было написано много юниксовых скриптов, и даже сисадмины учили Perl чтобы писать свои скрипты. И в ВУЗах советовали учить Perl, в т.ч. и мне лично. А Java и JavaScript - нет.

1. Perl
$A=10;print $A;
Отжирает: 7724Kb
2. Bash
A=10;printf «$A\n»;
Отжирает: 1112Kb
Итого: На очень простом коде, разница в потреблении памяти в 7 раз.

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

Что угодно лучше, нежели баш. Даже перл.

Ну, bash обычно и так запущен. Особенно если что-то запускается из командной строки. А там shared библиотеки, все дела.

Теперь больше по сути. Во-первых, сейчас не 1990-е и не 2000-е чтобы экономить мегабайты оперативки на отдельных скриптах. Во-вторых, Perl - это мощный скриптовый язык, и сравнивать его надо с аналогичными языками, такими как Python, Ruby,... и т.д. Где-то потребление ресурсов может быть больше, где-то меньше, но в случае отдельных скриптов это ещё ни о чём не говорит.

Что угодно лучше, нежели баш. Даже перл.

Что значит лучше? Лучше чем?

Чем баш. Очевидно же. В баше плохо абсолютно всё кроме перенаправления потоков ввода-вывода. Соответственно, если нужно просто пару команд из shell скопипастить и схоронить в файлике, баш годится. А для чего-то большего — нет.

Ну, bash обычно и так запущен. Особенно если что-то запускается из командной строки. А там shared библиотеки, все дела.

Во-первых «обычно» понятие сферичное. А во-вторых вы сами и ответили, что оно получается лучше для использования.

Теперь больше по сути. Во-первых, сейчас не 1990-е и не 2000-е чтобы экономить мегабайты оперативки на отдельных скриптах.

Мегабайт + мегабайт вот и вышел гигабайт.

Во-вторых, Perl - это мощный скриптовый язык, и сравнивать его надо с аналогичными языками, такими как Python, Ruby,... и т.д.

Я не сравнивал ЯП, я сравнивал инструменты для решения конкретной задачи.

Соответственно, если нужно просто пару команд из shell скопипастить и схоронить в файлике, баш годится.

Так у ТС это оно и есть.

А для чего-то большего — нет.

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

Так у ТС это оно и есть.

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

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

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

Если же придумать к скрипту удобный интерфейс

ТУЙ или ГУЙ что ли?

с кучей ключиков

И в чем проблема в ключиках?

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

Что не так с проверкой входных значений?

выходных значений

Пример где это требуется. Или возможно я вас не так понял.

нормальными собщениями об ошибках

За нормальные что надо считать?

какой-то нетривиальной логикой

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

ТУЙ или ГУЙ что ли?

Сюда с башем лучше вообще не лезть.

И в чем проблема в ключиках?

Напишите мне скрипт который принимает следующие ключи

-p, --parallel — с параметром целое число от 1 до число ядер минус 1
-s, --silence — флаг, убирающий сообщения об ошибках, программа молча падает с exit -1
-v, --verbose N — напротив, поднимает болтливость. Без флагов сообщает об error, с флагом -v → info, -vv → warning, -vvv → debug. Verbose N — эквивалентная форма, где N — задаёт количество 'v' символов. Если N больше трёх или 'v' слишком много — ошибка. -s и -v — взаимоно исключающи, если упоминаются вместе — ошибка/
-l --log file —  куда писать об ошибках, вместо stderr. Если файл не доступен на запись — снова ошибка. 
-h, --help — выдаёт справку

Логику можно не писать, чисто разбор ключей. Все сообщения об ошибках должны быть осмысленны, т.е. вызвать внешнюю команду и показать её ошибку — не катит.

Я потом покажу как это делается в нормальном языке и мы сравним где проще.

Что не так с проверкой входных значений?

Муторно очень. Собственно, любые статьи на тему оборонительное программирование на баше наводят на мысль, что написать надёжный скрипт можно, но слишком много мороки и борьбы с инструментом.

Пример где это требуется.

Любая функция должна возвращать значение определённого типа. Любая команда должна делать свою задачу. А если что-то пошло не так — сигнализировать об ошибке исключением или специальным значением, чтобы дальше скрипт не молол ерунду, а мог корректно заврешиться, объяснив что и где пошло не так.

За нормальные что надо считать?

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

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

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

ТУЙ или ГУЙ что ли?

Сюда с башем лучше вообще не лезть.

man dialog
man xdialog

Напишите мне скрипт который принимает следующие ключи
-p, --parallel — с параметром целое число от 1 до число ядер минус 1

cores=$(grep 'cpu cores' /proc/cpuinfo | cut -d ' ' -f 3 | sort -u) операцию сравнения надеюсь осилите?

-s, --silence — флаг, убирающий сообщения об ошибках

set -Eeuo pipefail
{
 #your code here
} 2>/dev/null

, программа молча падает с exit -1

trap 'exit -1' ERR
C exit -1 она упадет, но на выходе совсем не -1 exit code будет.

-v, --verbose N — напротив, поднимает болтливость.

Тут уж все в ваших руках.

-l --log file — куда писать об ошибках, вместо stderr. Если файл не доступен на запись — снова ошибка.

Сами додумаетесь на основе описанного выше или разжевать нужно?

-h, --help — выдаёт справку

Это тоже разжевать нужно?

Логику можно не писать, чисто разбор ключей.

while getopts ":v:ht" ARGV; do
 case "$ARGV" in
  "t" )
   SHOWDT=1
  ;;
  "d" )
   REPDATE="$(date +%h\ %_d -d "$OPTARG day")"
  ;;
  "h" )
   echo "Usage $0 [-d<daycount>] [-t]";
   echo -e "\t -t            :show datetime";
   echo -e "\t -d<daycount>  :show one day report";
   echo -e "\t               :sample  $0 -d-2";
   echo -e "\t                        report -2 day from 'now'";
   exit
  ;;
  ":" )
   echo "No argument value for option $OPTARG"
   exit
  ;;
  "?" )
   echo "Unknown option $OPTARG";
   exit
  ;;
 esac
done

Это самый простой вариант для однобуквенных параметров. Для --paramname например так

OPTIONS=$(getopt -n $0 -o d:ht --long day:,help,datetime, -- "$@")
eval set -- "$OPTIONS"

while true ; do
#while getopts ":d:ht" ARGV; do
 case "$1" in
  "-t"|"--datetime" )
   SHOWDT=1
   shift
  ;;
  "-d"|"--day" )
   REPDATE="$(date +%h\ %_d -d "$2 day")"
   shift 2
  ;;
  "-h"|"--help" )
   echo "Usage $0 [-d|--day<daycount>] [-t|--datetime]";
   echo -e "\t -t|--datetime            :show datetime";
   echo -e "\t -d<daycount>             :show one day report";
   echo -e "\t                          :sample  $0 -d-2";
   echo -e "\t                              report -2 day from 'now'";
   exit
  ;;
  ":" )
   echo "No argument value for option $OPTARG"
   exit
  ;;
  "?" )
   echo "Unknown option $OPTARG";
   exit
  ;;
  --) shift ; break ;;
 esac
done

Это тоже разжевать нужно?

А можно не кусочками, а всё сразу готовое?

Что не так с проверкой входных значений?

Муторно очень. Собственно, любые статьи на тему оборонительное программирование на баше наводят на мысль, что написать надёжный скрипт можно, но слишком много мороки и борьбы с инструментом.

Муторно чем?

Любая функция должна возвращать значение определённого типа.

Кому должна?

За нормальные что надо считать?

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

А для «Floating point exception» не надо читать код программы что ли?

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

И солнце ярче и щи кислее... угу.

Т.е. они лучше во всём вообще.

Лучше для чего?

А можно не кусочками, а всё сразу готовое?

Вы не дочитываете сообщение и на середине прочитанного ответ пишите?

Муторно чем?

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

Я вас попросил простую программу написать

Я вам привел два примера, заметить названия параметров на нужные вам и добавить if-ов думаю осилите сами. В том же Ц будут ровно такие же if-ы по условиям. А совсем полное соответствие вашей хотелки вы знаете в каком разделе искать. :)

а вы меня в маны посылаете

В маны я вас послал в ответ на ваше:

Сюда с башем лучше вообще не лезть.

Так что не передергивайте.

В общем, адепт баша

Вот никогда им не был, я вообще не адепт какого-либо ЯП или скриптоты. Хэйтер некоторых ЯП это да, есть такое. Хотя подумал... нет, наверное я и не хэйтер какого-либо ЯП, конкретные реализации да, могу хэйтить.

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