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