"Process" commands improvement

Propose new features and changes
JBensimon
Posts: 118
Joined: 19 Nov 2017, 11:19

"Process" commands improvement

Post by JBensimon » 01 Feb 2022, 18:24

It would be very useful if the Process commands (Exist, Close, Wait, etc.) offered the option to limit their scope to processes running in the same session as the script, which I'm guessing is what most people actually intend when using these commands. Scripts that run in multi-user environments like a server O/S (or even a workstation O/S where "Switch user" may be in use) and in which these commands are used "naively", could wind up getting fooled by (or closing) processes running in other sessions, especially likely if the script is running elevated.

Workarounds are available if the script's author is aware of the "danger", but they're tedious to implement: for example, the script could first determine its session ID with the following commands

Code: Select all

PID := DllCall("GetCurrentProcessId")
DllCall("ProcessIdToSessionId", "UInt", PID, "UInt*", SessionID)
and then run, capture, and parse the output of

Code: Select all

TaskList.exe /FI "IMAGENAME eq targetprocess.exe" /FI "SESSION eq %SessionID%" /FO CSV /NH
to determine the PIDs of only the matching process(es) running in the current session.

If this is not easily implemented, the possibility of accidentally operating on processes in other sessions should maybe be mentioned in the documentation, along with workaround examples.

Jacques.

User avatar
Animan8000
Posts: 56
Joined: 11 May 2022, 05:00
Contact:

Re: "Process" commands improvement

Post by Animan8000 » 18 May 2022, 13:12

I would also love seeing to be able to use expressions/variables and or also full path exe's as PIDOrName parameter. Full path because if there's different processes with the same name but you want to target only the ones from a specific path, it would be handy.

User avatar
tank
Posts: 3122
Joined: 28 Sep 2013, 22:15
Location: CarrolltonTX
Contact:

Re: "Process" commands improvement

Post by tank » 18 May 2022, 13:20

There is literally no scenario where within windows there aren't additional users running processes even if they are system processes. It is assumed that if a script writer needs to worry about other users in same OS that they are advanced enuff to manage this with something more appropriate like WMI
We are troubled on every side‚ yet not distressed; we are perplexed‚
but not in despair; Persecuted‚ but not forsaken; cast down‚ but not destroyed;
Telegram is the best way to reach me
https://t.me/ttnnkkrr
If you have forum suggestions please submit a
Check Out WebWriter

JBensimon
Posts: 118
Joined: 19 Nov 2017, 11:19

Re: "Process" commands improvement

Post by JBensimon » 18 May 2022, 17:00

Advanced users *would* be able to work around the issue *if* they're aware it exists: most everything in AHK (for example window-related commands) naturally do not cross the session boundary, so it's easy to fall into the trap of assuming it also applies to process-related commands, and if they write a script that at some point kills say Outlook.exe (which they're pretty sure isn't also running as a system process!), they could inadvertently be affecting other sessions.

Thus my recommendation that, if the process-related commands cannot easily be given the option to limit their scope to the current session, then the potential issue at least be mentioned in the doc.

User avatar
tank
Posts: 3122
Joined: 28 Sep 2013, 22:15
Location: CarrolltonTX
Contact:

Re: "Process" commands improvement

Post by tank » 19 May 2022, 14:46

nonsense, plenty of ahk commands interact far under the specific 6ser session. the fact that in 2 decades you are the first to take issue with this makes it clear that no one else likely sees this as you do. but feel free to submit a pull request on the documentation on github
We are troubled on every side‚ yet not distressed; we are perplexed‚
but not in despair; Persecuted‚ but not forsaken; cast down‚ but not destroyed;
Telegram is the best way to reach me
https://t.me/ttnnkkrr
If you have forum suggestions please submit a
Check Out WebWriter

JBensimon
Posts: 118
Joined: 19 Nov 2017, 11:19

Re: "Process" commands improvement

Post by JBensimon » 20 May 2022, 07:59

Well, I for one would certainly appreciate your pointing out other examples of AHK commands/functions/features that might affect apps in other sessions when used naively.

As for nobody having pointed out the potential issue with process-related commands, it's not the first time in this forum or its predecessor that I've brought up some aspect of the program that's specific to server-based multi-user environments, because a lot of my work involves such environments.

But fine, call it nonsense if you like.

lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

Re: "Process" commands improvement

Post by lexikos » 21 May 2022, 17:30

The following would be acceptable:
  • A warning in the documentation.
  • A recommendation to use other methods if the check or action should be limited to the current session.
For instance, it is typically the case that WinKill can be used instead of Process Close, and WinExist can be used instead of Process Exist. DetectHiddenWindows can be used if the window is hidden, and ahk_exe to identify it by process name or path (Process Exist does not support paths). It is also sometimes the case that the process can and should be closed gracefully by other means.

It should go without saying that running any program as admin involves a certain amount of risk. For the Outlook.exe scenario, it would seem that this is where the risk comes from, more so than naive use of the Process command. If you work with administrative windows that must be automated, my recommendation is the #1 workaround for UAC in the FAQ: run with UI access. Closing Outlook for only the current user doesn't seem like something you would typically need to do in a script designed to make changes that require running as admin.

Even if the option is added, like you said, the user must be aware of the issue before they will utilize that option.

It would be feasible to use ProcessIdToSessionId as a filter in ProcessExist. I will add it to my notes, but realistically won't look at implementing it for a long time given what else I want to do. Also note that I am more or less at a point where I do not intend to add any new features to AutoHotkey v1.

JBensimon
Posts: 118
Joined: 19 Nov 2017, 11:19

Re: "Process" commands improvement

Post by JBensimon » 22 May 2022, 10:18

Outlook.exe was of course only a silly example of a process one would never worry about being present as a background system process, but your perfectly sensible reply is noted and understood.

Thanks.

JB

Post Reply

Return to “Wish List”