System Events cannot work with negative process ids

Scripting Forums AppleScript | Mac OS X
#1

I’ve discovered that System Events cannot work with negative process ids. Those are real, and seem to occur when a Mac’s uptime has gotten pretty long. Obviously, this seems to be the way the system describes ids that have rolled over an integer limit.
My specific situation is where I am working with more than one app that gives the same name, and I want to work with the frontmost. So, I get the process id of the frontmost app, and if it contains my name, that’s the process id I want to work with. If the frontmost is not a name-match, I just get the first process that does match.
Then, I use a tell process id myAppID block to work with it. It doesn’t work to try to sue a reference, since the de-reference will often talk to one of the other instances - I have to use tell process id myAppID.
Ok. That all works, and I use that extensively and successfully.
However, at some point, it appears that macOS starts assigning large scientific numbers to processes, and then even that isn’t enough and it rolls over into negative scientific numbers, like -2.124749523E+9.
Example:

tell application "System Events"
	id of every application process whose name contains "ker"
end tell
(* RESULT:
{1.914708368E+9, -2.124749523E+9}
*)

Unfortunately, it seems System Events cannot handle those “negative” process ids.
If I run the positive scientific number process id, I get expected results:

tell application "System Events"
	properties of process id 1.914708368E+9
end tell
(* RESULT:
{has scripting terminology:false, …and so on…, accessibility description:missing value, enabled:missing value, unix id:33483}
*)

But, if I run the same code for the “negative” scientific number, this is the result:

tell application "System Events"
	properties of process id -2.124749523E+9
end tell
(* ERROR: 
error "System Events got an error: Can’t get process id -2.124749523E+9." number -1728 from process id -2.124749523E+9
*)

Has anyone else seen this before? Obviously, one solution would be to restart my Mac, which I will do, but I was hoping there would be a way that System Events can be coaxed into working with these process ids. I did some searching online, and it looks like process ids are Int32, which of course have a maximum value of 2^31-1 (2,147,483,647). That matches the behavior I’m seeing, except for the fact that System Events doesn’t seem to support the rollover to negative values that macOS uses to handle overflow.
Can anyone think of a way to get System Events to work with these (legitimate) process ids?

#2

id in AppleScriprt can be pretty general ID of
An item

Your asking for id and every item will always return a list.

You want to ask for process ids of ……
Or every process id of ………

Your then calling system events
properties of process id yourID

Just for fun try

set aApp to first application process whos id is yourID
properties of aApp

you really should use variable to get and set properties
And then use to results to test things

#3

I know that every item returns a list. I was showing examples of the unusual application process ids that currently exist on my system.
I was hard-coding the negative id in my next example to make it clear this was a very specific issue: System Events cannot talk to negative application process ids. I didn’t want anyone to wonder if the variable was some unexpected data type (e.g. a list).
When I was actually doing this, I was using variables. I have a pretty involved script that works very reliably in normal use, but is how I discovered this System Events problem with (actual) negative process ids.
Here’s the results for your suggestion:

tell application "System Events"
	set yourID to id of (last application process whose name contains "ker")
	(*  -1.747260137E+9  *)
	set aApp to first application process whose id is yourID
	(* error "System Events got an error: Can’t get application process 1 whose id = -1.747260137E+9. Invalid index." number -1719 *)
	properties of aApp
end tell

So, unfortunately, this is indicating the same issue I posted about.
System Events refuses to recognize a negative number as a valid application process id when it comes to talking TO a process, even when System Events was the method by which the process id was obtained.

If I only want to get the properties of a process where I can do the “whose name contains” logic, I could use a reference. Unfortunately, in my case, I don’t want to talk to just ANY app that matches the name. I want to check the frontmost app, see if that matches the name, and then talk TO that specific app. But, if the frontmost does not match, I want to talk to just whichever matches. And, I have a lot I want to do with that, so I wrapped that logic into a function/handler. That cannot return a reference, since AppleScript will happily pick a non-frontmost instance of the app when it dereferences the reference. I need to go by the specific process id chosen.
So, that’s how I discovered this inability of System Events to talk to a negative process id.

Can anyone think of some way, other than a system restart to reduce uptime and process id numbers, to get System Events to talk to a negative process id?

#4

When this happens, what are the pids for these two app versions as shown in terminal?

#5

@ronzo99 - that is a fascinating hint that might have led me to the solution!
Their UNIX pids are 64851 and 94065. I was talking about the System Events process id, which is different, of course.
BUT, while trying to get a reference by name leads to the problem where, upon dereferencing, I no longer can target the frontmost app, it looks like I can target by UNIX id instead.
So, if I switch over my handler to return the unix id, and then, instead of using tell application process myID, I instead use tell (first application process whose unix id is myID), it looks like that will work.
Example:

set fmAppID to getFMAppUnixID()
tell application "System Events"
	tell (first application process whose unix id is fmAppID)
		set frontmost to true
		click menu item "Script Workspace..." of menu "Scripts" of menu bar 1
	end tell
end tell

And, from what I can see online, due to its UNIX underpinnings, macOS reuses old pids, rather than allowing them to rollover to negative numbers.
So, this might be a solution that won’t run into the same problem. I don’t think there is any concern in this scenario about a pid reuse attack, since the scripts get the pid and then send FileMaker-specific commands, so malicious code would have to terminate FileMaker after the pid was obtained, then somehow generate/terminate many processes to be assigned the pid, and somehow the FileMaker-specific commands would have to initiate something else.
Anyone have more thoughts on that - is this a potential security concern? It seems not, in this case.

#6

Try NSWorkspace

frontmostApplication // NSRunningApplication
runningApplications. // array of NSRunningApplications

Filter the runningApplications by localizedName property.

Then you can ask for its
processIdentifier

#7

You’re getting an invalid index error.
Your asking for first,
when the whose clause is only going to return one instance.

There can only be ONE
application process whose id is yourID

#8

I’m trying to get only one process. That’s the whole point.
In AppleScript, the syntax “first A of B whose C is D” will return the first item of what would otherwise be a list.
The index error is because System Events does not supporting talking to an application process whose (AppleScript) id is negative, as I demonstrated earlier.
Now that I’ve restarted my Mac, and the multiple FileMaker processes I have running all have positive ids, the exact same code does not get an error.
This was not a syntax error, it is a flaw in how System Events handles the fact that the id AppleScript uses to refer to processes does not reuse old ids when they become available, but instead, when the ids hit the signed Int32 limit of 2^32-1, they rollover to negative numbers.
Here’s the same code, post restart, proving that this is not a situation of syntax error:

tell application "System Events"
	set yourID to id of (last application process whose name contains "ker")
	(* 1540472 *)
	set aApp to first application process whose id is yourID
	return result
	(* SUCCESSFUL RESULT: 
		application process "FileMaker Pro" of application "System Events"  
	*)
end tell

Anyway, the solution was what @ronzo99 hinted at: use the actual (Unix) PID of the frontmost app, and then tell that process using this kind of syntax. The Unix PID has a big advantage on a system with long uptime, and where, possibly, something was generating a LOT of processes that have since ended: it reuses ids once they are free, to keep the PID from getting large, and certainly never going negative.

tell application "System Events"
	tell (first application process whose unix id is fmAppID)
		-- DO SOMETHING
	end tell
end tell