RunWait executes wrong .exe file

[hso]

[Moderator's note: Topic moved from Bug Reports.]

I've got this very simple script:

Code: Select all

RunWait, K:\BEST\FXU\Makro til P6\FlexManager\Release\Afbestil rejse P6 Id.exe "25640562"

In this folder I've got a couple of executable files. Besides the 'Afbestil rejse P6 Id.exe' I also have a 'Afbestil rejse.exe'

When I run above script, it executes the 'Afbestil rejse.exe' file instead of the 'Afbestil rejse P6 Id.exe' file.

[Xtra]

Try:

Code: Select all

RunWait, %ComSpec% /c ""K:\BEST\FXU\Makro til P6\FlexManager\Release\Afbestil rejse P6 Id.exe" "25640562""

When running a program via ComSpec (cmd.exe) -- perhaps because you need to redirect the program's input or output -- if the path or name of the executable contains spaces, the entire string should be enclosed in an outer pair of quotes.

[hso]

I did get it running by putting my executable path in double quotes.

Code: Select all

OpgaveExe := """" . OpgaveExe . """"
RunWait, %OpgaveExe% %Parameter% %BestiltOpgaveId%

But this is not described in the function specs. I have successfully been using this command for a few years with about a million tasks. So running without ComSpec does works.

[joefiesta]

I am using ahk 1.1.33.09 on Windows 7 pro.

This appears to be a genuine bug. If not on the part of the AHK then WINDOWS. I haven't tested to see if WINDOWS is the culprit.

I often run executables with a space in the fileid. But, haven't found this problem because, out of habit, I prefer to always enclose such fileids in double quotes. And, this is an extremely obscure bug!!!

I ran the following script, each time uncommenting 1 RUN command. Results are shown as comments in the code.

It appears that
1. when a blank is part of the fileid of the path the information after the blank is discarded
in determining the name of the target executable but IF and ONLY IF by doing so the fileid then becomes a fileid on a .EXE file that exists.
2. In this case, the "modified" path is the target executable of the RUN command. and
3. the "discarded" portion of the correct excutable value is interpretted as part of the paramters.

test script:
gif := "C:\Users\Joey\Documents\my photos\Other people's pics\gifs\1-64.gif"
;Run, C:\Program Files\GIF Viewer\GIF Viewer.exe "%gif%",, UserErrorLevel
;Run, C:\Program Files\GIF Viewer\GIF Viewer - Copy.exe "%gif%" ; fails
; the above runs GIF Viewer.exe
; which then asks what file to open.
;Run, C:\Program Files\GIF Viewer\GIF Viewer Copy.exe "%gif%" ; fails
; the above runs GIF Viewer.exe
; which then asks what file to open.
; this was to check if the "-" (special character, so to speak made
; a difference. it did not.
;Run, C:\Program Files\GIF Viewer\GIFViewer Copy Copy.exe "%gif%" ; works
; then create GIFViewer.exe
;Run, C:\Program Files\GIF Viewer\GIFViewer "%gif%" ; works
;Run, C:\Program Files\GIF Viewer\GIFViewer Copy Copy.exe "%gif%" ; fails
; the above runs GIFViewer.exe and apparently thinks the
; "Copy Copy.exe" %gif% are the parameters to pass
exitapp


side story.... just a diversion:
I remember as a programmer long ago, I created an MVS file with a blank in the name. This was not a simple thing to do, especially since it was frowned upon. The head of security one day came down to operations where I worked and he was furious. Especially since I was just a computer operator. He BLAMED ME for his security program failing because of my file. I was ECSTATIC. He was such a jerk!!!!

[TAC109]

I've got this very simple script:

Code: Select all

RunWait, K:\BEST\FXU\Makro til P6\FlexManager\Release\Afbestil rejse P6 Id.exe "25640562"

In this folder I've got a couple of executable files. Besides the 'Afbestil rejse P6 Id.exe' I also have a 'Afbestil rejse.exe'

When I run above script, it executes the 'Afbestil rejse.exe' file instead of the 'Afbestil rejse P6 Id.exe' file.

This problem can occur because the 'target' parameter to Run/RunWait can contain both the target program name plus any parameters required separated by spaces. If the target path\name contains spaces as well then the system has to guess which of the beginning space-delimited parts refers to the target program (with the rest being taken as parameters). It does this by consecutively adding space-delimited items and checking if there is something that can be executed at that location. In your case it found the wrong program to run.

The way to resolve this is to include double quotes around the target program like this:

Code: Select all

RunWait, "K:\BEST\FXU\Makro til P6\FlexManager\Release\Afbestil rejse P6 Id.exe" "25640562"

With quotes around the program to be run there is no guesswork required and the correct program will be run.

Edit: I’ve suggested a documentation improvement for the Run/RunWait command.

Cheers

[lexikos]

This is standard OS behaviour.

If you are using a long file name that contains a space, use quoted strings to indicate where the file name ends and the arguments begin; otherwise, the file name is ambiguous. For example, consider the string "c:\program files\sub dir\program name". This string can be interpreted in a number of ways. The system tries to interpret the possibilities in the following order:

1. c:\program.exe
2. c:\program files\sub.exe
3. c:\program files\sub dir\program.exe
4. c:\program files\sub dir\program name.exe

Source: CreateProcessW function (processthreadsapi.h) - Win32 apps | Microsoft Docs

The lesson you should take from this is that you should always use quote marks when the target program path/name might contain spaces (and I don't just mean for the Run command).

If you specify a verb (e.g. by prefixing the Target parameter with open or *open and a space), this forces AutoHotkey to perform its own minimal parsing of the Target parameter and call ShellExecuteEx instead of CreateProcess. In that case, AutoHotkey treats the .exe as the end of the program name, since quote marks are not present.