AutoIt v3.3.9.12 Beta

[guinness]

Well Run returns a PID, which can be useful for some people.

[jaberwacky]

Just came back to say I answered my own question.

[Jos]

Would be a big script-breaker as it is used a lot and ShellExecute doesn't support STDxxx redirection.

Jos

[Ascend4nt]

Regarding the issue with manifests marked as 'requireAdministrator':  this is not a problem specific to AutoIt scripts.  Run() will of course fail for any process with that in it.

Asking for the capability to use Run() on scripts that need to self-elevate isn't helpful as

1) The PID returned from Run() will not be valid once the script reruns itself as it did in 3.3.8.1 and earlier

2) Redirecting I/O of a script that effectively terminates when it reruns itself isn't useful.  Plus, you can't redirect I/O on an elevated process without being elevated yourself.

Also, ShellExecuteEx does in fact return Process ID #'s in many cases, and this is one of the arguments me and Valik got into - AutoIt could be written to return a Process ID # from ShellExecute, but the fact that it doesn't always return PIDs is why Valik decided not to add it. This 'sometimes PID' situation could be worked around with something like a -1 return when ShellExecute is successful but a PID # wasn't obtained..

Currently you can use ShellExecuteEx examples on the forum to get PIDs, however

[Jon]

Also, ShellExecuteEx does in fact return Process ID #'s in many cases, and this is one of the arguments me and Valik got into - AutoIt could be written to return a Process ID # from ShellExecute, but the fact that it doesn't always return PIDs is why Valik decided not to add it. This 'sometimes PID' situation could be worked around with something like a -1 return when ShellExecute is successful but a PID # wasn't obtained..

 

I've added the code to return a PID. I don't quite follow the logic of not adding it as ShellExecuteWait() would also fail for the situation described - but we still have that.

[Ascend4nt]

I've added the code to return a PID. I don't quite follow the logic of not adding it as ShellExecuteWait() would also fail for the situation described - but we still have that.

Sweet!  That might be a script-breaking change as some people might rely on ShellExecute() returning 0 or 1 (it gives that specific value in the help).  You could always just return it in @extended if you care about that..