LINUX.ORG.RU

Вышел bash 5.0

 , ,


3

7

Почти через 10 лет после выхода bash 4.0 и чуть больше чем через 2 года после выхода bash 4.4 состоялся релиз пользовательской оболочки и интерпретатора скриптов версии 5.0.

В новой версии:

  • Встроенная команда «wait» теперь ждёт создания замены последнего процесса;
  • Новые переменные $EPOCHSECONDS и $EPOCHREALTIME, которые раскрываются в секунды с начала эпохи Unix с точностью до секунд и с точностью до микросекунд соответственно;
  • Новые загружаемые встроенные команды: rm, stat, fdflags;
  • Новая переменная $BASH_ARGV0, которая раскрывается в $0 и устанавливает $0 в назначение;
  • При передаче числового аргумента readline'овская команда shell-expand-line больше не удаляет кавычки и подавляет замену команды и процесса;
  • Команда «history -d» теперь понимает отрицательные аргументы как сдвиг с конца истории команд;
  • При передаче аргумента «name» команде «coproc» теперь активируется режим раскрытия слов, таким образом уникальные coproc'ы теперь могут быть созданы в циклах;
  • Цикл раскрытия имён из именных ссылок в функциях теперь раскрывает их в имена переменных в глобальной области видимости;
  • У встроенной команды «wait» теперь появилась опция "-f", которая указывает ждать полного завершения процесса вместо изменения его состояния;
  • Теперь появилось определение в файле config-top.h, которое позволяет оболочке в ограниченном режиме переопределять статическое значение $PATH независимо от содержимого при запуске;
  • Теперь замена процессов не наследует опцию «v» в отличие от замены команд;
  • Теперь если оболочка в неинтерактивном режиме с включенным управлением процессами замечает, что основноц процесс завершился с SIGINT, то ведёт себя как при получении SIGINT;
  • Теперь Posix режим включает единожды запускаемую SIGCHLD ловушку для каждого завершающегося процесса-потомка даже если управление процессами отключено;
  • Новая shopt опция: localvar_inherit; Если она установлена, то локальная переменная наследует значение переменной с таким же именем в ближайшей предшествующей области видимости; Однако, значения переменных несовместимых типов (например, индексированный массив вместо ассоциативного массива) наследоваться не будут;
  • «bind -r» теперь проверяет связана ли указанная последовательность прежде чем связать её с NULL'ом во избежание создания раскладок для многоклавишных последовательностей;
  • Числовой аргумент для команды «operate-and-get-next» теперь указывает какую строку из истории команд нужно редактировать;
  • Позиционные параметры теперь определяются до запуска стартовых файлов, а потому в них теперь стало можно использовать $@;
  • Появилась новая опция, которая доступна на этапе компилирования, которая позволяет отключить проверку того, чтобы наследованная $OLDPWD была директорией;
  • Встроенная команда «history» теперь может удалять диапазоны команд из истории через "-d начало-конец";
  • Встроенная привязываемая команда «vi-edit-and-execute-command» теперь переводит readline обратно в режим вставки vi после выполнения команд из редактируемого файла;
  • Дополнение команд теперь учитывает соответствия алиасам и именам функций оболочки без учёта регистра если установлена переменная completion-ignore-case;
  • Новая опция оболочки «assoc_expand_once», которая включает попытку раскрытия индексов ассоциативных массивов только единожды;
  • Теперь оболочка устанавливает $BASH_ARGV и $BASH_ARGC при запуске только при включенном расширенном отладочном режиме, в то время как раньше они устанавливались независимо от дополнительных условий;
  • Встроенная команда «umask» теперь позволяет указывать режимы и маски больше чем восьмеричное 777;
  • Встроенная команда «times» теперь учитывает локаль при выводе разделителя между целой и дробной частями десятичного числа;
  • В наличии новая, отключенная по умолчанию и незадокументированная опция оболочки, которая позволяет включать и отключать отправку истории команд syslog'у во время их выполнения;
  • Больше нельзя определять переменные перед специальными встроенными командами, которые изменяют атрибуты переменных, а затем возвращают их обратно в исполняемую среду, до тех пор пока уровень совместимости не установлен в 44 или меньше;
  • Теперь можно определять дефолтное значение $HISTSIZE во время компиляции в файле config-top.h;
  • Встроенная команда «complete» теперь принимает опцию "-I", которая указывает что нужно дополнять первое слово в строке;
  • Встроенная в bash malloc() теперь использует mmap() (по возможности) для удовлетворения запросов более чем 128 Кб, таким образом free() теперь может задействовать mfree() для возвращения страниц памяти ядру;
  • Опция «globasciiranges» теперь включена по дефолту и может быть отключена при компиляции;
  • Индексированные и ассоциативные массивы теперь разрешают индексы состоящие исключительно из пробелов;
  • Опция «checkwinsize» теперь включена по дефолту;
  • shopt опции «localvar_unset» и «progcomp_alias» теперь видимы и задокументированы;
  • Обработчик имён сигналов теперь понимает имена от «SIGRTMIN+n» до «SIGRTMAX»;
  • Новая загружаемая встроенная команда seq;
  • Выполнение ловушек теперь учитывает внутренние вызовы «eval»;
  • Переменная $_ теперь не меняется при выполнении форкающей команды;
  • Встроенная команда «kill» теперь принимает такие аргументы как -sSIGNAME и -nSIGNUM даже если соответствующие программы не поддерживают соответствующие сигналы;
  • В Posix режиме теперь включена «shift_verbose» опция;

Новое в библиотеке readline:

  • Неинкрементирующий поиск в vi-режиме ('N', 'n') теперь может искать шаблон оболочки в соответствии со спецификацией Posix (при доступности используется fnmatch());
  • Доступны новые назначаемые команды «next-screen-line» и «previous-screen-line», которые перемещают курсор в тот же самый столбец следующей или предыдущей строки соответственно;
  • Доступны дефолтные привязки клавиш для control-arrow-key комбинаций;
  • Отрицательный аргумент "-N" команды quoted-insert теперь означает вставку следующих N символов используя quoted-insert;
  • Новая публичная функция rl_check_signals(), которая позволяет приложениям отвечать на сигналы, которые ловит readline пока ожидает ввода используя кастомную функцию чтения;
  • Теперь доступна проверка условий относительно версии readline прямо в файле inputrc; Для этого была внедрена своя собственная реализация сравнения: поддерживаемые операторы «равно» и «неравно», строковые переменные могут сравниваться с числами, двоичные переменные должны сравниваться с «on» и «off», имена переменных от операторов отделяются пробелами;
  • Библиотека для раскрытия истории теперь понимает замену команд и процессов, расширенную универсализацию и позволяет появляться им где угодно в словах;
  • Библиотека истории теперь содержит новую переменную, которая разрешает приложенгиям устанавливать начальное состояние закавычивания, таким образом состояние закавычивания может наследоваться от предыдущей строки;
  • Новая публичная функция rl_set_keymap_name() для установки и использования определяемых приложениями имён раскладок;
  • Клавиша «Insert» на цифровом блоке, если доступна, теперь переводит readline в режим перезаписи;

>>> Подробности

★★★★★

Проверено: Shaman007 ()

Ответ на: комментарий от anonymous

Поскольку find может надеяться только на себя, он и делает всё сам. Пока нужная проверка есть в find — тепло и приятно, если нет — боль, регэкспы и текстовые пайпы.

В ПШ пайпы — это не больно, можно легко припайпить Get-Acl. И что-нибудь ещё, например, Get-ADPrincipalGroupMembership. Найди с помощью find файлы, принадлежащие LDAP-пользователям, входящим в группу Accounting, тогда и приходи.

muon ★★★ ()
Ответ на: комментарий от muon

Можешь не отвечать, я знаю, что удаляет он фигово: на нескольких десятках тысяч файлов падает с ошибкой «слишком много аргументов» (sic!)

Он - это павершел ? - https://community.spiceworks.com/topic/2102136-deleting-massive-amounts-of-files

В лине надо что-то сильно не так делать чтобы не получилось.

handbrake ★★★ ()
Ответ на: комментарий от handbrake

навскидку: тыц, тыц

find /path/to/folder -name «filenamestart*» -type f -exec rm -f {} \;

This works but is very slow and constantly fails from running out of memory.

И пошли-поехали костыли с renice, stat, кто-то докатился даже до rsync. Пойди научи их там жить.

muon ★★★ ()
Ответ на: комментарий от muon

Пойди научи их там жить.

Можно подумать, там небожительский контингент, не то что на ЛОР. Справедливости ради, правильное решение там таки дали: замена -exec \; на -exec \+, что уже десятки лет как в POSIX, в отличии от всяких действительно костылей подросткового нигилистического улучшательства типа xargs и прочих parallel

vodz ★★★★ ()
Последнее исправление: vodz (всего исправлений: 2)
Ответ на: комментарий от muon

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

Группы/пользователи LDAP мапятся на системных пользователей/группы через nss(обычно) и тут тоже всё прозрачно. Только надо получить Ай-Ди пользователей и групп. Не удивлюсь что таки-да к году этак 2028 будут запросы типа «creating systemd unit powershell comandlet». responce: New-SystemdUnit, Get-SystemdUnit и бла бла бла.

anonymous ()
Ответ на: комментарий от muon

И пошли-поехали костыли с renice, stat, кто-то докатился даже до rsync. Пойди научи их там жить.

Я не очень понял кто, кого и чего ради собирается учить жить.

Я хотел показать, что проблема удаления значительного количества файлов существует во всех ОС и это не проблема шелла вообще. В лине, она решаема ~десятком способов не покидая шелла, т.к. он лишь средство запуска.

Но павершел, претендуя на нечто большее, обещает решать это сам и не справляется (и это ожидаемо т.к. это маркетинговый, а не технологический инструмент), а когда выпилят cmd с обвязкой чем вообще подобные проблемы решать ? А что делать с Get-AppxPackage | Remove-AppxPackage которые 2-3 раза подряд запускать приходится, потому что с первого не отрабатывают ?

MS много раз доказывала, что для них маркетинг важнее технологий, если бы они не сделали объекты, то чем бы их шелл отличался от юниксового и как можно было бы изолировать обучение специалистов от унифицированного шелла доступного ВЕЗДЕ, кроме десктопов МС и крошечного сегмента их серверов ?

handbrake ★★★ ()
Ответ на: комментарий от vodz

как обычно при таком вызове все интерактивные программы превращаются в неинтерактивные, например, less в cat

Ты действительно ни разу не писал «что-то | less» ?!

DonkeyHot ★★★★★ ()
Ответ на: комментарий от DonkeyHot

Ты действительно ни разу не писал «что-то | less» ?!

less — интерактивный cat, то есть стандартный ввод — сами данные для отображения, потому интерактивность там сделана насильно через открытие /dev/tty. Когда оно невозможно, либо в случае less file | less, получаем cat. Желание glog *.* | rm — должно преобразовать все утилиты, начиная с rm в обязательные интерактивные, то есть сломать саму суть юникса в fork+pipe, что и отличало его от известных на то время ОС в лучшую сторону с возможностью обработки удобным конвеерным способом.

vodz ★★★★ ()
Ответ на: комментарий от anonymous

Get-AppxPackage | Remove-AppxPackage -> Get-AppxPackage | % { Remove-AppxPackage $_ ; Start-Sleep 3 }

Если не сложно, можно расшифровать что тут происходит ? - Судя по выводу моего скрипта, операции идут последовательно и каждая должна возвращать управление по завершению, а тут, если я правильно понимаю добавлен костыль с 3х секундной паузой (т.е. на разных системах может требоваться разное время) означающий что завершения особо не наступает. Можно расшифровать для совсем тупых и не понимающих PS в моем лице что происходит в твоем скрипте ?

handbrake ★★★ ()
Ответ на: комментарий от handbrake

Get-AppxPackage | % { Remove-AppxPackage $_ ; Start-Sleep 3 } Всё что в фигурных скобках - скриптблок. Суть функции, которые тоже на самом деле скриптблоки. В скриптблоке две команды. От первой команды по пайпу передаётся второй, % - Foreach-Object, ну и для каждого объекта исполняем то что в скриптблоке, можно ожидать завершения удаления получив объект характеризующий или олицетворяющий процесс, можно впихнуть костыль в виде таймаута.

anonymous ()
Ответ на: комментарий от vodz

преобразовать все утилиты, начиная с rm в обязательные интерактивные

Серьёзно? Интерактивность «rm-а» включается отдельной кнопкой "-i", ничего там не cломается. Более того, кнопка была бы не нужна - добавь специальную интерактивную прогу «ask», можно sh builtin-ом. И это было бы куда «unixway"нее и вилотрубастее.

Заметь, они разделили stdout/stderr, но не догадались сделать то же с stdin-ом. Понятно, что в эпоху ввода данных через serial терминалы полезность оного неочевидна. Но несиметричненько. А если задуматься про всякие ESC-последовательнсти, и tc*attr-ы, оно всегда было нужно. Не говоря уже про современные графические концы.

DonkeyHot ★★★★★ ()
Ответ на: комментарий от DonkeyHot

$ man xargs

       -n max-args, --max-args=max-args
              Use  at most max-args arguments per command line.  Fewer than max-args arguments will be used if the size (see the -s option) is exceeded, unless the -x option is given, in
              which case xargs will exit.


$ find <path> -type f | xargs -n4 rm


Будет удалять по 4-ре за раз.

WatchCat ★★★★ ()
Последнее исправление: WatchCat (всего исправлений: 1)
Ответ на: комментарий от DonkeyHot

Серьёзно?

Абсолютно.

Интерактивность «rm-а» включается отдельной кнопкой "-i",

Я в курсе.

Более того, кнопка была бы не нужна - добавь специальную интерактивную прогу «ask»,

Не понял, что сейчас то вам это не даёт сделать?

но не догадались сделать то же с stdin-ом.

Ну да конечно... Разделять между чем? stdin и /dev/tty ? И зачем этот геморой нужен 99.9% прог? Только чтобы каждая утилита могла изображать из себя xagrs по вашей прихоти?

А если задуматься про всякие ESC-последовательнсти

Которые возникают от чего? Не от того ли, что «украшательством» занимаются там, где не просят? esc-последовательности не имеют к unix-у никакого прямого отношения, это просто команды управления изначально печатающим устройством, а потом видеотерминалом. Подключи терминал Vt100 к Спектруму и тоже и те же esc-последовательности придётся генерить.

vodz ★★★★ ()
Ответ на: комментарий от anonymous

Всё что в фигурных скобках - скриптблок.

Спасибо.

можно впихнуть костыль в виде таймаута

Не вгугляю причину таймаута, это проблема PS, msi или кого - не в курсе случаем ? Там действительно нужен костыль в виде таймаута или это предположение ? - после железобетонного zypper(apt-get/yum/...) install mc htop vim..., таймаут в таком месте выглядит дикостью...

handbrake ★★★ ()
Ответ на: комментарий от handbrake

Какой-то из приколов винды. Например, ntfs может сказать, что каталог удален и вернуть управление, а на самом деле он ещё есть. Поэтому везде втыкают функции «удалить надёжно», которая в цикле делает stat+sleep...

anonymous ()
Ответ на: комментарий от handbrake

Я предположил что таймаут даст «облегчение». Это эмпирически т.к. выполняясь в среде CLR всё это действо может запускать процедуры удаления опосредованно (что там не знаю т.к. в своём зоопарке юзаем вынь10 корпоративную а там апликух почти нет хотя магазин есть) и два или более запроса на удаление могут переполнять что-то там и костыль в виде таймаута возможно даст облегчение. Ну если у себя буду удалять на раб. станциях это вот всё то начну с таймаута а если вдруг не поможет то буду получать объект с методом удаления и через таймаут проверять статус. Костыль с таймаутом как-то проще выглядит и если работает такое в 98% случаев то на 1.5% проблем можно не обращать внимания при числе рабочих станций до 500.

anonymous ()
Ответ на: комментарий от WatchCat

Будет удалять по 4-ре за раз

Всё равно же качельки — меньше за раз = больше форкекзеков = дольше, больше за раз = больше задержки и память(малосущественно, но есть же) = дольше.

DonkeyHot ★★★★★ ()
Ответ на: комментарий от vodz

что сейчас то вам это не даёт сделать

Сейчас нет смысла - rm не умеет из stdin-а.

зачем этот геморой нужен 99.9% прог

Затем, что каждая «правильная» программа должна уметь принимать данные от других программ. Это автоматически делает *все* интерактивные программы неправильными (включая rm -i — да-нет не являются её данными). Или заставляет их искать обходные маршруты(переоткрытие tty, Xы всякие).

Которые возникают от чего

От того, что мы должны были передавать «данные» и «управление» в одном потоке. Вопрос в том, где мы их должны были разделить взад. Сейчас управление из потока выцепляет кто попало - кто-то ^C заменяет SIGINT-ом, кто-то ESCблабла свистелками, иногда оно добирается до программы как есть, иногда порезано (\r).

Зачем это программе (xargs, например, или той же rm)? Незачем, ей только имена файлов нужны. Иногда их отфильтровывает шел - но только в интерактивном режиме и не всегда. Запусти, например, xargs touch, и кота на клаву, потом столько интересного в каталогах найдёшь... Разве кому-то это нужно?

Не поленились бы, было бы 2 fd - один с данными и только с данными, другой - с мусором, не хошь не ешь. Простые программы остались бы простыми в худшем случае. Интерактивным понадобился бы select/poll из коробки. Большое дело.

DonkeyHot ★★★★★ ()
Ответ на: комментарий от anonymous

Ты думаешь, классический rm -rf * с этим справится?

Знаю что нет. Но шелл не претендует и в архитектуре заложено, что есть как это обойти, PS же альтернатив (если выкинуть cmd с обвязкой) особо не предлагает.

Любопытнее другое, PS по ресурсам вообще должен гораздо больше жрать, соответственно течь, и интересно задавался ли кто вопросом, насколько вообще можно доверять его выхлопу - zypper remove mc top дает предсказуемый результат, Remove-AppxPackage - нет...

handbrake ★★★ ()
Ответ на: комментарий от DonkeyHot

Сейчас нет смысла - rm не умеет из stdin-а.

Ну в этом топике обсуждаем включение rm в виде встроенной команды, а сискол unlink всё равно удаляет по одному. Потому никакой разницы теперь нет, абсолютно не будет никакого выигрыша. Но это только для rm. А для чего-то более сложного, то управление — это зачастую сложный скрипт, вплоть до записей в БД. Потому в универсальном смысле управление в виде аргументов, имени скрипта или параметров для работы с БД выглядит единообразнее. Попробуйте мыслить глобальнее, а не докапываться до rm.

vodz ★★★★ ()
Ответ на: комментарий от anonymous

ПШ не течёт, в паверщели управляемый код

по RCE в неделю в винде всю жизнь находили, а сейчас им вдруг индусов грамотных завезли ?

Memory leaks in a .NET application have always been a programmer's nightmare. https://www.c-sharpcorner.com/UploadFile/shivprasadk/best-practices-no-5-dete...

handbrake ★★★ ()
Ответ на: комментарий от handbrake

Что сказать-то хотел? Что из .net можно аллоцировать unmanaged ресурсы (память и gdi объекты в статье) и не освобождать их и тогда будет утечка памяти? В самом PS проблемы-то где?

anonymous ()
Ответ на: комментарий от handbrake

В винде обычно дотнот патченый и штабильный если система на правильном канале обновлений. Другое дело что из дотнота вызывают и как. Сам повершел это просто один из классов дотнота: System.Management.Automation.PowerShell

Но топик про bash 5.0 да

anonymous ()
Ответ на: комментарий от anonymous

Что сказать-то хотел?

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

Программисты знают что корректная работа обеспечивается, скорее, четным количеством багов, чем их отсутсствием, евангелистам пох какие воздушные колебания производить, они за деньги работают, начиная свою речь «здрасьте, я Вася Пупкин, раньше продвигал оракл, мои контакты на первом слайде», эксплуатанты знают знают об ограничениях инструментов (хотя допустимый %% сбоев в PS для меня дичь), фанатики из-за слепой веры и глупости, контент менеджеры для поддержания посещаемости ресурса, остальные для фана. В свободную минуту гадаю что за ником стоит. :)

Но топик про bash 5.0 да

В который пришли с тотальным преимуществом PS, так почему бы не обсудить как дела не с абстракциями, а реальными проблемами.

handbrake ★★★ ()
Ответ на: комментарий от handbrake

так почему бы не обсудить как дела не с абстракциями, а реальными проблемами

Если начать исправлять «недостатки баша»/«то чего в нём не хватает» то в дальней перспективе скорее всего это будет VM со сборкой мусора, типизацией, объектами и ffi. При этом это уже не будет простой и надёжный системный шелл. Из всего выходит что лучше ничего не трогать.

Хорошо-бы (без срача :) ) перечислить и обозначить реальные проблемы bash как ЯП, шелла

anonymous ()

При этом это уже не будет простой и надёжный системный шелл.

#!/usr/bin/env sh
И наши все железки от чайника до кластера с компами и смартофонами по середине.

Из всего выходит что лучше ничего не трогать.

Почти. Багфиксы безусловно нужны. Но функционал за десятилетия накоплен, unix way позволяет расширяться добавлением утилит, вот только нового по серьезному, за последние 20 лет ничего не появилось... Никсы - это один раз настроил и годами деньги получаешь, увеличивая клиентскую базу на отполированной за десятилетия платформе, пока адепты мс вязнут и теряют деньги в бесконечной гонке, за несуществующей морковкой на удочке в руках евангелиста, сидящего на их же финансовой шее.

handbrake ★★★ ()
Ответ на: комментарий от vodz

в этом топике обсуждаем включение rm в виде встроенной команды

Это недостаточно глобально. Данная часть обсуждения была о другом. Грубо - о появлении rm в find(:а теперь ещё в bash:). Что-то не ладно в униксовом пути.

DonkeyHot ★★★★★ ()
Ответ на: комментарий от DonkeyHot

Данная часть обсуждения была о другом. Грубо - о появлении rm в find(:а теперь ещё в bash:). Что-то не ладно в униксовом пути.

Значить есть какая-то притягательность в удалении... :) Почему — не знаю. Зато я знаю, почему через pipe не делают для всего. Обмен по pipe до появления сети всегда был очень тяжелый, Одно дело один fork, другое дело на одном процессоре и памяти под один процесс гонять через системный буфер с переключением задач данные. Для этого даже был отдельный автоматический PRI с понижением приоритета на 7, чтобы разгрузить систему и ударить по пальцам шибко вумных юзеров.

vodz ★★★★ ()
Последнее исправление: vodz (всего исправлений: 1)
Ответ на: комментарий от vodz

Во-во. Поэтому нормальный подход - вообще ничего не передавать, только указатель на объект. И процесс новый зачастую не нужен - только лишний раз аргументы парсить и динамически либы линковать. И все для того, чтобы один syscall дёрнуть (stat или unlink, например). В общем как и сделано в PS :D Вместо программ где каждый как может придумывает свои аргументы - набор маленьких функций с общим инфраструктурным кодом (который и в рантайме один).

anonymous ()
Ответ на: комментарий от anonymous

нормальный подход не использовать то что отъедает со старта много озу т.к. это дотнот и если необходимо что-то сложное запустить из системного шелла скрипт/программу наперл/питон/jvm_based_lang_by_shebang/scheme получив по пайпу готовый результат при этом не надрывая системную память и не засоряя файловую систему страхоподелиями от микрософта

anonymous ()
Ответ на: комментарий от vodz

Обмен по pipe до появления сети всегда был очень тяжелый, Одно дело один fork, другое дело на одном процессоре и памяти под один процесс гонять через системный буфер с переключением задач данные

Думаю, тебе стоит пересчитать стоимости. Труба всегда дешевлее сети - нет потерь, маршрутизации, и преобразования форматов. И всегда дешевлее обработки аргументов с forkexec-ом - там всего пара memcpy и пара сисколов, а попробуй почитать strace rm.

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

DonkeyHot ★★★★★ ()
Ответ на: комментарий от DonkeyHot

Думаю, тебе стоит пересчитать стоимости.

Вы невнимательно прочли.

Труба всегда дешевлее сети

А я что сказал?

И всегда дешевлее обработки аргументов с forkexec-ом

Вроде и не чатик с вами, отвечаете через полсуток, а прочесть перед ответом не удосуживаетесь. Речь была не о cиcколе, а именно об обмене данными. fork с аргументами - он один, а по трубе идёт обмен с переключением задач туда сюда через системный буфер. Особенно это смешно, когда команда встроенна, но pipe (в отличии от сокета) без fork-а — не работает.

vodz ★★★★ ()
Ответ на: комментарий от vodz

А я что сказал?

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

Договорились, сеть ни при чём.

Я это понял, как «отказ от чтения данных их stdin-а продиктован ресурсоёмкостью оного». Это очевидно не так — именно по причине большей ресурсоёмкости передачи через argv у find-а есть -delete, -exec {} +, | xargs, (+зачем в баше не знаю).

fork с аргументами - он один, а по трубе идёт обмен с переключением задач...

И потребление этого обмена меньше оного через fork+exec. Например, strace rm показывает 10 открытий файлов, 12 чтений(вместе с mmap-ом), в общей сумме - 54 сискола (без fork-а). Безосновательно считая эти операции в среднем такими же дешёвыми, как memcpy, через слабо(8к) буфферизированный stdin/out за это кол-во пролезет 55/2*BUFSIZE/(ARG_MAX-$(env | wc -l)) - минимум в 1.7 раз больше.

Откуда мораль: авторы оптимизировали не ресурс системы, а ресурс дизайнерского мозга.

DonkeyHot ★★★★★ ()
Ответ на: комментарий от DonkeyHot

то очевидно не так — именно по причине большей ресурсоёмкости передачи через argv у find-а есть -delete

Я уже устал разговаривать с человеком, который совершенно невнимательно читает ответы и твердит бездоказательную чушь. Ваш метод glob *.* | rm — обязательно потребует pipe+fork, а exec, если rm не встроена. Если отказаться от этой чуши и делать как обычно, через встроенную rm argv[ * ], то вообще ни pipe, не fork, ни write от вашего glog, ни read от вашего супер-rm — не надо.

И потребление этого обмена меньше оного через fork+exec.

По нынешним временам fork достаточно дёшев. exec вообще к рассматриваему вопросу отношения не имеет, так как нужность exec определяется только встроенностью: есть — не надо, нет — значит вызываем извне. Для pipe — fork обязателен.

vodz ★★★★ ()
Последнее исправление: vodz (всего исправлений: 1)
Ответ на: комментарий от vodz

делать как обычно, через встроенную rm argv[ * ],

Согласен. Если встроить rm в каждую. программу, определяюшую, что нужно удалить. Ах да, для последнего нужно ешё stat встроить, test и expr. Что там следующее? У линукса ешё 330 системных вызовов. Уверенно движемся в сторону повершела(обрастая костылями, в отличии от оного).

обязательно потребует pipe+fork и exec

Конечно. Целых 5 штук. На все 4 миллиарда удалённых файлов. И при этом в своп не полезет, и на слишком много аргументов не пожалуется, в отличии от «rm $(find)».

exec вообще к рассматриваему вопросу отношения не имеет

тут было много нецензурных слов. форки и трубы - бесплатны, на фоне exec. Первые всего лишь распределяют/копируют немножко памяти. Последний - читает и инициализирует кучу кода. Не веришь - найди какой-нибудь толстенный лог и сравни, как изменяются времена выполнения:

tr -d "'" толстенный_лог | #это чтобы xargs не ругался на кавычки
cat | # это повторить "N" >= 0 раз
xargs -n "M" /bin/true
с изменением M и N.

DonkeyHot ★★★★★ ()
Ответ на: комментарий от anonymous

Зокопать его но видимо поздно как и с нинужноД.

О, закопать никогда не поздно! Впрочем, systemd всем уже плешь проел, а про powershell лично я вот сегодня узнал из этого треда.

Croco ()
Ответ на: комментарий от muon

Но как же системы инициализации? или ты сразу пришёл на systemd?

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

Croco ()