When performing a search:
Search the current folder
This is just speculation, but based on a conversation with my partner, there are two types of computer users. The first group makes use of hierarchical storage, consistent naming conventions, and other organizational tricks to give them a rough idea of where any file might be. The second group has never heard the term "file systems" and just stores everything with an arbitrary name in whatever location the originating application uses by default.
The first group would prefer to search the given directory, because the supplied context (of which folder to start the search in) drastically improves/speeds search results. The second group prefers to search the entire disk, because supplying that additional context is impossible - any file might appear anywhere.
The set intersection between the first group and "people who change their default settings" is much higher than it is with the second group. Consequently, the whole disk search is enabled by default.
Additionally, given the addition of an "All My Files" view in Finder (a feature which the first group would probably find baffling), Apple may also believe that the latter group outnumbers the former.
As search is fast enough nowadays with indexing, I'd rather have it search the whole disk every time than the directory I'm in just to realize I've put it someplace else.
Maybe we need a name for this behavior, I propose "idiot-driven-development".
defaults write com.apple.finder FXDefaultSearchScope -string "SCcf"It grabs my dot files and restores them, installs Homebrew and a bunch of programs, restores their plists (I have backup script that backs up all their plists) and writes a bunch of macOS settings via the `defaults write` command.
I can install/wipe macOS, follow the initial setting screens then when on the desktop I just connect to my NAS, copy over one script and run it in the Terminal to get my machine setup how I like it. It isn't perfect but it does about 97% of the work for me with the added bonus that it is consistent/reproducible for the most part so avoids me forgetting to change a setting some place.
I don't go crazy with it as I don't wipe my machine often enough to justify going all out with a fully automated system. Honestly it is less to save time and more to maintain consistency and have a 'documented as code' record of my environment setup (not quite infrastructure as code levels :)
# Trackpad: enable tap to click for this user and for the login screen
# Trackpad: map bottom right corner to right-click
# Disable “natural” (Lion-style) scrollingthis is old-lenovo-hacker style
Have you tried using the trackpad at its default settings? They actually make a ton of sense.
But it seems this project has fallen behind on PRs.
If you would like to have this fix, you can do this after cloning the repo:
git clone https://github.com/mathiasbynens/dotfiles && cd dotfiles
git fetch origin "+refs/pull/*/head:refs/remotes/origin/pr/*" && git cherry-pick origin/pr/963Use Alfred; I've been using it for years (10 maybe?) -- solves this problem and is extremely useful in general
Physical function keys are a must-have for every mac imo
Most new Macs come with full-size function keys, including a massive escape key the same size as the tab key. (At least on the en-US layout; can't speak to others.)
> Physical function keys are a must-have for every mac imo
While it wasn't the case for a while, they all do now.
Also four finger press for cmd+`
My only excuse for using Alfred is Dash (https://kapeli.com/dash), which integrates with Alfred, but these days so does just about every editor i use (including Vim, Emacs and Sublime Text), so i very rarely find myself using Alfred for it anymore.
One tool i do use at lot though is Hook (https://hookproductivity.com/).
¯\_(ツ)_/¯
Short answer Large number of users don’t use folders to organize their files. They just depend on searching everywhere to find files that may have dropped in any random location. Those people are less likely to find the setting that makes current folder the default search target.
Tip: Use the Help menu to search menu items. I just pressed ⌘? and typed "Find" and Find by Name… popped up.
Damn, been using macOS for 9 years now and just found out about this :o Thanks!
For example Photoshop (and its colleagues) is darn near impossible for me to use on Windows — and at least 50% of the reason is absence of the "Help" menu search feature.
Thank you for showing me that menu command! That'll be a lifesaver going forward. Usability achieved despite Apple design, not because of it.
I think it, yes, uses the Spotlight index for finding files, although I wouldn't be surprised if Alfred does some clever stuff on top of it too.
• Finder -> Preferences -> Advanced -> “When performing a search: Use the Previous Search Scope”
• On any Finder window, CMD-F -> Search: This Mac / [ FolderName ]
• On the loupe: “Filename” instead of “Everything”
Enjoy
I wrote my own solution using fd + sqlite + fzf but it's nowhere as fast as Everything, and it also requires me to focus the Terminal to use it.
How it catches all file writes to update that index near instantaneously, I have no idea.
I actually solved that by using the native macOS fsevents API which can watch the whole filesystem for changes, and I can instantly update the SQLite db I use for the index through that.
The problem is actually enumerating and searching the whole database, that's the slow part. Right now I have over 5 million rows in it and passing the SELECT results to fzf is the slowest part, taking a few seconds at least on an M1 Max.
I'm not sure how Everything presented the results so fast, with metadata and everything.
To your point regarding the slowness - in that case it's not really acting as an index though, is it, if you're scanning the whole list and passing it to fzf?
A proper fuzzy text search index (I think elastic and similar engines have these built-in) should yield orders of magnitude better performance.
In the end I might have to reimplement that in Swift with an always cached index and native Spotlight like search bar to really make this as easy to use as I want.
It's not practical to reach for the browser or Terminal to do this search.
Don't know if it works on Ventura, not upgrading until I know.
"This version of Finda (629.0.0+df7956) is not compatible with your operating system version (22.1.0). Press Enter to download the latest version or Command+ to quit."
EDIT: e-mailed the Developer, beta release coming tomorrow...
But then again, they will almost certainly screw it up, given that Windows Search still can't search my start menu reliably without pauses. And their history with acquisitions and integrating tech isn't very good.
With Windows, it is death by a thousand paper cuts. With Linux, you might get your arm chopped off while getting every device (or sleep) to work flawlessly, but once it works, it stays working. And small things like search work like you expect them to.
How did one dev managed to achieve what, apparently, no corporate entity ever has?
But I still use both, because Raycast doesn't support "folder search". I use folders in general because they don't change, and I usually know what I'm looking for. It (should be)/is also faster than searching all files.
When I'm looking for a file or it's contents, I'll fall back to spotlight
find . -type f -name “somestring”
but yeah that seems like more typing than one might want compared to a simple text entry field in the GUI.
(But your "find" will search in and below the current directory for files that exactly match "somestring".)
Yeah I realize that, but find is a stronger tool for the use case because it also allows wildcards to be specified in the name.
>your "find" will search in and below
Your "mdfind" will also search in and below the current directory.
find also has -depth which can be used to tell it to search only this directory.
mdfind has -onlyin to tell it what directory to search in, but it still recurses down. Does it have an option to limit this? Please do tell.
>for files that exactly match "somestring"
Well find also allows wildcards though. So not necessarily exactly… somestring is just an example.
Does mdfind allow wildcards?
Also find is fun to combine with grep to inspect file contents, especially since it has the -print0 option…
find . -type f -name "*.py" -print0 | xargs -0 grep somestring
`find . -type f -name \*.py -exec grep homestring {} \;`
I moved back to Windows a couple of years back. Spotlight is the second thing I miss most from macOS, with the first being Preview.
(https://news.ycombinator.com/item?id=33321000)
There seems to be two kind of searching people do. Some people want a search tool that searches in documents. Some people want a search tool that searches filenames.
Everything search is exclusively the second. I think I can count on one hand the number of times I've wanted to search inside documents in the last 10+ years (and for those cases, grep has worked fine, even on windows!).
For some reason, searching inside documents seems to be the default for both windows and os x search, and it's super annoying.
If you want to search documents you have created, I can imagine that you may not use the feature much. But e.g. for research papers, the downloaded copy rarely reflects the contents/authors, so it is really handy to be able to search the contents.
> For some reason, searching inside documents seems to be the default for both windows and os x search, and it's super annoying.
Weird. For me windows don't seem to search inside documents, or at least not in all documents.
I use it all the time to run binaries. For instance, "cmd-space mail". I wouldn't know the names of the files I want to search anyway.
The only way to fix it is to do some command line mumbo jumbo like rebuilding the Spotlight index and deleting index folders.
The search interface in finder has a builder for predicates (start a search then hit the plus on the right side of the search bar). There you can start to see some of the friendly prefixes for filesystem items such as extension:, kind:, date:, tag:.
You can also see the mass of file specific metadata - like width, audio bit rate, city, genre.
I have not, however, found a handy way to translate between English description, friendly prefix, and the internal query names like kMDItemContentType.
Fun aside - some of these used to work in the Mac app store - for instance, you could search for listed applications which could open exotic document types.
The "uselessness" IMHO is mostly in that it exposes the most simplistic interface possible, and people just don't know where to go from there (other than terminal users going `man mdfind` I suppose). That gap is only widened by how different it is from other filesystem-based mechanisms for power users, which have more established commonalities like regex and filesystem globbing.
https://github.com/sharkdp/fd#installation
assuming you are "in the current folder" in the terminal...
But maybe that more nostalgia than actual memories ;)
A Spotlight search never starts a scan of your disk. The disk is always fully indexed and returns results out of the index very fast. The only exception is typically when the system is updated (or some other big event) and it reindexes everything.
That being said, as others have pointed out, there is a setting to make a Finder window search apply only to the directory in the current window.
All I want is to hit Command-F to quickly search the filenames in the current folder (not start a sluggish scan of my entire hard disk). There used to be workarounds for this, but then they removed "Find by Name..." from Finder just to make our lives harder. Does anyone know a workable alternative?