what port(s) give me good control over processes (list, kill, etc) better than MacOS pgrep+pkill

[Richard L. Hamilton]

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 <kennethwolcott at 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 <rlhamil at 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 <kennethwolcott at 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$
>> 
>