Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #247235 > unrolled thread

disable IPv6 debian

Back to article view | Back to linux.debian.user

Contents

  disable IPv6 debian wilson <info@bigcount.xyz> - 2022-04-15 13:50 +0200
    Re: disable IPv6 debian 황병희 <soyeomul@doraji.xyz> - 2022-04-15 14:00 +0200
      Re: disable IPv6 debian wilson <info@bigcount.xyz> - 2022-04-15 14:30 +0200
        Re: disable IPv6 debian Greg Wooledge <greg@wooledge.org> - 2022-04-15 17:00 +0200
          Re: disable IPv6 debian Greg Wooledge <greg@wooledge.org> - 2022-04-15 18:00 +0200
            Re: disable IPv6 debian Tim Woodall <debianuser@woodall.me.uk> - 2022-04-15 18:10 +0200
          Re: disable IPv6 debian wilson <info@bigcount.xyz> - 2022-04-16 02:10 +0200
            Re: disable IPv6 debian Greg Wooledge <greg@wooledge.org> - 2022-04-16 02:20 +0200
              Re: disable IPv6 debian wilson <info@bigcount.xyz> - 2022-04-16 02:30 +0200
                Re: disable IPv6 debian Charles Curley <charlescurley@charlescurley.com> - 2022-04-16 02:40 +0200
                Re: disable IPv6 debian Greg Wooledge <greg@wooledge.org> - 2022-04-16 02:50 +0200
                  Re: disable IPv6 debian wilson <info@bigcount.xyz> - 2022-04-16 03:10 +0200
                  Re: disable IPv6 debian The Wanderer <wanderer@fastmail.fm> - 2022-04-16 03:50 +0200
                    Re: disable IPv6 debian wilson <info@bigcount.xyz> - 2022-04-16 04:10 +0200
                    Re: disable IPv6 debian Greg Wooledge <greg@wooledge.org> - 2022-04-16 05:00 +0200
                      Re: disable IPv6 debian The Wanderer <wanderer@fastmail.fm> - 2022-04-16 14:10 +0200
                        Re: disable IPv6 debian Greg Wooledge <greg@wooledge.org> - 2022-04-16 15:10 +0200
                        Re: disable IPv6 debian David Wright <deblis@lionunicorn.co.uk> - 2022-04-16 18:10 +0200
                    Re: disable IPv6 debian <tomas@tuxteam.de> - 2022-04-16 08:20 +0200
                      Re: disable IPv6 debian Tim Woodall <debianuser@woodall.me.uk> - 2022-04-16 08:40 +0200
                        Re: disable IPv6 debian wilson <info@bigcount.xyz> - 2022-04-16 10:30 +0200
                          Re: disable IPv6 debian David <bouncingcats@gmail.com> - 2022-04-16 10:50 +0200
                          Re: disable IPv6 debian Greg Wooledge <greg@wooledge.org> - 2022-04-16 15:00 +0200
              Re: disable IPv6 debian Michael Stone <mstone@debian.org> - 2022-04-16 20:00 +0200
            Re: disable IPv6 debian <tomas@tuxteam.de> - 2022-04-16 08:20 +0200
        Re: disable IPv6 debian Chuck Zmudzinski <brchuckz@netscape.net> - 2022-04-15 19:40 +0200
        Re: disable IPv6 debian Andy Smith <andy@strugglers.net> - 2022-04-16 01:00 +0200
          Re: disable IPv6 debian didar <nosferatu@purlo.in> - 2022-04-16 07:10 +0200
            Re: disable IPv6 debian Andy Smith <andy@strugglers.net> - 2022-04-16 11:50 +0200
    Re: disable IPv6 debian Reco <recoverym4n@enotuniq.net> - 2022-04-15 14:30 +0200
      Re: disable IPv6 debian wilson <info@bigcount.xyz> - 2022-04-15 14:40 +0200
        Re: disable IPv6 debian Erwan David <erwan@rail.eu.org> - 2022-04-15 16:00 +0200
          Re: disable IPv6 debian Jeremy Ardley <jeremy@ardley.org> - 2022-04-15 16:20 +0200
        Re: disable IPv6 debian Reco <recoverym4n@enotuniq.net> - 2022-04-15 16:20 +0200
    Re: disable IPv6 debian wilson <info@bigcount.xyz> - 2022-04-16 02:20 +0200
    Re: disable IPv6 debian Ash Joubert <ash@transient.nz> - 2022-04-16 02:20 +0200

Page 1 of 2  [1] 2  Next page →

#247235 — disable IPv6 debian

Hello

What's the good way to disable IPv6 in a debian system?

Thanks

[toc] | [next] | [standalone]

#247236

> What's the good way to disable IPv6 in a debian system?

Well i don't know debian system. However i'm using Debian 11.

If that is about mail system Postfix, you check this parameter:

#+begin_src text
inet_protocols = ipv4
#+end_src

Sincerely, Linux fan Byung-Hee

-- 
^고맙습니다 _布德天下_ 감사합니다_^))//

[toc] | [prev] | [next] | [standalone]

#247239

no. it's the Hadoop system, which has the possible issue with ipv6.

thanks

황병희 wrote:
> If that is about mail system Postfix, you check this parameter:

[toc] | [prev] | [next] | [standalone]

#247248

On Fri, Apr 15, 2022 at 10:34:25AM -0400, Chuck Zmudzinski wrote:
> user@debian:~$ cat ipv6
> #!/bin/bash
> if [ $1 == "on" ]
> then
>         ip -6 route add default via <redacted> dev <redacted>
> elif [ $1 == "off" ]
> then
>         ip -6 route delete default
> fi

Quotes are in the wrong place.  The [ builtin command follows the
ordinary parsing rules, which means an unquoted $1 argument will be
subject to word splitting and filename expansions.

In simpler terms, it will blow up if $1 is empty or contains whitespace
characters or globbing characters.

The quotes need to go around "$1", not around string constants.

if [ "$1" == on ]

[toc] | [prev] | [next] | [standalone]

#247251

On Fri, Apr 15, 2022 at 11:21:46AM -0400, Chuck Zmudzinski wrote:
> Another improvement to the script would be to have the script toggle the
> default route on or off, depending on the existence or not of the default
> route, for the case when there is no argument to the script.

That requires some way to *determine* the current state.  Parsing the
routing table, perhaps?  If you could tell us how to do that, it might
help.

[toc] | [prev] | [next] | [standalone]

#247253

On Fri, 15 Apr 2022, Greg Wooledge wrote:

> On Fri, Apr 15, 2022 at 11:21:46AM -0400, Chuck Zmudzinski wrote:
>> Another improvement to the script would be to have the script toggle the
>> default route on or off, depending on the existence or not of the default
>> route, for the case when there is no argument to the script.
>
> That requires some way to *determine* the current state.  Parsing the
> routing table, perhaps?  If you could tell us how to do that, it might
> help.
>
>

Try this (untested as I'm remote and don't want to remove my default
route!)

[[ -z "$( ip -6 route show exact default )" ]] && echo no

Hopefully will print no if there is no default route.

Tim.

[toc] | [prev] | [next] | [standalone]

#247262

Greg Wooledge wrote:
> if [ "$1" == on ]

this sounds strange. why a string doesn't need "" around in shell script?

[toc] | [prev] | [next] | [standalone]

#247265

On Sat, Apr 16, 2022 at 08:06:23AM +0800, wilson wrote:
> 
> 
> Greg Wooledge wrote:
> > if [ "$1" == on ]
> 
> this sounds strange. why a string doesn't need "" around in shell script?

You only need quotes to force a literal interpretation of whitespace or
other special characters, or to suppress word splitting and filename
expansion (globbing) after a substitution.

Consider a command like this:

ls -l .bashrc

You've got a command name, and you're passing two string arguments to
it.  If you feel a need to quote every string argument, then you should
be writing it like this:

ls "-l" ".bashrc"

But nobody does that.  It's simply unnecessary.  Likewise, you don't need
quotes around "on" or "off" because they don't contain special characters.
You also don't need quotes around the "==" string argument that was passed
in this command.  It's funny that you would think you should put quotes
around "on" but not around "==", isn't it.

[toc] | [prev] | [next] | [standalone]

#247266

Greg Wooledge wrote:
> But nobody does that.  It's simply unnecessary.  Likewise, you don't need
> quotes around "on" or "off" because they don't contain special characters.
> You also don't need quotes around the "==" string argument that was passed
> in this command.  It's funny that you would think you should put quotes
> around "on" but not around "==", isn't it.

I didn't know much about shell rules.
Can you help check if my this script has any issue?
I use it to check the port is opened by which process.
(in our system there are many many ports opened by java (the hadoop 
ecosystem)).

#!/bin/bash

PORT=$1
if [ -z $PORT ];then
   echo "$0 port"
   exit
fi

PS=`lsof -i :$PORT |grep LISTEN |awk '{print $2}'`

if [ -z $PS ];then
   echo "no this port, or I don't have privilege to list the port"
   exit
fi

ps -efw |grep $PS |grep -v grep

Thanks

[toc] | [prev] | [next] | [standalone]

#247267

On Sat, 16 Apr 2022 08:20:40 +0800
wilson <info@bigcount.xyz> wrote:

> I didn't know much about shell rules.
> Can you help check if my this script has any issue?

You might look into the shellcheck package. There is an extension to
use it in Emacs, and there may well be extensions for other editors.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#247268

On Sat, Apr 16, 2022 at 08:20:40AM +0800, wilson wrote:
> Can you help check if my this script has any issue?

> #!/bin/bash
> 
> PORT=$1
> if [ -z $PORT ];then

"$PORT" should be quoted here.
 
>   echo "$0 port"

As a usage message, this is rather minimal.  At least put "usage: " in
front of it.  Ideally it should also be written to stderr, not stdout.

echo "usage: $0 port" >&2

>   exit

And you should exit with a nonzero status here, to indicate that an error
occurred.

exit 1

> fi
> 
> PS=`lsof -i :$PORT |grep LISTEN |awk '{print $2}'`

Backticks are deprecated.  $( ) is preferred for command substitution.

"$PORT" should be quoted here as well.

grep LISTEN | awk '{print $2}' can be combined into a single command:

awk '/LISTEN/ {print $2}'

> 
> if [ -z $PS ];then

"$PS" should be quoted.

>   echo "no this port, or I don't have privilege to list the port"

Use >&2 to send the error message to stderr.

>   exit

exit 1

> fi
> 
> ps -efw |grep $PS |grep -v grep

"$PS" should be quoted.

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"

But it depends on whether you actually want that behavior.

> 
> Thanks

As a final note, using ALL-CAPS VARIABLE NAMES is a bad practice.  All-caps
variable names are reserved for environment variables, or special shell
internal variables like PATH, BASH_VERSION, RANDOM and so on.  Your
ordinary variables should contain at least one lower-case letter, to avoid
a name collision.

I don't think PORT or PS are used by anything... yet... but eventually
you're going to shoot yourself in the foot by accidentally picking
something like USER or PATH which *is* in use.  So, it's best to break
the bad habits now.

[toc] | [prev] | [next] | [standalone]

#247269

Greg Wooledge wrote:
> "$PORT" should be quoted here.

Thanks a lot Greg.
So my improved script as following.

#!/bin/bash

port=$1

if [ -z "$port" ];then
   echo "usage: $0 port" >&2
   exit 1
fi

ps=$(lsof -i :"$port" |awk '/LISTEN/ {print $2}')

if [ -z "$ps" ];then
   echo "no this port, or I don't have privilege to list the port" >&2
   exit 1
fi

ps -efw |grep -v grep |grep "$ps"

exit 0


Is it the right one for now?

Regards.

[toc] | [prev] | [next] | [standalone]

#247270

[Multipart message — attachments visible in raw view] — view raw

On 2022-04-15 at 20:47, Greg Wooledge wrote:

> On Sat, Apr 16, 2022 at 08:20:40AM +0800, wilson wrote:

>> ps -efw |grep $PS |grep -v grep

> 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.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#247272

The Wanderer wrote:
> 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.

thanks. so i have changed it back again for the last grep.

#!/bin/bash

port=$1

if [ -z "$port" ];then
   echo "usage: $0 port" >&2
   exit 1
fi

ps=$(lsof -i :"$port" |awk '/LISTEN/ {print $2}')

if [ -z "$ps" ];then
   echo "no this port, or I don't have privilege to list the port" >&2
   exit 1
fi

ps -efw |grep "$ps" |grep -v grep

exit 0

[toc] | [prev] | [next] | [standalone]

#247274

On Fri, Apr 15, 2022 at 09:47:11PM -0400, The Wanderer wrote:
> On 2022-04-15 at 20:47, Greg Wooledge wrote:
> > On Sat, Apr 16, 2022 at 08:20:40AM +0800, wilson wrote:
> 
> >> ps -efw |grep $PS |grep -v grep
> 
> > 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.  The difference is that the exit
status of the pipeline is that of the last command in the pipeline.

If you go with the first command, you end up with the exit status of
"grep -v c".  When c is grep, and this filter is being used to suppress
the extra race-conditional output of a "grep" command from the process
list (which may not be there), the resulting exit status will be
unpredictable.

With the second command, the exit status will be 0 (success) if there is
at least one matching "b" in the output, and 1 (failure) if not.

Of course, if you put "exit 0" after it, then it doesn't matter.

[toc] | [prev] | [next] | [standalone]

#247289

[Multipart message — attachments visible in raw view] — view raw

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...

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#247291

On Sat, Apr 16, 2022 at 08:07:09AM -0400, The Wanderer wrote:
> ...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.

All of the commands in a pipeline are executed simultaneously, in
parallel.

Except of course nothing is truly simultaneous.  The shell will attempt
to start them all at roughly the same time, but individual timing
issues across three child processes cause what we call a "race condition".
Sometimes, one of them runs a bit too fast, or a bit too slow, and
you get weird results.

For this pipeline,

  ps -ef | grep foobar | grep -v grep

the race condition is that the ps command could execute so quickly
that the 'grep foobar' process hasn't even started yet.  And then, you
would *not* see 'grep foobar' in the output of ps, and so the final
'grep -v grep' wouldn't match any lines.  In practice, you might not
ever see this happen, at least not in a small number of trials.  But
if you do this thousands of times, on systems with varying loads, you
might.

And of course, tomas raised the excellent point that this is not the
best way to show a process when you already know its PID.

  ps -ef | grep "$mypid"

is silly.  You can simply do

  ps -fp "$mypid"

instead.  You even get to see the headers, which are lost in the silly
variant.

[toc] | [prev] | [next] | [standalone]

#247296

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.

[toc] | [prev] | [next] | [standalone]

#247279

[Multipart message — attachments visible in raw view] — view raw

On Fri, Apr 15, 2022 at 09:47:11PM -0400, The Wanderer wrote:
> On 2022-04-15 at 20:47, Greg Wooledge wrote:
> 
> > On Sat, Apr 16, 2022 at 08:20:40AM +0800, wilson wrote:
> 
> >> ps -efw |grep $PS |grep -v grep
> 
> > 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 [...]

If all you want to do is to find out whether a process with PID "$PS"
is running, why not

  ps --pid "$PS" > /dev/null 2>&1 && echo "yo"

or even perhaps

  kill -0 "$PS" 2>/dev/null && echo "yo"

But yes, for the general pattern you are right.

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#247282

On Sat, 16 Apr 2022, tomas@tuxteam.de wrote:

> On Fri, Apr 15, 2022 at 09:47:11PM -0400, The Wanderer wrote:
>> On 2022-04-15 at 20:47, Greg Wooledge wrote:
>>
>>> On Sat, Apr 16, 2022 at 08:20:40AM +0800, wilson wrote:
>>
>>>> ps -efw |grep $PS |grep -v grep
>>
>>> 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 [...]
>
> If all you want to do is to find out whether a process with PID "$PS"
> is running, why not
>
>  ps --pid "$PS" > /dev/null 2>&1 && echo "yo"
>
> or even perhaps
>
>  kill -0 "$PS" 2>/dev/null && echo "yo"
>
> But yes, for the general pattern you are right.
>
Agree totally with this.

But if you want to use grep, then you need -w at least. grep for pid 123
will also match 1123, 1234, 11234 etc.

ps -ef | grep -w '[p]s' will not match the grep command.

ps -ef | grep -w "[${PS:0:1}]${PS:1}"

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web