On Sat 16 Apr 2022 at 08:07:09 (-0400), The Wanderer wrote: > On 2022-04-15 at 22:52, Greg Wooledge wrote: > > On Fri, Apr 15, 2022 at 09:47:11PM -0400, The Wanderer wrote: > >> On 2022-04-15 at 20:47, Greg Wooledge wrote: > >>> You're also going to exit your script with the exit status from > >>> that last grep command. That's probably not what you want. If > >>> it's not, then an explicit "exit 0" at the end might be a good > >>> idea. > >>> > >>> Or, as another choice, you might want to exit with the exit > >>> status of the *first* grep. In that case, switching them around > >>> would be better: > >>> > >>> ps -efw | grep -v grep | grep "$PS" > >> > >> This would probably result in undesired behavior. I recognize this > >> pattern; for reasons that I don't entirely grasp but which seem > >> somehow intuitive to me, invoking ps in any of the ways that I've > >> yet found useful and piping the output to grep will result in that > >> grep process - with its arguments - being listed in the ps output. > >> > >> Because the string you're grepping for is included in that > >> argument list, that line will be matched, and so will be printed. > >> > >> In order to avoid that, the obvious thing to do is just append ' | > >> grep -v grep' to the pipeline, so that the unwanted result line > >> gets stripped out. I've used that pattern many times. > >> > >> IOW: Having the "cut out any lines that mention the command that > >> got the search pattern passed to it" command come last is likely to > >> be a necessity. > > > > Your conclusion is not correct. > > > > foobar | grep b | grep -v c > > > > foobar | grep -v c | grep b > > > > both give the same lines of output. > > ...Huh. That's so unintuitive that it hadn't even occurred to me to test > it before posting, but I just did test it (with 'ps', not 'foobar', > because there's a reason why 'ps' would be special for this purpose), > and you're correct. > > I *think* it makes sense on examination? In that the fact that the first > grep command occurs in the ps output in the first place must mean that > its process is in some sense started before the ps command is run, even > though the ps command comes earlier in the pipeline, so the same must > logically hold true for the *second* grep command as well. > > That's a weird fact to have be true to begin with, but given that it > *is* true or we wouldn't have this issue anyway, I suppose it holds > together. > > Thanks for getting me to check my own intuition on this...
If you want to see to the end of the pipe, just use a command there that you can recognise and match. For example, here I've used "less" in a less frequently used variant (in case there are other instances of the pager running): $ ps -ef | grep -e xclock -e less -e grep | grep -v grep | less -X auser 2656 1 0 09:46 tty1 00:00:00 xclock -strftime %a %d auser 4730 2091 0 10:53 pts/10 00:00:00 less -X $ Getting the second grep to show up as a running process is tricky as it usually matches itself, but can be done: $ ps -ef | grep -e xclock -e less -e grep | grep -f /tmp/patt -v | less -X auser 2656 1 0 09:46 tty1 00:00:00 xclock -strftime %a %d auser 4783 2091 0 10:55 pts/10 00:00:00 grep -f /tmp/patt -v auser 4784 2091 0 10:55 pts/10 00:00:00 less -X $ cat /tmp/patt grep -e $ Cheers, David.
