I can't seem to find anything about a Powershell equivalent of the where command from cmd. Should I just call it from cmd or is there something more elegant in PS?


6 Answers 6


Use the Get-Command commandlet passing it the name of the executable. It populates the Path property of the returned object (of type ApplicationInfo) with the fully resolved path to the executable.

# ~> (get-command notepad.exe).Path
  • 30
    If you find yourself using this a lot, you can abbreviate the command as gcm instead of typing the whole Get-Command word every time
    – Moshe Katz
    Nov 18, 2013 at 20:38
  • 1
    @MosheKatz Thank you! gcm notepad has been working perfect for me when I just want to see which file am I calling.
    – Shawn Wang
    Jul 28, 2017 at 18:07
  • 5
    And this, boys and girls, is how you over-complicate useful things that were already right. If it isn't broken, don't fix it.
    – AFP_555
    Apr 18, 2018 at 14:39
  • Thank you very much for this command. I can Add-Type without hardcoding the path. Feb 23, 2019 at 3:07
  • Source works the same, see answer below Jul 16, 2020 at 13:43

If you're just looking to have the same functionality without invoking cmd, you can call where.exe from powershell, as long as C:\Windows\System32 is in your path. The command where (without the .exe) is aliased to Where-Object, so just specify the full name.

PS C:\Users\alec> where
cmdlet Where-Object at command pipeline position 1

PS C:\Users\alec> where.exe
The syntax of this command is:

WHERE [/R dir] [/Q] [/F] [/T] pattern...

where isn't a built in cmd command. It's a standalone application (where.exe), so strictly speaking PowerShell doesn't "need a replacement".

So why doesn't where work in PowerShell? It seems to do nothing:

PS C:\> where where
PS C:\>

By default where is aliased to a built-in PS cmdlet.

PS C:\> get-help where


Well, that's great to know, but is there a way to avoid calling where-object when trying to call where.exe?

The answer is, yes.

Option 1

Call where.exe with extension. (This is a handy way to work around other aliasing and file-extension prioritisation issues.)

PS C:\> where.exe where

Option 2

Remove the alias.

PS C:\> Remove-Item alias:\where -Force
PS C:\> where where

Side Notes

zdan's answer proposes using Get-Command as an alternative. Although it's a little more verbose (even when using the default gcm alias), it has richer functionality than where.exe. If used in scripting, do pay attention to the subtle differences between the two. E.g. where.exe returns all matches, whereas Get-Command returns only the first result unless you include the optional -TotalCount parameter.

PS C:\> where.exe notepad
PS C:\> (gcm notepad).Path
PS C:\> (gcm notepad -TotalCount 5).Path
PS C:\>

And finally, if you remove the default where alias, you might also consider reassigning that as an alias to Get-Command. (But this would probably be of dubious benefit.)

PS C:\> Set-Alias where Get-Command
PS C:\> where notepad

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Application     notepad.exe                                        10.0.15... C:\WINDOWS\system32\notepad.exe

PS C:\> (where notepad).Path
PS C:\>
  • Like the alias idea, cool stuff!
    Apr 15, 2020 at 11:43
  • 1
    (gcm some_program -All).Path replicates the default behavior of where.exe
    – Marduk
    Nov 5, 2020 at 15:40

Get-ChildItem C:\SomeDir -Recurse *.dll

That's pretty much what the old where.exe does... was there more specific functionality that you're trying to mimic?

Edit: In response to Joshua's comment... oh, you want to search your PATH environment variables too? No problem.

Foreach($_ In $Env:Path -Split ';')
    Get-ChildItem $_ -Recurse *.dll
  • 2
    "where" also searches the PATH as well Nov 13, 2013 at 0:38
  • 5
    oh, you want to search your PATH environment variables too? Um, yes, that’s the whole point to where, otherwise you can just use dir. Der. :-P
    – Synetech
    Nov 19, 2013 at 2:26

Both Path and Source from Get-Command work the same

> (Get-Command notepad).Path
> (Get-Command notepad).Source

Who had this idea to define aliases so that you can not call system executables present in PATH?

Anyways, most reliable solution would be, to define an alias, I am used to:

PS H:\> Set-Alias which where.exe
PS H:\> which notepad
PS H:\>

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy