Thank you, you have provided lots of help which I need to fully digest..
Ken
On Sat, Apr 8, 2023 at 5:09 PM Richard L. Hamilton <rlha...@smart.net> wrote:
>
> If you're trying to be exact and ONLY get the process you're probably
> interested in, here's a scenario:
>
> sh-3.2$ pgrep -lf CARROT # list process-id and full command line
> 911 /Applications/CARROTweather.app/Contents/MacOS/CARROTweather
>
> sh-3.2$ pgrep -l CARROT # list process-id and just command name
> 911 CARROTweather
>
> sh-3.2$ pgrep -u ${LOGNAME} -x CARROTweather # match only current user-id and
> exact command name
> 911
>
> With -f, it will match (and with -l, display) the entire command line.
> Without it, it will match (and with -l, display) the command "name", which is
> the first sixteen characters of the last level of the pathname passed to
> execve(), or maybe of argv[0], but I don't think so.
>
> With -x it has to be an exact match, otherwise it just has to match a
> substring (somewhere in what's being matched).
>
> With -u it has to match that user-id too (which can be either numeric or an
> account name).
>
> So the last of those requires specifically the process CARROTweather running
> with my own user-id, and will ignore an instance with any other user-id, such
> as if someone else is logged in graphically with screen sharing/VNC (maybe
> with NX and some other things too if they allow multiple graphical logins)
> and also running it.
>
> A single user can still have multiple processes of the same name running
> (such as either a command line program or an app opened with the -n option of
> the open command); there would probably be no good and simple way to be sure
> which one was desired.
>
>
> > On Apr 8, 2023, at 17:20, Kenneth Wolcott <kennethwolc...@gmail.com> wrote:
> >
> > Hi Richard;
> >
> > Thank you for your additional input.
> >
> > Apparently I was over-thinking pgrep+pkill in my earlier attempts.
> >
> > I have implemented your suggestions in my script and it appears to work
> > fine.
> >
> > Thanks,
> > Ken Wolcott
> >
> > On Fri, Apr 7, 2023 at 9:27 PM Richard L. Hamilton <rlha...@smart.net>
> > wrote:
> >>
> >> Not seeing that, if this fits your scenario:
> >>
> >> sh-3.2$ open -a TextEdit
> >> sh-3.2$ pgrep -lf TextEdit
> >> 68476 /System/Applications/TextEdit.app/Contents/MacOS/TextEdit
> >> sh-3.2$ pkill TextEdit
> >> # it went away...
> >>
> >> SIGTERM is (usually) like Quit; SIGKILL is like Force Quit.
> >>
> >> A process may ignore SIGTERM; the signalling process will not be informed
> >> of that. SIGKILL cannot be ignored; although in some Unix implementations,
> >> a hang on what's supposed to be fast I/O (like a physical disk, or an NFS
> >> mount that's "hard" but not "intr") can make a process unkillable, at
> >> least until the hang resolves, if it does; if not, nothing but a reboot
> >> will kill such a process. Some implementations block SIGKILL on process 1,
> >> because process 1 is essential and there's no good reason to do that.
> >>
> >> Sometimes the executable in an app bundle does not have the same name as
> >> the app; but a pgrep -lf could match based on the full path includng the
> >> app name.
> >>
> >> pgrep or pkill not finding something is not an error, although they'll
> >> have a return code of one.
> >> sh-3.2$ pgrep -lf nosuch
> >> sh-3.2$ echo $?
> >> 1
> >> sh-3.2$ pkill nosuch
> >> sh-3.2$ echo $?
> >> 1
> >>
> >> You cannot kill something unless you're root or the same real or effective
> >> userid as it is; there MIGHT be other restrictions, Apple liking to be
> >> tricky about security. But if it exists and you're not allowed to kill it,
> >> that would get an error message:
> >>
> >> sh-3.2$ pkill syslogd
> >> pkill: signalling pid 161: Operation not permitted
> >>
> >> Other than those cases, I don't have further guesses what's happening.
> >>
> >>
> >> On Apr 7, 2023, at 23:55, Kenneth Wolcott <kennethwolc...@gmail.com> wrote:
> >>
> >> Hi Richard;
> >>
> >> Thanks for the info. I'll look into those.
> >>
> >> I found that a process that I started by using the MacOS open
> >> command could be listed by prep but I could not kill it with pkill
> >> (silently fails, like a no-op).
> >>
> >> sh-3.2$
> >>
> >
>
