Исходное сообщение
"GitHub опубликовал статистику за 2020 год" Отправлено Аноним, 03-Дек-20 22:49
Я думал, будет вариант получше. Там просто написано, что захардкоженный максимум это 256, а не 1000+, да и дефолта в 32 вполне достаточно на самом деле. Можно и без питона, и я даже где-то использовал dd conv=swab,ucase под это дело, но это такая-то грязь. А, кроме того, swab ведь инвертирует только пары байтов, если мне надо инвертировать больше чем пары он этого уже не может. Кроме того, на нечётном числе будет баг. Вроде с этим я и столкнулся. Нет, всё-таки, для чтения файлов баш очень не подходит, максимум на что он способен это служить клеем и всё остальное изврат. Т.е. мне надо написать однострочник на си, который это сделает и вызывать уже его. Да даже если так, половина конструкций обломается из-за IFS и другая половина уже из-за IFS=. Я только недавно узнал (заново открыл?) о конструкции вида for file do и раньше с именами файлов мне было работать сложнее. >что угодно Далеко не что угодно и совсем не как угодно. Проблема ещё и в том, что когда внешних вызовов много, эффективность скрипта снижается весьма значительно и ничего с этим не сделать. В итоге питон оказывается быстрее и эффективнее, поскольку он не спамит процессами. Ещё, например, у меня была задача исправить поломанную кодировку в именах файлов. Обычно, конечно, iconv, но не в с случае с cp932 и cp1252, когда юникод ломается. У питона, кстати, тоже были проблемы, но питон может и работать с любыми байтами без декодирования в локаль и я просто "исправил" их. Я думал свихнуть от жонглирования локалями и кодировками, и всё же нужно передавать так, чтобы баш его не трогал сам. Это было ужасно, питон намного приятней оказался. А ведь задача тоже совершенно элементарная -- поменять кодировку строки из поломанного юникода в корректный юникод. Я выяснил в процессе, что utf8 очень легко сломать и cp1252 вообще похоже не декодируется в utf8 (даже корректный) и только в utf16/utf32, а это дополнительные проблемы.