If you enter "nonsense" in the location bar, it somehow adds "c:\windows\system32" in front of it and DO then tries to open "c:\Windows\system32\nonsene".
Is this by design?
I noticed while playing with onBeforeFolderChange(), that incoming (invalid) target-paths, get prefixed as well with "c:\win..".
My actual goal is, to fetch exactly what the user entered into the location bar, but that's hardly possible if I don't know what DO is going to add for cases like this.
That "c:\windows\system32" seems to be some strange default directory here, because if I enter "notepad.exe" in the location bar, DO enters the folder "C:\windows\system32" and selects "notepad.exe", even if the tab showed some folder on drive D:\ before.
It won't always be C:\Windows\System32; if you type a relative path into the location field then it is interpreted relative to the process's current directory. This is required in a few situations, although not when typing into the location field; that's just an artifact of other code. Since there's no reason to type just a folder name into the location field, it's not something we've coded special behaviour for. (To go to a folder relative to the current folder, you wouldn't even use the location field; just type into the lister.)
Regardless of all that, the script would not see what was typed before it was processed into an absolute path anyway, so what you're trying to do won't work regardless of which folder is used to turn the relative path into an absolute one.
There are lots of other ways to run a script with a string typed by the user, of course.
Well, I just had the idea to paste registry paths into the location field and let DO open regedit with that path. I kind of like the idea behind using the location field for that, because it is always right in front of me and registry paths are paths after all! o) See here: Command: GoRegistry (open reg-key by button or path-field)
Isn't that a superb usecase for "stealing" the location bar? o)