Winget PROCESSNAME and case

[joefiesta]

When I use " WINGET, prcname , processname ..." the name of the process may not EXACTLY match the name of the executable. Specifically, the case of the value of prcname may be different. What is returned by WINGET PROCESSNAME appears to be the name of the process as specified on the executable's COMMAND LINE.

So, for example, if I run "C:\myProgram.exe" via ahk using the following:

run "C:\MYPROGAM.EXE"

Winget, prcname, processname ... will return for prcname "MYPROGRAM.EXE".

Is this a bug? One can VERY EASILY consider it a bug in lieu of the following. When one looks at the process in task manager (god forbid you have windows10--does it even have a task manager. Last I looked the taskmanager therein was pathetic and displays almost nothing.) the taskmanger can show the "image path name" and "command line". The "image path name" is the TRUE value of the process's name (as to case). The "command line" shows how the user invoked the process.

[gregster]

(god forbid you have windows10--does it even have a task manager. Last I looked the taskmanager therein was pathetic and displays almost nothing.)

If I remember correctly, in the Win10 task manager I had to right-click on the listview headers (in 'more details' mode) to get to a menu that let me add some more columns with additional information like process name and PID (but perhaps you already did that). I am not totally sure with how much information it started out, though...

[gregster]

I am not sure if I understand your question correctly. If I use the Processname option with Winget I seem to get the same that I get when I look at the process name column in the task manager (which is different from the 'name' and 'command line' columns - but these descriptions are different in my task manager, because I don't use the english locale). That seems correct to me...

But I cannot identify a "image path name" in my locale (on Win 10) - so I am not sure if I am on the same page.

[jeeswg]

- I agree joefiesta, ideally this should be fixed.
- When you use WinGet with ProcessName or ProcessPath, the case of the name/path varies, depending on how the program was opened. My script provides a workaround to get the name/path with the correct case.
- (One way this affects me: I have a script that takes printscreens and records the process name in the filename, and the process name's case is inconsistent.)
- In my example below though, sometimes, even when the process is run with an incorrect case, WinGet gets it correctly. Perhaps this is something to do with file redirection, or perhaps there is some other explanation.

Code: Select all

w:: ;run process with incorrect case
;note: should be 'notepad.exe'
Run, C:\Windows\System32\NOTEpad.exe
Run, C:\Windows\SysWOW64\NOTEpad.exe
return

q:: ;get process name/path
WinGet, hWnd, ID, A
;if launched with an incorrect case,
;these will *probably* have the incorrect case
WinGet, vPName, ProcessName, % "ahk_id " hWnd
WinGet, vPPath, ProcessPath, % "ahk_id " hWnd
;correct case:
Loop, Files, % vPPath, FD
	vPPath2 := A_LoopFileLongPath
SplitPath, vPPath2, vPName2
MsgBox, % vPName "`r`n" vPPath "`r`n" vPName2 "`r`n" vPPath2
return

[jeeswg]

- Actually, one principle of programming is to do the minimum of work. So it might be better to get the path with what might be the incorrect case, and fix it afterwards if desired. (As I demonstrated, A_LoopFileLongPath can fix the case.)
- Another important principle is good documentation. It should be mentioned in the documentation. I've added it to my documentation extension tutorial.
- An important consideration, IIRC, it may be that sometimes WinGet ProcessName/ProcessPath only has access to a name and not a path, and so you couldn't guarantee for example, that WinGet ProcessName would give you the correct case. Thus, I would suppose that only ProcessPath could reliably give a path with the correct case. And since case correcting is unnecessary most of the time, it might be better to allow the user to make the choice, and to not do it automatically.