Код, который мы все пишем...

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

Кому нужны одноразовые поделки под одиночные задачи?

не нужно кодом на баше делиться, оставьте его себе

Там всё захардкожено и заточено под конретную задачу. Зачем это кому-то нужно?

Я вчера парсил данные ссылок со страниц базы википедии питоном для последующего data mining'а. И зачем кому-то это кривое поделие может понадобиться?

Кстати, в результате получилось (без листьев) всего 2 млн. понятий внутри русской википедии. По числу ссылок несколько примеров:

россия			95802
футбол			19637
православие		6521
microsoft windows	3604
linux			2673
сталин			2568
путин			2529
ubuntu			489
debian			383
bash			125

У меня не захардкожено и полно библиотек. Это же стиль программирования индивидуальный: если человек привык писать универсальные вещи, он их и будет писать на любом языке.
Хотя нет, вру, мои вещи работают только под Linux. Но, собственно, и bash - из нормальных widely used enterprise-grade systems только в Linux по дефолту.

Почему?

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

это у кого как - у меня вон один скрипт конфиг для тачпада из ~/.config считывает)
и вообще скрипты затачиваю под широкое применение, чтобы самому потом не переделывать всё

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

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

Хотя, как-то написал разбивку и сложение pdf в удобную для печати последовательность. Даже выложил, хз зачем.

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

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

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

потому что на баше мало кто пишет универсальное.
99% всех скриптов это одноразовые недоскрипты с хардкодом.
а скорость...тут скорее дело в том, что приходится постоянно что-то дёргать в больших кол-вах

Вот ты свои скрипты и выкладывай. Я скрипт из 3 строк «пофиксить кодировку музыки, перегнать в свободные форматы, разбить flac+cue на tracks» не вижу смысла кому-то давать, он пишется за 5 минут.

Когда я открываю написанный коллегой более-менее сложный скрипт на sh/awk/sed, меня охватывает ужас и уныние от всех этих «if [ -x» и я продолжаю писать аналогичные вещи на Ruby.

Есть же commandlinefu и подобные.

А всё что сложнее — либо не универсально (работает только у пейсателя на компьютере), либо дикая нечитаемая каша.

уже сделали

У самого около 15 скриптов, постоянно использую 1-2, остальные были написаны «на один раз» и кроме как мне такое вряд ли нужно кому-то ещё.

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

Раз в полгода где-то проскакивают вроде треды с обменом скриптами... Дальше, думаю, дело вряд ли сдвинется.

А мне кажется, что на Java пишут дикую нечитаемую говнокашу. А код AJAX повергает в состояние «хочу блевать», потому что более отвратительным может быть только brainfuck или erlang в запущенной стадии. Всё зависит от привычки. Тем не менее реально на Shell пишет большинство *nix-админов, и это хорошо.
Кстати, то, что ты назвал кашей, я себе срочно в закладки поместил: офигенная статья!

тут скорее дело в том, что приходится постоянно что-то дёргать в больших кол-вах

К сожалению, это не подтверждается практикой: нативный код на BASH работает медленнее, чем тоже самое, но с использованием sed'ов и grep'ов. В связи с этим складывается ощущение, что сам BASH написан с точки зрения оптимизации скорости написан наихудшим образом из всех возможных.

$ man bash | grep -A 1 BUGS
BUGS
       It's too big and too slow.

Судя по тому, что эта надпись тут уже не знаю сколько висит, фиксить это никто не собирается.

Сперва её просто забыли убрать, а потом оставили чисто для юмора.

Вроде соответствует действительности, зачем убирать?

нативный код на BASH работает медленнее, чем тоже самое, но с использованием sed'ов и grep'ов.

4.2
вот только что попробовал заменить

[[ "${1}" == *:* ]]

grep -q ":" <<< "${1}"

А ты уверен, что это тормозит grep/sed/..., а не его вызов из bash-а?

уверен - сейчас дождусь завершения цикла в 1000000 проходов и покажу циферки
да, если я ошибаюсь - как проверить?

Взять массив данных побольше, чтобы он обрабатывался достаточный период времени за один вызов grep/sed. Вывод пускать в /dev/null, а не в файл или консоль.

сотни полезняшек не помешают

уж до этого я и сам догадался.
это всё?

Вот, последнее, что писал. Вчера.

#!/bin/bash

for i in `seq 0 340`; do
	echo -n $i: I
	sudo mysql AB_FORUMS -e "insert ignore into posts_cache (id,body,body_ts) (select post_id, html, cached_modify_time from posts_cached_fields d \
		inner join posts p on p.id = d.post_id left join posts_cache c on c.id = d.post_id where post_id >= ${i}0000 and post_id <= ${i}9999 and body is null)"
	echo -n "."
	sleep 5
	echo -n "U"
	sudo mysql AB_FORUMS -e "update posts_cache c inner join posts_cached_fields d on d.post_id = c.id set c.body = html \
		where post_id >= ${i}0000 and post_id <= ${i}9999 and body is null;"
	echo -n "."
	sleep 5
	echo -n "D"
	sudo mysql AB_FORUMS -e "UPDATE posts_cached_fields d inner join posts_cache c on c.id = d.post_id \
		set d.html = NULL
		where d.post_id >= ${i}0000 and post_id <= ${i}9999\
		and d.html = c.body;"
	echo "."
	sleep 10
done

Есть с него хоть какая-то практическая польза для общественности? :) Боюсь, 99.9% bash-скриптов именно такие.

миллион ждать устал - вот 1000

[ megabaks@desktop ] ~ $ x(){ [[ "${1}" == *:* ]];}
[ megabaks@desktop ] ~ $ time for i in `seq 1000`;do x lol:lor;done

real    0m0.015s
user    0m0.013s
sys     0m0.002s
[ megabaks@desktop ] ~ $ x(){ grep -q ":" <<< "${1}";}
[ megabaks@desktop ] ~ $ time for i in `seq 1000`;do x lol:lor;done

real    0m4.824s
user    0m1.383s
sys     0m2.857s
[ megabaks@desktop ] ~ $ 

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

Ты попробуй на нормальных regexp'ах, куски из строки подлиннее вычленять. Будешь удивлён :) см. BASH_REMATCH

   if [[ -f "$csvSource" ]]; then    
    csv_row+=$(sed -nr "s%^${lon},\s*${lat},\s*([^,]+),?\s*$%,\1%"'; T lbl; p; q; :lbl; $s%.*%,'$UNDEF'%p' "$csvSource")
   else
    csv_row+=",$UNDEF"
   fi

Вот кусочек реального кода, который с использованием SED работал быстрее, чем с нативным BASH и его regex-движком.

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

нативный код на BASH

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

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

тут ты 1000 раз вызываешь grep. Очевидно, что это очень медленно работает

Попробуй и зацени даже не разницу в работе «сравнивающих скобок», а количество времени, на которое различаются разные варианты. А ведь это каких-то 100000 циклов, не твой миллион!

#!/bin/bash
w4r () {
 echo 'some wait for random accumulation...'
 sleep 0.02
 return 0
}

echo 'Init random...'
for ((i=1; i<10000; i++)); do a=$RANDOM; b=$RANDOM; done
echo 'Begin the simple arithmetic comparisson test'

echo -en '\nQ="[", OP="-gt"'
time { for ((i=1; i<100000; i++)); do a=$RANDOM; b=$RANDOM; [ $a -gt $b ]; done; }
w4r

echo -en '\nQ="[[", OP="-gt"'
time { for ((i=1; i<100000; i++)); do a=$RANDOM; b=$RANDOM; [[ $a -gt $b ]]; done; }
w4r

echo -en '\nQ="[[", OP=">"'
time { for ((i=1; i<100000; i++)); do a=$RANDOM; b=$RANDOM; [[ $a > $b ]]; done; }
w4r

echo -en '\nQ="((", OP=">"; V="$a"'
time { for ((i=1; i<100000; i++)); do a=$RANDOM; b=$RANDOM; (( $a > $b )); done; }
w4r

echo -en '\nQ="((", OP=">"; V="a"'
time { for ((i=1; i<100000; i++)); do a=$RANDOM; b=$RANDOM; (( a > b )); done; }
w4r

echo 'THE END ;)'

аха, потому и говорю, что под одну гребёнку нельзя

Очевидно, что это очень медленно работает

Ага, как и регулярные выражения, как и hash-массивы...

Иными словами, баш работает очень медленно. Но быстрые внешние утилиты, делающие ту же работу, вызываются ещё медленнее, сводя на нет их быстроту.

Это давно придумали и назвали CPAN. Правда, там sh немного не bourne-совместимый, но кого это волнует?

Интересно, а на scheme кто-нибудь скриптики пишет? У них там в доках вроде заявлено про такую возможность.

Когда я открываю написанный коллегой более-менее сложный скрипт на sh/awk/sed, меня охватывает ужас и уныние от всех этих «if [ -x» и я продолжаю писать аналогичные вещи на Ruby.

sh/awk/sed ==> Ruby? Да тебе к доктору надо.

У меня пара поделий на баше предложена всем желающим на сайте. А в основном, конечно, делается всё для единичного применения; ну или для неоднократного применения для решения одной и той же задачи в краткие сроки. К примеру, могу написать парсер для выложенных в вебе статистических данных, сграбить им несколько баз данных и всё — больше он никогда мне не понадобится. Так что, как и с перлом (хотя в меньшей степени), скорость работы мне не очень важна; главное, чтобы быстро написать можно было и получить результат. И обмен результатами деятельности тоже бессмысленный получается.

Угу, а еще добавить в bash арифметику с float. Хоть какую-нибудь.

стоить пнуть посильнее разработчиков того же BASH'а, чтобы они его оптимизировали

займись. предлагаю скрестить его с llvm

Там всё захардкожено и заточено под конретную задачу. Зачем это кому-то нужно?

ну есть же пакетные менеджеры на bash, значит кому-то всё-таки нужно

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