Почему ps o/p перечисляет процесс grep после канала?

Когда вы выполняете команду:

ps -ef | grep cron

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

(... Я предполагаю, что в вашем случае bash, из-за атрибута цвета grep я думаю, что вы используете систему gnu, такую ​​​​как дистрибутив Linux, но то же самое и в других unix/оболочках...)

выполнит вызов pipe() для создания FIFO, затем fork() (создаст свою текущую копию). Это создаст новый дочерний процесс. Этот новый сгенерированный дочерний процесс будет close() использовать свой стандартный дескриптор выходного файла (fd 1) и присоединит fd 1 к стороне записи канала, созданного родительским процессом (оболочкой, в которой вы выполнили команду). Это возможно, потому что системный вызов fork() будет поддерживать для каждого допустимый дескриптор открытого файла (в данном случае канал fd). После этого это будет exec() первая (в вашем случае) ps команда, найденная в вашей переменной окружения PATH. С вызовом exec() процесс станет командой, которую вы выполнили.

Итак, теперь у вас есть процесс оболочки с дочерним элементом, который в вашем случае является командой ps с атрибутами -ef.

В этот момент родитель (оболочка) снова fork()s. Этот недавно сгенерированный дочерний процесс close()s использует свой стандартный дескриптор входного файла (fd 0) и прикрепляет fd 0 к стороне чтения канала, созданного родительским процессом (оболочкой, в которой вы выполнили команду).

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

Теперь у вас есть процесс оболочки с двумя дочерними процессами (родственными), где первый — это команда ps с атрибутами -ef, а второй — команда grep с атрибутом cron. Сторона чтения канала подключена к STDIN команды grep, а сторона записи подключена к STDOUT команды ps: стандартный вывод команды ps подключен к стандартному вводу команды grep.

Поскольку ps написан для отправки на стандартный вывод информации о каждом запущенном процессе, а grep написан для получения на стандартный ввод чего-то, что должно соответствовать заданному шаблону, вы получите ответ на свой первый вопрос:

1. оболочка работает: ps -ef;
2. оболочка работает: grep cron;
3. ps отправляет данные (даже содержащие строку "grep cron") на grep
4. grep соответствует своему шаблону поиска из STDIN и соответствует строке "grep cron" из-за атрибута "cron", который вы передали в grep: вы указываете grep сопоставлять строку "cron", и это происходит, потому что "grep cron" строка, возвращаемая ps в момент начала выполнения grep.

Когда вы выполняете:

ps -ef | grep '[c]ron'

переданный атрибут указывает grep сопоставить что-то, содержащее «c», за которым следует «ron». Как и в первом примере, но в этом случае он нарушит строку соответствия, возвращаемую ps, потому что:

1. оболочка работает: ps -ef;
2. оболочка работает: grep [c]ron;
3. ps отправляет данные (даже содержащие строку grep [c]ron) на grep
4. grep не соответствует шаблону поиска из стандартного ввода, потому что строка, содержащая «c», за которой следует «ron», не найдена, но найдена строка, содержащая «c», за которой следует «]ron».

GNU grep не имеет ограничения на соответствие строк, а на некоторых платформах (я думаю, Solaris, HPUX, aix) ограничение на количество строк задается переменной "$COLUMN" или шириной экрана терминала.

Надеемся, что этот длинный ответ немного прояснит процесс оболочки.

НАКОНЕЧНИК:

ps -ef | grep cron | grep -v grep

Оболочка строит ваш конвейер с серией вызовов fork(), pipe() и exec(). В зависимости от оболочки любая ее часть может быть построена первой. Таким образом, grep может быть запущен еще до того, как ps запустится. Или, даже если ps запустится первым, он будет записывать в буфер канала ядра 4k и в конечном итоге заблокируется (при печати строки вывода процесса) до тех пор, пока grep не запустится и не начнет потреблять данные в канале. В последнем случае, если ps может начаться и закончиться раньше, чем grep, вы можете не увидеть grep cron в выводе. Возможно, вы уже заметили этот недетерминизм в игре.

В вашей команде

ps -ef | grep 'cron'

Linux выполняет команду «grep» перед командой ps -ef. Затем Linux сопоставляет стандартный вывод (STDOUT) «ps -ef» со стандартным вводом (STDIN) команды grep.

Он не выполняет команду ps, сохраняет результат в памяти и передает его в grep. Подумайте об этом, почему бы это? Представьте, если бы вы перекачивали сто гигабайт данных?

Изменить Что касается вашего второго вопроса:

В grep (и большинстве движков регулярных выражений) вы можете указать скобки, чтобы сообщить, что вы принимаете ЛЮБОЙ символ в скобках. Таким образом, написание [c] означает, что он будет принимать любой символ, но указан только c. Точно так же вы можете сделать любую другую комбинацию символов.

ps aux | grep cron
root      1079  0.0  0.0  18976  1032 ?        Ss   Mar08   0:00 cron
root     23744  0.0  0.0  14564   900 pts/0    S+   21:13   0:00 grep --color=auto cron

^ Это соответствует самому себе, потому что ваша собственная команда содержит "cron"

ps aux | grep [c]ron
root      1079  0.0  0.0  18976  1032 ?        Ss   Mar08   0:00 cron

Это соответствует cron, потому что cron содержит c, а затем «ron». Однако это не соответствует вашему запросу, потому что ваш запрос [c]ron

Вы можете поместить в скобки все, что хотите, если оно содержит c:

ps aux | grep [cbcdefadq]ron
root      1079  0.0  0.0  18976  1032 ?        Ss   Mar08   0:00 cron

Если вы удалите C, он не будет совпадать, потому что «cron» начинается с c:

ps aux | grep [abedf]ron

^ Нет результатов

Изменить 2

Повторю еще раз: с помощью grep можно делать всевозможные сумасшедшие вещи. Нет смысла выбирать первого персонажа для этого.

ps aux | grep [c][ro][ro][n]
root      1079  0.0  0.0  18976  1032 ?        Ss   Mar08   0:00 cron

Вы написали: «Насколько я понимаю, ps перечисляет процессы и передает список в grep. grep даже не запустился, пока ps перечисляет процессы».

Ваше понимание неверно.

Трубопровод так не работает. Оболочка не выполняет первую команду до завершения, запоминает вывод первой команды, а затем после запускает следующую команду, используя эти данные в качестве входных данных. Нет. Вместо этого выполняются оба процесса, и их входы/выходы подключены. Как писал Бен Джексон, нет никаких особых гарантий того, что процессы будут выполняться одновременно, если они оба очень недолговечны и если ядро ​​может комфортно управлять небольшим объемом данных, проходящих через соединение. В таком случае все действительно могло произойти так, как вы ожидаете, только случайно. Но концептуальная модель, о которой следует помнить, заключается в том, что они работают параллельно.

Если вам нужны официальные источники, как насчет справочной страницы bash:

  A pipeline is a sequence of one or more commands separated by the character |.  The format for a pipeline is:

         [time [-p]] [ ! ] command [ | command2 ... ]

  The  standard  output  of command is connected via a pipe to the standard input of command2.  This connection is
  performed before any redirections specified by the command (see REDIRECTION below).

  ...

  Each command in a pipeline is executed as a separate process (i.e., in a subshell).

Что касается вашего второго вопроса (который, к сожалению, вообще не связан с этим), вы просто описываете особенность работы регулярных выражений. Регулярное выражение cron соответствует строке cron. Регулярное выражение [c]ron не соответствует строке [c]ron. Таким образом, первая команда grep найдет себя в списке процессов, а вторая — нет.

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

$ ps -ef | grep [c]ron

pgrep иногда лучше, чем ps -ef | grep word, потому что исключает grep. Пытаться

pgrep -f bash
pgrep -lf bash

$ ps -ef | grep cron

Linux Shell всегда выполняет команду справа налево. Итак, перед выполнением ps -ef grep cron уже выполняется, поэтому o/p показывает саму команду.

$ ps -ef | grep [c]ron

Но в этом u указано grep ron, за которым следует только c. Итак, o/p без командной строки, потому что в команде есть [c]ron.