Unix-type "locate" on Windows?

Question

Using the Windows CLI (cmd), how does one locate a file that he knows part of the name of? For instance, every single Windows workstation installs javac in a different location, how would one find it from the Windows CLI (cmd)?

Googling I see mention only of using the Windows Explorer (file manager) GUI or downloading some freeware application. Does Windows really not have a locate command built in? Do the server editions have it? I do not want to install cygwin or anything else, these are typically not my machines.

Answer 1

You should be able to do what you need to do with dir:

dir [filename] /s

Replace [filename] with the filename you're looking for, you should be able to use wildcards. /s makes it search sub-directories so if you need to you can start in the root of C: and have it check the entire drive.

Answer 2

Nobody talks about "where" command? it search executable file in PATH of current environment.

where <executable>

c:\ where
The syntax of this command is:

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

Description:
    Displays the location of files that match the search pattern.
    By default, the search is done along the current directory and
    in the paths specified by the PATH environment variable.

Answer 3

Windos has the most straightforward answer. But if you're fond of the command line, you may want to look at powershell too. To accomplish the same type of search you'd use

get-childitem [starting path eg c:\users\] -filter [wildcarded search or filename] -recurse

Which has the nice side benefit of being able to be pumped into a handy foreach statement and run a process against the search results.

get-childitem [starting path eg c:\users\] -filter [wildcarded search or filename] -recurse |
    foreach ($_){
          [do something to $_.fullname , like maybe display my image file or relocate it etc..]
    }

Answer 4

I simply got a locate program for Windows. You just need to follow the read me instructions and copy the .dll files and .exe to system32.

Alternative includes adding the program path to the environment variable PATH.

The idea is to get locate on Windows if you're looking for something "like" locate. :)

Answer 5

The question is somewhat ambiguous.

You want to locate a file (stated in the body of the OP), but you also want a "locate-type" command/app (stated in the title). There is one subtle consideration with huge implications. You can locate with two different methods:

1. Searching the target tree structure directly in each search (slow).

2. First creating a database of the target tree structure (may be time-consuming), and then locating by searching the database (very fast). The database has to be updated periodically to obtain good results in searches. See http://en.wikipedia.org/wiki/Locate_%28Unix%29.

Unix locate is of "type 2", but as per the body of your OP, you would be ok with any of the two methods. Moreover, you ask specifically about CLI options.

I list below some options, and I specify whether they are CLI / GUI, type 1 / 2, and I add some comments.

1. http://locate32.cogit.net/ (already pointed at by John T and then by Cheeku). GUI, type 2. There is a portable version. Outstanding easiness of use, and configurability. Very similar to Unix locate (which I used and liked a lot).
   Note: Being used to Unix's Updatedb taking quite long to update a database (of course, it depends on the size of the scanned tree), I find locate32 extremely fast. I do not know how it can be so much improved.

2. http://sourceforge.net/projects/winlocate/ CLI, type 2.

3. dir [filename] /s, the solution by Windos. CLI, type 1.

4. gci ..., the solution by OldWolf. CLI, type 1.

5. http://gnuwin32.sourceforge.net/packages/findutils.htm CLI, type 2.

6. Everything GUI, type ?.

Answer 6

I created a PowerShell port for locate and updatedb. Uses SQLite as a backend, and has an auto installer. Just

.\Invoke-Locate.ps1 -install. 

locates take about 300ms/query.

Then

locate whatever

and you're set.

https://gallery.technet.microsoft.com/scriptcenter/Invoke-Locate-PowerShell-0aa2673a

Answer 7

No need to install by hand. See http://chocolatey.org

choco install winlocate

Restart shell environment

Updatedb.bat -a
Locate.bat somefile

Answer 8

I know this one was answered a long time ago, however this is my script to simulate the locate function used in unix/linux

Save this as locate.bat and place in System32 OR run from directory it's stored in. Takes one parameter like this "cmd> locate javac.exe"

The locate /c switch (as a 2nd parameter will count the number of instances ) and locate /? will display the help text

@echo off 
if [%1]==[] goto :usage
if [%1] == [/?] (
:usage
echo Usage: 
echo locate "filename" { optional } /c { shows counter }
echo note:  results are exported to C:\temp\result.txt
goto :EOF
) else (
     setlocal EnableDelayedExpansion
     dir /a /b /s C:\ | findstr /I "%1" > C:\temp\result.txt 
     type C:\temp\result.txt | more /S
     set counter=0
     if [%2] == [/c] (
         for /F %%i in ('type C:\temp\result.txt') do (
             set /a counter=!counter!+1
         )
         echo Total Matches: !counter!
      ) 
)
endlocal > nul  
goto :EOF

EDIT: (Updated Script, more organized and can handle a wider variety of situations, such as allowing for any search term not just a filename)

@echo off
::initialize local varaibles to default values
setlocal

set file=
set directory=
set toppath=top

::some switch validation ( from command line )
if [%1]==[] goto :Usage
if [%1]==[/?] goto :Usage
if [%1]==[/help] goto :Usage

::handle switches with if structures
if [%2]==[/c] (
     set count=yes
) ELSE (
     if [%2]==[/t] ( if [%3]==[] (goto :Usage) else (set toppath=%3))   
     if [%4]==[/c] (
          set count=yes
     ) ELSE (
          set count=
     )
)
set file=%1

::Directory Validation ( Goto jumps possible, along with raptors ) 
if [%toppath%] == [] ( 
    IF NOT EXIST %toppath% goto :FolderInvalid 
) else (
    if [%toppath%] neq [top] set directory=%toppath%
)
set toppath=
setlocal EnableDelayedExpansion

::Run Bulk of the Script
dir /a /b /s %directory% | findstr /I "%file%" > C:\temp\result.txt 
type C:\temp\result.txt | more /S
     set counter=0
     if [%count%]==[yes] (
         for /F %%i in ('type C:\temp\result.txt') do (
             set /a counter=!counter!+1
     )
     echo Total Matches: !counter!
) 

goto :End

:Usage
echo locate ^[file^] {term^/file to look for} ^| ^[^/t^] {dir^/subdirs to search} ^| ^[^/c^] {show counter}
echo.
echo notes to user:  1. Results are exported to C:\temp\result.txt
echo                 2. Default search dir is the current unless specified by ^/t switch
echo                 3. For best results write switches in order given ! ( or beware of raptors )
goto :End

:FolderInvalid
echo Folder Invalid

:End
endlocal > nul

Answer 9

For future space Windows historians: we have been blessed with Everything Search. Picture dmenu+find+mlocate rolled up into a tight, pretty little Windows service w/ cli options. Except this thing updates its index in real time. Nothing on Linux comes close. It will be one of the few times you will say "gee I wish this darn kernel was a little more Microsofty"

Answer 10

The short answer is that there is no exact equivalent on Windows. The workaround is to use the dir command. This is a directory list command that supports special characters, and can be used as pointed out in the accepted answer.

The Locate command on many Unix like systems is an index based search. It works in tandem with the Updatedb command that indexes file systems. Since it is an index based search, it is usually much faster than text based search commands such as dir and find on Unix, especially when searching deep directory hierarchies.

Answer 11

I'm not aware of any CLI method to do this in Windows. Keep in mind that the Windows CLI has been abandoned by common users, so it offers a generally less mature set of tools. Your best bet might be using the gnu find in Windows, which you can get from GnuWin32. If you're developing a script, you'd just have to include find.exe and its dependencies with the script (don't worry, it's not very big).