当我做
$ ps -ef | grep cron
我明白了
root 1036 1 0 Jul28 ? 00:00:00 cron
abc 21025 14334 0 19:15 pts/2 00:00:00 grep --color=auto cron
我的问题是为什么我看到第二行。据我了解，ps列出进程并将列表通过管道传输到grep. grep列出进程时甚至还没有开始运行ps，那么如何grep在 o/p 中列出进程？
相关的第二个问题：
当我做
$ ps -ef | grep [c]ron
我只得到
root 1036 1 0 Jul28 ? 00:00:00 cron
grep第一次和第二次执行有什么区别？
When you execute the command:
ps -ef | grep cron
the shell you are using
(...I assume bash in your case, due to the color attribute of grep I think you are running a gnu system like a linux distribution, but it's the same on other unix/shell as well...)
will execute the pipe() call to create a FIFO, then it will fork() (make a running copy of itself). This will create a new child process. This new generated child process will close() its standard output file descriptor (fd 1) and attach the fd 1 to the write side of the pipe created by the father process (the shell where you executed the command). This is possible because the fork() syscall will maintain, for each, a valid open file descriptor (the pipe fd in this case). After doing so it will exec() the first (in your case) ps command found in your PATH environment variable. With the exec() call the process will become the command you executed.
So, you now have the shell process with a child that is, in your case, the ps command with -ef attributes.
At this point, the parent (the shell) fork()s again. This newly generated child process close()s its standard input file descriptor (fd 0) and attaches the fd 0 to the read side of the pipe created by the father process (the shell where you executed the command).
After doing so it will exec() the first (in your case) grep command found in your PATH environment variable.
Now you have the shell process with two children (that are siblings) where the first one is the ps command with -ef attributes and the second one is the grep command with the cron attribute. The read side of the pipe is attached to the STDIN of the grep command and the write side is attached to the STDOUT of the ps command: the standard output of the ps command is attached to the standard input of the grep command.
Since ps is written to send on the standard output info on each running process, while grep is written to get on its standard input something that has to match a given pattern, you'll have the answer to your first question:
ps -ef;grep cron;ps sends data (that even contains the string "grep cron") to grepgrep matches its search pattern from the STDIN and it matches the string "grep cron" because of the "cron" attribute you passed in to grep: you are instructing grep to match the "cron" string and it does because "grep cron" is a string returned by ps at the time grep has started its execution.When you execute:
ps -ef | grep '[c]ron'
the attribute passed instructs grep to match something containing "c" followed by "ron". Like the first example, but in this case it will break the match string returned by ps because:
ps -ef;grep [c]ron;ps sends data (that even contains the string grep [c]ron) to grepgrep does not match its search pattern from the stdin because a string containing "c" followed by "ron" it's not found, but it has found a string containing "c" followed by "]ron"GNU grep does not have any string matching limit, and on some platforms (I think Solaris, HPUX, aix) the limit of the string is given by the "$COLUMN" variable or by the terminal's screen width.
Hopefully this long response clarifies the shell pipe process a bit.
TIP:
ps -ef | grep cron | grep -v grep
shell 使用一系列fork(),pipe()和exec()调用来构建您的管道。根据外壳的不同，它的任何部分都可以先构建。所以grep可能在ps开始之前就已经在运行了。或者，即使ps先启动，它也会写入 4k 内核管道缓冲区并最终阻塞（同时打印一行进程输出），直到grep启动并开始使用管道中的数据。在后一种情况下，如果ps能够在grep甚至开始之前开始和结束，您可能看不到grep cron输出中的 。您可能已经注意到这种不确定性在起作用。
In your command
ps -ef | grep 'cron'
Linux is executing the "grep" command before the ps -ef command. Linux then maps the standard output (STDOUT) of "ps -ef" to the standard input (STDIN) of the grep command.
It does not execute the ps command, store the result in memory, and them pass it to grep. Think about that, why would it? Imagine if you were piping a hundred gigabytes of data?
Edit In regards to your second question:
In grep (and most regular expression engines), you can specify brackets to let it know that you'll accept ANY character in the brackets. So writing [c] means it will accept any charcter, but only c is specified. Similarly, you could do any other combination of characters.
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
^ That matches itself, because your own command contains "cron"
ps aux | grep [c]ron
root 1079 0.0 0.0 18976 1032 ? Ss Mar08 0:00 cron
That matches cron, because cron contains a c, and then "ron". It does not match your request though, because your request is [c]ron
You can put whatever you want in the brackets, as long as it contains the c:
ps aux | grep [cbcdefadq]ron
root 1079 0.0 0.0 18976 1032 ? Ss Mar08 0:00 cron
If you remove the C, it won't match though, because "cron", starts with a c:
ps aux | grep [abedf]ron
^ Has no results
Edit 2
To reiterate the point, you can do all sorts of crazy stuff with grep. There's no significance in picking the first character to do this with.
ps aux | grep [c][ro][ro][n]
root 1079 0.0 0.0 18976 1032 ? Ss Mar08 0:00 cron
You wrote: "From my understanding, ps lists the processes and pipes the list to grep. grep hasn't even started running while ps is listing processes".
Your understanding is incorrect.
That is not how a pipeline works. The shell does not run the first command to completion, remember the output of the first command, and then afterwards run the next command using that data as input. No. Instead, both processes execute and their inputs/outputs are connected. As Ben Jackson wrote, there is nothing to particularly guarantee that the processes run at the same time, if they are both very short-lived, and if the kernel can comfortably manage the small amount of data passing through the connection. In that case, it really could happen the way you expect, only by chance. But the conceptual model to keep in mind is that they run in parallel.
If you want official sources, how about the bash man page:
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).
As for your second question (which is not really related at all, I am sorry to say), you are just describing a feature of how regular expressions work. The regular expression cron matches the string cron. The regular expression [c]ron does not match the string [c]ron. Thus the first grep command will find itself in a process list, but the second one will not.
您的实际问题已被其他人回答，但我会提供一个提示：如果您不想看到grep列出的过程，您可以这样做：
$ ps -ef | grep [c]ron
pgrep is sometimes better than ps -ef | grep word because it exclude the grep. Try
pgrep -f bash
pgrep -lf bash
$ ps -ef | grep cron
Linux Shell always execute command from right to left. so, before ps -ef execution grep cron already executed that's why o/p show's the command itself.
$ ps -ef | grep [c]ron
But in this u specified grep ron followed by only c. so, o/p is without command line because in command there is [c]ron.