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

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

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

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

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

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

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. Пойди научи их там жить.

в случае rm - у него есть еще -i, который превратит разбор потока ввода в ад.

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

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

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

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

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

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

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

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

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

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

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

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

Найди ... и приходи

боль, регэкспы и текстовые пайпы

users=$(getent -s sss group Accounting | cut -d: -f4)
find / -type f '(' -user ${users//,/ -o -user } ')'

Не так уж больно.

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

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

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

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

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

Немного неточно - от первой команды в строке по пайпу на % и от него скриптблок с переданным в него объектом.

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

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

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

... в случае less file | less

Кстати, ssh с таким тоже справляется на ура. Никакой ереси и неподъёмности там нет.

А что find делает хорошо, ищет или удаляет?
Можешь не отвечать

Программа называется find, что по твоему она должна делать хорошо?
Ты считаешь, что удалять?

$ 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

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

Вот ты все 3 пункта и подтвердил.

Серьёзно?

Абсолютно.

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

Я в курсе.

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

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

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

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

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

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

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

Спасибо.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

по 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...

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

ps уже .net не использует?

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

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

Жду в bash 6.0 встроенный nc)

Кстати, баш (baş) с тюркских языков переводится как «голова».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

... почему через 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 раз больше.

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

отвечаете через полсуток

Да, мне ещё работать приходится :)

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

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

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

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

делать как обычно, через встроенную 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

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

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

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

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