Если же вы забыли свой пароль на форуме, то воспользуйтесь данной ссылкой для восстановления пароля.
/*
Сообщения: 88 Благодарности: 5
——- Hasta la victoria siempre!
Конфигурация компьютера
ОС: Linux x86_64
Попробуйте для начала оставить в файле только:
——- Поспешай не торопясь
Сообщения: 88 Благодарности: 5
——- Hasta la victoria siempre!
Сообщения: 88 Благодарности: 5
Источник
Почему «grep *» не работает?
В эти дни, изучая Linux, я нашел что-то, что меня смутило:
«_» это просто курсор, не поймите ошибку 🙂
кто бы это объяснил? Спасибо
4 ответа 4
Глобус * расширяется оболочкой до буквенного списка всех (не точечных) файлов в текущем каталоге. Аргументами grep являются поисковое выражение и список файлов. Таким образом, grep * конечном итоге использует первое имя файла в качестве поискового выражения. Вы ищете имя первого файла (как регулярное выражение) в других файлах.
Grep ищет стандартный ввод только в том случае, если вы не указали явных имен файлов. Увидеть:
Кстати, * не является допустимым регулярным выражением. Как вы обнаружили, пустое поисковое выражение соответствует всем входным строкам. Регулярное выражение , которое соответствует всем непустые строки ввода . ; в регулярном выражении точка — это метасимвол, который соответствует одному символу, любому символу, кроме новой строки. Звезда kleene — это суффиксный оператор, который допускает ноль или более повторений предыдущего регулярного выражения, поэтому вы часто видите регулярное выражение .* Для «что-нибудь вообще», но в этом контексте это избыточно, поскольку вы уже ничего не сопоставляете вообще с пустой строкой поиска.
Наконец, считается плохим тоном cat на одном файле. Вместо cat file | grep «» вы сохраняете процесс и, возможно, немного презираете , когда grep читает файл напрямую; grep «» file
grep * собирается выполнить «глобальное» расширение для файлов в текущем каталоге.
Я не могу точно предсказать, что произойдет, но * наверняка будет соответствовать имени файла abcd . Таким образом, вы можете в конечном итоге искать «abcd» в файле abcd . Или вы можете в конечном итоге искать имя (лексографически) первого файла в других файлах.
Если бы текущий каталог был пуст, вы бы в конечном итоге искали * . Но это также не сработает, потому что первый аргумент командной строки — это регулярное выражение, а «*» не является допустимым регулярным выражением.
Чтобы предотвратить слипание, напишите это:
. но это не имеет смысла по причине, указанной выше.
Для поиска буквального символа «*»:
Прежде чем grep увидит аргумент командной строки, этот аргумент анализируется оболочкой. Для оболочки * — это подстановочный знак для «всех файлов без точек в текущем каталоге». Поскольку оболочка сначала обрабатывает аргумент, ваша строка превращается в это:
(при условии, что эти три файла находятся в вашем текущем каталоге). Это то, что grep видит из своих аргументов, но это не то, что вы хотите.
Вместо этого вы можете поместить шаблон для grep в кавычки, чтобы он не обрабатывался оболочкой:
Это лучше, но все же не то, что вы хотите: grep использует регулярные выражения, а не подстановочные знаки в стиле оболочки. Звездочка для grep означает «0..n повторений предыдущего символа» — символ, который вы не указали. Близко, но не сигара.
Если вам нужен «любой» шаблон, вы ищете «0..n повторений произвольного символа». Последний представлен точкой ( ‘.’ ) В регулярных выражениях:
Это то, что вы искали.
Изменить: другой случай легче объяснить. С grep «» вы ищете пустую строку, которая присутствует в качестве подстроки в любой строке.
Источник
Почему grep не срабатывает в случае «3+»?
Вот такая ситуация:
Почему в первом случае регулярка не удовлетворяет выражению? Вполне ведь удовлетворяет.. Ведь чисел в диапазоне 0-9 как минимум одно есть..
Re: Почему grep не срабатывает в случае «8+»?
О чёрт. Склеело всё в одно строчку. Вот я что имел ввиду: `echo «aaa111aaa» | grep ‘5+’`. Почему оно не срабатывает?
Re: Почему grep не срабатывает в случае «8+»?
echo «aaa111aaa» | grep ‘5\+’
Re: Почему grep не срабатывает в случае «2+»?
grep по умолчанию строку не как регулярное выражение использует. Используй egrep или grep -E
Re: Почему grep не срабатывает в случае «1+»?
точнее так (из мануала):
Grep understands two different versions of regular expression syntax: “basic” and “extended.” In GNU grep, there is no difference in available functionality using either syntax. In other implementations, basic regular expressions are less powerful. The following description applies to extended regular expressions; differences for basic regular expressions are summarized afterwards.
Re: Почему grep не срабатывает в случае «2+»?
Для таких простых случаев, чтобы не использовать egrep (grep -E) я пишу так: grep ’51*’
Re: Почему grep не срабатывает в случае «3+»?
Вообще 3 — еще есть перловые, с -P
Re: Почему grep не срабатывает в случае «2+»?
ну про «два» — так в мануале написано 🙂
Re: Почему grep не срабатывает в случае
Спасибо большое за ответы! Действительно работает 🙂
Источник
Я положил систему с помощью grep. Что я сделал не так?
Есть физический сервер с Oracle Linux 7.5, с ядром uek-5 и с последними обновами.
Набрал простую команду по ssh:
и после этого сервер завис полностью. Сказать, что я был в шоке — ничего не сказать.
Последнее в консоли:
ssh завис, консоль через ILO была просто чёрной.
Что я сделал не так? Как через grep я мог положить систему? На вируталке с такой же ОС не смог воспроизвести проблему. А это был почти prod, к счастью, сервер пока новый и только билдится.
P.S> grep запускать через sudo.
Что я сделал не так? Как через grep я мог положить систему?
Было у меня также. Не делай так.
Моя ванга говорит, что если зависло на /sys, значит в каком-то драйвере баг.
Ребята, Ubuntu 18.04 зависает точно так же. Попробовал на домашнем ПК. Вируталки не зависают, только физика.
4 раза подряд только что проделал эксперимент, система зависает. В консоли выводится сообщение о ACPI и система фризится.
Что это за бред? Я не пойму.
P.S. grep надо через sudo делать.
в логах на Ubunru:
p.S. проблема из-за каталога /sys/kernel Выявил опытным путём.
не делай grep по /sys/
Жаль, что на зависший Oracle Linux ещё не купили лицензию. На системах с купленной лицензией нельзя экспериментировать.
RHEL ‘чтобы поиграться’ тоже отсутствуют. Придётся ждать ‘планового’ ребута серверов, чтобы спровоцировать зависание и открыть кейс вендору. Если разрешат, конечно.
у меня не зависает — время идет и все такое, но остановить выполнение этой команды не могу — все ядра в сотку. прикольный такой вирус — можно прикрутить к чему нибудь или в наглую напарить — мол выполни такую то команду
Попробовал на ораньж пай пк+ с армбианом, повисело и отвисло, брат жив. На i7 под арчем даже и не зависало толком. На фряхе тоже не висло, брат жив снова. Так что у тебя что то не так.
На серваке с Oracle Linux 2 процессора Intel® Xeon® Gold 6142 (в сумме 32 ядра и 64 потока) и 256 ГБ RAM, дома i5-6400 (4 ядра) и 16 GB RAM.
Дома система крайне неотзывчивая становится и приходится делать reset, на серваке ctrl + c не работала, новая ssh-сессия не открывалась, через ilo тупо чёрный экран.
Не работай под рутом (c) ™ (r)
Дебилы б. (r) ™ (c)
Но grep же работает в 1 поток, и если даже он будет парсить файл размером 256ТБ — разве ситсема должна повсинуть?
Должна виртуальная память кончиться. ЕМНИП, в бубунте overcommit разрешён по дефолту — это значит, что OOM не придёт. Ну и если там свопа дохера — оно не виснет, оно в своп всю эту чухню складывает. А это медленно.
Перед зависаниями я смотрел free -m в соседнем терминале, свободной памяти было много.
Можно продолжать теоретизировать после того как станет понятно на каком файлике затыкаемся.
А так, внутренняя Ванга подсказывает, что у нас с одной стороны паровозик грепа катится, а с другой — ядро пытается на полном ходу ему рельсы подкладывать. В смысле, «файлик» этот. И, возможно, оно утилизирует больше одного cpu core на это.
grep отлично вешает. Давно известно. Ничего нового.
Oracle Linux Unbreakable Enterprise Kernel положил систему с помощью grep
При определенном положении звезд можно и find’ом kernel panic вызвать.
Ты ищешь в каком-то файле, который постоянно изменяется.
интересно, я есть ли воспроизводимые пути вызова BSoD на Windows?
Вы мне не поверите, то с помощью вашей конструкции ничего не зависает. А если сделать так, как я написал — зависает.
конечно, можно набрать специальную юникодную последовательность в notepad.exe
Просто find по умолчанию никогда не ходит по символическим ссылкам, а ‘grep -r’ ходит по тем, что есть в командной строке, куда ты их загоняешь по ‘*’. Попробуй сравнить структуру /sys на реальной и виртуальной машинах, максимально близких по железу и операционке, может и найдёшь в чём фокус.
Просто find по умолчанию никогда не ходит по символическим ссылкам
. по ссылке наверно уходит в /proc, а там полно странных файлов, которые по нормальному не открыть.
Ок, да, тогда как насчет
интересно, я есть ли воспроизводимые пути вызова BSoD на Windows?
Да, раньше в одной из функций WinAPI был баг из-за отсутствия проверки деления на 0. При вызове этой функции с определённым аргументом винда падала в синий экран.
Ничего, система не зависает.
Считывать все подряд псевдофайлы — идея выглядит так себе. Но было бы интересно, на каких именно файлах глохнет.
Поправить реестр, нажать ctrl+Scroll Lock
Что только не придумают, чтобы только не подойти к проблеме по уму. Ведь grep непаралельный, надо вначале выяснить, оно замирает на одном файле или находит бесконечное количесво тут же генерируемых файлов и захлёбывается в этом. А потом уже делать всякие strace на конкретном каталоге/файле.
Я так понимаю, проблема не в том, что grep где-то там захлёбывается, а в том, что при этом ложится вся система.
Хороший «ручной вирус».
У меня grep на файлах amd-(что-то там) выдал чёрный экран, после нескольких секунд изображение появилось, но из-за артефактов ничего непонятно. Такого авангарда, который происходит на экране, я ещё не у одного художника не видел.
если ты на винде из с правами администратора запустишь простенький скрипт читающий всю опертивку(из под оминаже можно по идее да) любая винда зависнет
если ты из под админа в винде начнешь читать ACPI прошивок работающих жестких дисков-все зависнет
и еще тыща сценариев
то что ты решил грипнуть «потомушто могу» а там сотни «неактивных драйверов»(которые вешают ядро если читать их без инициализации).
повесить ACPI на вин/линукс современном дело двух строк скрипто-кода, и под админа конечноже
Я так понимаю, проблема не в том, что grep где-то там захлёбывается, а в том, что при этом ложится вся система.
А я так понимаю, что проблема не выявлена. С тем же успехом может оказаться, что дело не в поиске как таковом, а в бесконечном количестве файлов в каталогах и выжирании всей памяти на их «имена», ибо /sys славится замкнутыми ссылками и кольцеванием дерева. Но это одна из версий.
Что это за дистрибутив, в котором система ложится от одной программы, выжравшей память? Даже если лимиты не настроены, есть же OOM-Killer. Форк-бомбы тут нет, один процесс.
Manjaro — вывод команды — куча строк с «Отказано в доступе».
Если всю память съела программа из юзерспейса — ее пристрелит OOM. Если всю память съело ядро — мы увидим kernel panic.
Наверное, не память. Но это, опять же, чисто теоретически.
В сислоге там ничего не осталось интересного после «зависания»?
Если есть своп на медленном диске — OOM не придёт (система уйдет в IO, и это будет бесконечно долго).
Любой, у которого большой своп на медленном устройстве.
Ты пытался грепать волшебные файлы которые выполняют произвольные действия при обращении к ним на уровне железа. Да, даже при чтении.
Вируталки не зависают, только физика
Виртуалки эмулируя железо могут говорить что всё ок (вместо реальной операции стоит затычка).
Профиль | Отправить PM | Цитировать 
