Zsh лопнул

Bug reports are not currently being accepted through the SourceForge ticketing tools. The shell is being maintained by various (entirely self-appointed) subscribers to the mailing list,

zsh-workers@zsh.org

so mail about any issues (bug reports, suggestions, complaints…) related to the development of the shell should be sent there. If you want someone to mail you directly, say so. Most patches to zsh appear there first.

Please note when reporting bugs that many exist only on certain architectures, which the developers may not have access to. In this case debugging information, as detailed as possible, is particularly welcome.

какое слово непонятно

Тьюринг полнота же. А как ты хотел.

хоть показал бы что скопипастил, а то может не баг а фича. Вон в bash/sh скопипасти `yes`

чпок

Вон в bash/sh скопипасти yes

жидко набрасываешь. это не встроенная функция, а сторонняя программа, к башу не имеет никакого отношения:

aol@debian:~$ which yes
/usr/bin/yes
aol@debian:~$ ls -la /usr/bin/yes
-rwxr-xr-x 1 root root 39760 Sep 20  2022 /usr/bin/yes
aol@debian:~$

Память съест не yes, а bash.

Ну, ты вчитайся, если получится, в комментарий, на который я ответил. Там говорят, что это проблема присущая только bash/sh.

И эцсамое.. Надуманная какая-то история. Сколько я ядер не перекомпилировал, сколько билдрутов я не собрал, ни один баш не съедал столько памяти, отображая их выхлоп, чтобы его оом того.

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

bash ничего не съест от того что ты ему скажешь запустить какую-то прогу

, ни один баш не съедал столько памяти, отображая их выхлоп,

bash не отображает ничей вывод кроме своего собственного, что ты несёшь?

Ну, ты вчитайся, если получится, в комментарий, на который я ответил.

ты вчитайся

Там говорят, что это проблема присущая только bash/sh.

не говорят

Надуманная какая-то история.

несомненно

ни один баш не съедал столько памяти, отображая их выхлоп, чтобы его оом того.

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

команда в комментарии не отображает выхлоп yes

bash ничего не съест от того что ты ему скажешь запустить какую-то прогу

там написано другое

А причём тут bash? В любой оболочке, если ты будешь в переменную пихать бесконечное количество данных, память со временем кончится.

Видимо, это известная фича zsh начинать подо что-то выжирать память после специфического ввода, даже небольшого. На многопользовательской машине годами видел чьи-то zsh с 100% cpu и гигабайтами rss.

Пару раз сам ловил такое после ввода с клавиатуры русского символа при LC_ALL=en_US.UTF-8: zsh начинает пухнуть и есть cpu, на ctrl-C не реагирует, убивается kill -9.

Где «там»? Очевидно, там где это написано - там врут.

в комментарии анонимуса

обсуждаемая команда не просто запускает программу

А, там не yes а `yes`, не заметил

Мда пришлось reisub делать. Дурацкие 64 бита, позволяют одному процессу всю память сожрать.

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

А ты проверь ))) У меня 64 гига грохало за пару минут. И так что оом приходил и клал всё подряд, кроме баша, что доставляет особое веселье

А вы тему ulimit ещё раскройте, что касательно памяти нифига не работает :)

И так что оом приходил и клал всё подряд, кроме баша

А почему так?

while (1)

?

Так он же не буквы производит, а возвращает EXIT_SUCCESS родительскому процессу?

скопипасти yes

скопипасти

:(){ :|:& };:

:(){ :|:& };:

После этого смартфон ресетился только отключением аккумулятора.

// задумчиво почесали дефолтные ulimit в termux

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

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

Как бэ намекает на происхождение Вселенной: кто-то что-то не распарсил, инфлэйтнулся, и понеслась. OOM пока не случился, ждем.

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

https://interface31.ru/tech_it/2022/09/linux---nachinayushhim-chto-takoe-oom-...

Так вот почему я внезапно для себя свалил на tcsh… (%

Так вот почему я внезапно для себя свалил на tcsh… (%

Вот вам на немножечько покушать:

https://www.grymoire.com/Unix/CshTop10.txt

So many have decided that since they were using the C shell for their interactive session, why not use it for writing scripts?

Дальше можно не читать. Чувак явно употребляет что-то тяжёлое.

tcsh для интерактива, ash — для скриптов. </thread>

Таки еще немножечько за интерактив в csh:

https://www.grymoire.com/Unix/Csh.html#uh-3

По обоим ссылкам вполне резонные замечания, но всё это относится в первую очередь к скриптованию. Скриптование на (t)csh это не просто боль и страдания, это БОЛЬ И СТРАДАНИЯ. Никто в здравом уме не станет писать скрипты на (t)csh, так как совершенно любой (кроме DOS Batch, лол) инструмент (пусть даже это не скриптовый язык) подойдёт для этой цели лучше, чем (t)csh.

Но в интерактиве tcsh лучше:

• В sh/ash нет комплишнов, совсем. Только дополнения путей. Этого крайне недостаточно.
• В sh/ash нет коллбэков на промпт. Я уже не могу без перекрашивания % в зелёный/красный в зависимости от статуса последней команды.

Про brace expansion прочитай.

А почему не bash?

В sh/ash нет коллбэков на промпт. Я уже не могу без перекрашивания % в зелёный/красный в зависимости от статуса последней команды.

В bash можно, например: export PS1="\$(test \$? -eq 0 && echo green || echo red)% "

В sh/ash нет комплишнов, совсем. Только дополнения путей. Этого крайне недостаточно.

bash дополняет не только пути. Впрочем, сам пользуюсь только ими.

А почему не bash?

А потому что я не линуксоид, очевидно. (=

В bash можно, например: export PS1="\$(test \$? -eq 0 && echo green || echo red)% "

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

bash дополняет не только пути.

tcsh тоже может, успевай только функции алиасы писать для каждого комплишна.

Впрочем, сам пользуюсь только ими.

А я пользуюсь дополнением устройств в dd if/of, дополнением сервисов в service, mount из fstab, zpool, zfs и ещё много всего. И всё это не только аргументы, но и флаги. И да, я задолбался это всё переносить на tcsh. (=

А почему не bash?

А потому что я не линуксоид, очевидно. (=

Юзаю bash из портов на openbsd, портки не жмут.

В bash можно, например: export PS1="$(test $? -eq 0 && echo green || echo red)% "

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

Если не экранировать ‘$’, то один раз. C ‘\$’ отрабатывает перед каждым выводом промпта, как на картинке:

https://ibb.co/B6mNsRW

bash дополняет не только пути.

tcsh тоже может, успевай только функции алиасы писать для каждого комплишна.

Для bash тоже много успели: https://github.com/scop/bash-completion/

^^^ Выше слэши потерялись при цитировании:

export PS1="\$(test \$? -eq 0 && echo green || echo red)% "

Юзаю bash из портов на openbsd, портки не жмут.

После обновления базовой системы FreeBSD, но до обновления пакетов/портов, большинство приложений просто не работают. Так что ставить какой-то левый шелл от какого-то васяна это путь мазохиста. (=

Если не экранировать ‘$’, то один раз. C ‘$’ отрабатывает перед каждым выводом промпта

Как-то не по пацански POSIX.

Для bash тоже много успели

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

В этом случае лучше использовать «type», а не «which».

$ type echo
echo — это встроенная команда bash
$ which echo
/usr/bin/echo

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

В OpenBSD так же, это нормально. Перед sysupgrade делаю pkg_delete всех пакетов, после sysupgrade pkg_add по списку, и все самосборное тоже пересобираю, естественно.

ЗЫ Для root, естественно, всегда /bin/ksh. Для себя bash.

Как-то не по пацански POSIX.

А что POSIX говорит про промпт в sh?

Я бывший гентушник, там Bash безальтернативен был

Неужто других шеллов не было в portage?

В OpenBSD так же, это нормально. Перед sysupgrade делаю pkg_delete всех пакетов, после sysupgrade pkg_add по списку, и все самосборное тоже пересобираю, естественно.

У меня скрипт, который обновляет базу и пакеты. С ZFS Boot Environment это делается практически без даунтайма. Если после ребута что-то пошло не так, просто ребутаемся в старый релиз со старыми пакетами.

ЗЫ Для root, естественно, всегда /bin/ksh. Для себя bash.

У меня конфиг tcsh просто симлинком в /root из /usr/home/mord0d. Хоть FreeBSD давно перешли на /bin/sh по умолчанию, у меня остался старый дефолт с /bin/csh.

А что POSIX говорит про промпт в sh?

Конкретно про промпт — ничего. А назначение переменных вполне однозначно должно срабатывать один раз, при исполнении конфига шеллом, потому что фактически это скрипт.

Неужто других шеллов не было в portage?

Есть, но если поменять руту шелл, портаж ломается. Где-то в документации даже написано предупреждение, что этого делать не сто́ит. (=

Но то Linux, там Bash это де-факто стандарт.

/bin/ksh

Кстати, чем не устроил дефолтный ksh?
// Я всё собираюсь его потыкать, всё никак лапки не доходят.

У меня скрипт, который обновляет базу и пакеты. С ZFS Boot Environment это делается практически без даунтайма. Если после ребута что-то пошло не так, просто ребутаемся в старый релиз со старыми пакетами.

Сложновато как-то. Можно просто два экземпляра фс (кроме /home и т.д.) иметь на двух разделах. Обновили первый, если все нормально, синхронизируем второй с первого. Если обновление что-то сломало, то синхронизируем обратно первый со второго.

Хоть FreeBSD давно перешли на /bin/sh по умолчанию, у меня остался старый дефолт с /bin/csh.

Вон оно что. Думал, что только у Sun был csh по дефолту.

что POSIX говорит про промпт в sh?

Конкретно про промпт — ничего. А назначение переменных вполне однозначно должно срабатывать один раз, при исполнении конфига шеллом, потому что фактически это скрипт.

На содержимое переменной можно делать eval, это ничему не противоречит. Если кто засунул в .bashrc что-то типа export PS1=‘$( bash )’ – ССЗБ.

… если поменять руту шелл, портаж ломается. … Но то Linux, там Bash это де-факто стандарт.

Не факт. В Debian, насколько помню, /bin/sh не bash.

Кстати, чем не устроил дефолтный ksh?

В принципе, ksh устраивает с set -o emacs. Когда мигрировал на x86, первой системой был ALT Linux с bash, привычки оттуда.

Можно просто два экземпляра фс (кроме /home и т.д.) иметь на двух разделах. Обновили первый, если все нормально, синхронизируем второй с первого. Если обновление что-то сломало, то синхронизируем обратно первый со второго.

Вот это "сложноватее". (= Но да, без ZFS только так и придётся делать. Насколько я помню, в OpenBSD UFS не умеет ни снапшотов, ничего такого?

Думал, что только у Sun был csh по дефолту.

Сейчас, наверное, csh по дефолту уже нигде не встретить. В принципе логично.

На содержимое переменной можно делать eval, это ничему не противоречит.

Только вручную, потому что в sh/ash нет хуков. Совсем. Никаких. )=

Если кто засунул в .bashrc что-то типа export PS1=‘$( bash )’ – ССЗБ.

Ой, каких я только наркоманов не встречал. Это с учётом того, что я понимаю что и сам упорот. (=

… если поменять руту шелл, портаж ломается. … Но то Linux, там Bash это де-факто стандарт.

Не факт.

Ну да, от дистра зависит, но в среднем по больнице Bash это дефолтный шелл в большинстве дистров. Не считая всяких огрызков минималистичных, cloud-вариаций и прочего.

В Debian, насколько помню, /bin/sh не bash.

Да, там тоже ash, но он сильно отличается от ash во FreeBSD.

У меня в виртуалке крутится Debian (для Stable Diffusion нужно много ставить из pip, и не всё из этого так просто можно собрать на FreeBSD), меня их дебиановский ash выбесил в первые полчаса, поставил bash с комплишнами и забыл. (=

В принципе, ksh устраивает

В нём есть возможность прикрутить комплишны? А хуки?

Насколько я помню, в OpenBSD UFS не умеет ни снапшотов, ничего такого?

Не умеет. Все ручьками. Может, оно и к лучшему.

На содержимое переменной можно делать eval, это ничему не противоречит. Только вручную, потому что в sh/ash нет хуков. Совсем. Никаких. )=

ash маленький, ему много фич не надо.

Да, там тоже ash, но он сильно отличается от ash во FreeBSD.

В Debian, насколько помню, был dash – модифицированный оригинальный ash.

В принципе, ksh устраивает

В нём есть возможность прикрутить комплишны? А хуки?

Хуков по типу башевского PS0 не помню. Completion путей есть, completion аргументов команд прикручивается через set -A complete_{команда}_1 -- {аргумент1} {aргумент2} ...

P.S.^^^ здесь _1 – номер aргумента команды. Можно определить complete_{команда}_2 и т.д.

Добрый вечер

Может, оно и к лучшему.

Не знаю, я многими фичами ZFS пользуюсь, они сильно облегчают жизнь и продлевают аптайм. (=

ash маленький, ему много фич не надо.

Во FreeBSD есть local, навигация по истории в интерактивном режиме и ещё что-то не особо важное.

В Debian, насколько помню, был dash – модифицированный оригинальный ash.

Мне кажется, они его только обгрызли. (=

Хуков по типу башевского PS0 не помню. Completion путей есть, completion аргументов команд прикручивается через set -A complete_{команда}_1 -- {аргумент1} {aргумент2} ...

P.S.^^^ здесь _1 – номер aргумента команды. Можно определить complete_{команда}_2 и т.д.

Уже что-то. И выглядит это не так упорото, как alias в tcsh. (=

… многими фичами ZFS пользуюсь, они сильно облегчают жизнь и продлевают аптайм.

Лучше наоборот: продлевать жизнь и облегчать аптайм.

// По опыту, аптайм уже лет 20 ограничивается художеством электриков. В понедельник ~9 утра характерное время reboot. Реже вечер пятницы. При этом были аптаймы (Linux) больше 1000 суток, особого смысла не вижу. //

Size 129k 123k

Можно сравнить с /bin/sed, /bin/cat и т. д. Все равно в разы меньше /bin/bash.

По опыту, аптайм уже лет 20 ограничивается художеством электриков. В понедельник ~9 утра характерное время reboot. Реже вечер пятницы.

У меня UPS и бензиновый генератор. (=

Можно сравнить с /bin/sed, /bin/cat и т. д.

Я сравнил два шелла. Причём оба имеют общего предка.

Все равно в разы меньше /bin/bash.

Bash можно даже сам с собой сравнить:

☺

У меня UPS и бензиновый генератор.

Генератор не помогает от рубильника между генератором и нагрузкой.

Можно сравнить с /bin/sed, /bin/cat и т. д.

Я сравнил два шелла. Причём оба имеют общего предка.

Как эти шеллы слинкованы? Оба статически, как, например, ksh в OpenBSD?

Далее, sh и sed Тьюринг-полны, т.е., упрощая, позволяют вычислить, что угодно.

Тогда неудивительно, что статически слинкованный минимальный sh не в 10 раз толще статически слинкованного sed, при всех прочих равных.

А вот статически слинкованный bash в разы больше статически слинкованного ash, потому что в код bash напихали фич, которые могут быть зачитаны на языке bash и исполнены самим bash в runtime.

Bash можно даже сам с собой сравнить

Динамически слинкованные bash4 и bash5 отличаются по размеру в ~2 раза. Потому что пихают в coрцы то, что может быть реализовано в runtime.