Re: disable IPv6 debian
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.
Reply to: