по сути builtin commands  и запуск бинарников

Для Арчеводов тоже относительно правдиво

Интересный вопрос: а в каком смысле он безопаснее ?

Тут, наверное, имеется ввиду, то что с опцией set -o posix, любой шелл будет работать так как в стандарте posix написано. Разумеется это верно только для тех оболочек, которые такую опцию ввобще поддерживают

Есть кстати posix man pages, в том числе с мануалом по sh

systemd уже накатан. 😉

А что тебя привело-то в nixos?

Добрый день, есть 2 регулярки

.transferFrom\(.*\);
.transfer\(.*\);

и есть папка с файлами .txt из больше 100k

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

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

grep -l -E -r "\.transferFrom\(.*\);.*\.transfer\(.*\);" --include=*.txt |& tee -a bscresults1.txt - дало 451 результат

grep -l -E -r "\.transfer\(.*\);.*\.transferFrom\(.*\);" --include=*.txt |& tee -a bscresults2.txt - дало 1741 результат

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

главная задача найти имя файла рекурсивно, где условия одновременно выполнятся

спасибо

.transfer?(From).*

решение для нубов — пропусти второй греп через пайп

Емнип, у find параметры --exec можно использовать как условия в зависимости от кода выхода. Что-то в виде пары экзеков, каждый с проверкой на непустую строку грепом своей регуляркой, но это не точно, очень плохо помню. Ну или как выше сказали - grep -R 'regex1'|grep 'regex2'

можно и так и так, но тут хз стоит ли вопрос скорости, потому что есть вариант что первый рекурсивный grep может быть прилично быстрее чем find  --exec grep

Соглашусь - по 2 запуска грепа на файл не бесплатные. Подумал ещё, как можно сделать быстрее, но как-то не надумалось. Интересно, есть ли варианты?

POSIX sh – это набор портабельных фич, которые описаны в стандарте POSIX.
На самом деле не так уж и много шеллов, которые на 100% POSIX sh-совместимые, но использование этих фич гарантирует на 99% кроссплатформенность скриптов :)

Привет dash

Он безопасный в том же смысле, почему более безопасны LTS-версии ядер и дистрибутивов: там довольно ограниченный набор фич, которые нужно реализовать в шелле, и вектор атаки гораздо у́же; меньше добавляют левых фич = меньше шансов добавить shellshock'ов.

dash и busybox ash — это реализации стандарта POSIX sh, да.

вот сейчас побегу на busybox писать, чтобы скрипты на termux для android  были кроссплатформенные для линукса

Ну так то что написано под busybox заработает и в bash. Какие проблемы ?

бесполезная дискуссия, всегда есть устройства, и писать на стандарте очень не удобно