good chemistry is complicated,
and a little bit messy -LW
Re^3: System vs. User module version of List::Utilby afoken (Abbot)
|on Jun 19, 2017 at 20:18 UTC||Need Help??|
"Windows systems do not have an equivalent." Apart from:
Well, as much as I hate it, but that's nonsense:
dir /s filename (on DOS/Windows) is a stupid tree scanner that has to read at least all directories starting at the current directory. It is roughly equivalent to find . -name filename.
That's also a stupid tree scanner, according to Microsoft
find is yet another stupid tree scanner. See GNU documentation. Apart from that, findutils contain locate, see above.
Yeah, right. You could use locate on Windows. Like you could use it on Unix. With a database optimized for searching for filenames. Updated every now and then, and not always installed. Especially not installed on any "fresh" Windows installation. It is not even part of the installation media.
Windows has an indexing service, optional for NT 4, standard since W2k, replaced with Windows Search indexer in Vista. But both index file names AND file contents, so they are not really comparable to locate. Yes, I'm aware that the newer one has a search API, but it looks quite scary. Maybe it's quite easy to implement something that has a command line interface similar to locate, but it is not available out-of-the-box. Plus, neiter the Indexing Service nor Windows Search index all local files. Directories outside Microsoft's plan for where you should store your data are not scanned by default.
locate's updatedb can be configured by updatedb.conf, that file usually excludes virtual files, temp directories, and files on network shares and removable media. Directories outside the FHS are usually indexed. A sane updatedb.conf is usually bundled with locate when you use a binary or source distribution of Linux, and I'd expect the same for the BSDs.
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)