0

As a continuation to this question, can someone explain where the Run dialogue window obtains explorer.exe directory locations that match up with discrete directory names, e.g., "documents", "videos", "downloads", etc? Not to be confused with %path%, or Library versions of these directories. I assumed it would be in registry somewhere, similar to app path (related), but can't seem to find it on my own.

Arctiic
  • 1,001
  • 1
  • 6
  • 23

1 Answers1

1

It doesn't look up directory locations specifically – it really just uses the same %path% lookup procedure for all inputs that don't contain a colon or a (back)slash.

First the input is looked up in your user profile directory, known as %UserProfile%1 and usually located at C:\Users\<name> since Vista. You can run . to quickly open the directory itself.

This isn't limited to built-in directories; the Run dialog will open anything that's a valid filename within the current directory (including files). I believe it just uses ShellExecuteEx() under the hood, which is the standard "open this path like Explorer would" Win32 function.

If there is no match in the current directory, the Run dialog will search %path% for matches. For example, entering "system32" will open "C:\Windows\System32", in the exact same way that entering "notepad" would open "C:\Windows\notepad.exe". It doesn't matter that one is a directory and the other is an executable; the Run dialog just uses the default "shell open" on both.

1 Not to be confused with %HomeDrive%%HomePath%. If your account is customized such that the home location is different from the user profile location, your programs will be started with "home" as their initial directory but the Run dialog will still use the "user profile" directory.

u1686_grawity
  • 426,297
  • 64
  • 894
  • 966
  • Okay, that explains some things. I just changed my profile home path value, so I'll see if it now finds the correct directories. However, adding them to environmental paths doesn't seem to work without wrapping with %? – Arctiic Jan 27 '23 at 11:44
  • Not sure what you mean by that? – u1686_grawity Jan 27 '23 at 11:45
  • My other post details this, but the reason I'm trying to determine this is due to my attempt to change those directory locations (videos, documents, downloads, etc.) to a non-default location, `D:\users\*username*`, as I didn't wish for them to be stored on my M.2. I noticed that changing them through Properties > Location failed to update whereever `run` is getting their location from, as it would continue to try the old default location or output an error (verified by creating the respective folders in old locations and they would open). My profile's home path is left blank, so I think... – Arctiic Jan 28 '23 at 00:06
  • ...that might be why it keeps looking at the default location, I'll try updating it and seeing if it will fix the behavior. @user1686 – Arctiic Jan 28 '23 at 00:08
  • Hmm, what you mentioned about env path makes it sound as if, once added to %PATH%, the folders should open from `run` even when entered without wrapping them in %'s. However, this doesn't appear to be the behavior I'm observing? It simply gives an error for me. – Arctiic Jan 28 '23 at 00:13
  • Uh, you don't wrap folder names in %'s, you wrap _environment variable_ names in %'s. An environment variable is not a folder name. – u1686_grawity Jan 28 '23 at 11:27
  • Apologies for the incorrect vernacular usage, but from the functional perspective am I mistaken? I.e., you add a directory as an environmental variable's value, and in order to call on that variable through the `Run` dialogue, you need to input %*variable*% for it to work, right? – Arctiic Jan 28 '23 at 17:01
  • Yes, if you want to reference the value of a variable, you always need to use `%variable%`. (The expansion doesn't really care _what_ is being expanded, though – it doesn't look for folders specifically; it only does text substitution and the result still goes through the same process as above.) If you set "Music=D:\Data\Music" and expect to open it by typing just "Music", that will never work. – u1686_grawity Jan 28 '23 at 17:05
  • 1
    Regarding %PATH% though, remember that it doesn't list the individual items – it lists locations _containing_ items. So if you add D:\Data\Music to %PATH%, typing "Music" will **not** find it (but it will find e.g. D:\Data\Music\Old if you type "Old"); if you wanted the Music directory to be openable this way you would need to add its **parent** D:\Data to %PATH%. – u1686_grawity Jan 28 '23 at 17:07
  • (Or alternatively, you could create a standard .lnk shortcut in your user profile directory pointing to D:\Data\Music; typing "Music" will then find the file named "Music.lnk" and launch it, causing Explorer to open the directory you want.) – u1686_grawity Jan 28 '23 at 17:11
  • And ***that*** was the exact detail I've been missing this entire time! Thank you very much for that, it might appear to be obvious to you but from my amateur perspective it was not in the *least* bit intuitive that a layer of recursion woud be necessary for that behavior to emerge. I've been completely perplexed as to what mechanic enables it and already wrote off environmental variables in my mind despite thinking it *should* have been it, I somehow just missed that tidbit all these years. – Arctiic Jan 28 '23 at 17:24
  • No, I believe that's called "missing the forest for the trees" – focusing too much on the Run dialog opening directories specifically and forgetting the possibility that it has no special treatment for directories at all. – u1686_grawity Jan 28 '23 at 17:48
  • The reason it appears to be obvious is because that's exactly how %PATH% already works for its **primary** use (running programs) – e.g. I've used %PATH% to run executables (and not quite executables, e.g. "services.msc"), from that I know that it doesn't list each .exe file individually but is always a list of directories that are to be searched for the filename, therefore I know that _every_ PATH lookup involves one layer of recursion. "Running" a directory as described in this post follows the same rules as "running" a file, it doesn't add any more layers than that. – u1686_grawity Jan 28 '23 at 17:49
  • Okay, now that you put it that way I'm able to conceptualize the actual intended usage and behavior, and it frankly makes much more sense now. Having accumulated most of my knowledge through trial and error over the years, not to mention my lack of any formal training or education, my perceptions were largely developed and reenforced from frontend user space interactions. Even having now gained **much** more knowledge on the programmatic side, there are still misconceptions that have become so immutably ingrained that I'm completely blind to what should be obvious. – Arctiic Jan 28 '23 at 18:20
  • Anecdotally, I'm reminded of a friend who had a younger sibling still too young to know the alphabet, yet was astute enough to learn the exact sequence of keyboard inputs to open a web browser, navigate to YouTube, and load Disney videos without any assistance. Asking him how Disney is spelled though, he didn't know the answer until *much* later on. – Arctiic Jan 28 '23 at 18:33