* Moving files is unintuitive. It should be [cmd+x] then [cmd+v]. Instead it's [cmd+c] then [option+cmd+v], and this behavior is not afforded in the UI, you just have to look it up somewhere.
* Search within finder does not search the current context by default, it searches your entire computer. "But you can change this setting!" You shouldn't have to change this setting, and most people don't know it's even there.
* Renaming multiple files is a chore. You expect to rename a file, then press tab to highlight the next file, and begin typing. Instead, you... do some combination of enter, tab, then enter again, except it never quite works the way you expect, and sometimes the file moves because the sorting changes after you pressed enter the first time, and for some reason pressing tab actually moves you to the next folder.
* Speaking of pressing [enter] on files, that should open them, not rename them.
* For that matter, pressing [delete] should delete files. You just have to know that the key for that is [cmd+delete], and that deleting things is called moving them to the trash.
* In general, the number of contextual commands you just have to discover by trial and error, or by looking them up on the internet, because they are hidden in the UI. Even the right-click menu doesn't list things like "open in slideshow", because the right click menu has a secret menu of its own which you have to press [cmd] to see.
* There is no preview panel visible by default, that's another option you have to turn on, like showing the file path. This stuff should all be on by default.
* You have to view file info in a separate window.
* It's not clear to me why I can't close Finder by pressing [cmd+q]. Quitting finder is usually all I want to do when it's open.
That's discoverable by holding down Option while the Edit menu is open. This pattern of "revealing" additional functions with modifiers in menus has existed on macOS for a very long time.
> Speaking of pressing [enter] on files, that should open them, not rename them.
> For that matter, pressing [delete] should delete files. You just have to know that the key for that is [cmd+delete], and that deleting things is called moving them to the trash.
Adding a modifier to these functions helps prevent accidental irritating (opening 500 selected files) or potentially destructive (moving selected files to the trash) actions due to fat fingering, which is a particularly likely occurrence on laptops where edge keys like delete and return are easy to accidentally hit just moving around one's laptop. The accidental opening by hitting return one is something I've done several times over the years and it's never not infuriating.
On Windows, deleting a file moves it to the Recycle Bin which is functionally equivalent to what macOS does. In fact off the top of my head I don't know of a modern desktop environment that just directly deletes files without recourse.
> It's not clear to me why I can't close Finder by pressing [cmd+q]. Quitting finder is usually all I want to do when it's open.
Because the Finder powers the desktop too and its windows are not separate processes. In fact no application on macOS spawns additional windows as separate processes, that's a Windows/Linux thing.
Ironically, holding down "Option" to see hidden menu items is not discoverable at all. Most people will only ever do it by accident. The point is that anything commonly desired should not be hidden like that.
There's also the 'Help' menu in Finder that has the manual, tips, and menu search functionality.
That Finder and the desktop are a single process is an implementation detail that should be hidden from UI mechanisms like this.
So, not discoverable at all.
If you want it different, you want Linux or a BSD.
I guess I could also question the proposition that Apple doesn't change things people like about Macs. I could list a few examples of them doing that, too.
Thanks for the suggestion that I read a book.
> Search within finder does not search the current context by default, it searches your entire computer. "But you can change this setting!" You shouldn't have to change this setting, and most people don't know it's even there.
The default behavior used to be great, ~10 years ago (extremely snappy search scoped to the current folder). The change to searching the whole computer with significant lag was an absurd and mysterious regression.
It’s like the difference between US vs. UK spelling conventions. A British person saying “Americans are bad at spelling words” is just trolling.
Apologies, but what do you expect to happen to the file in-between the cut and the paste? Cut content exists only on the pasteboard. If I cut a sentence from a document and then cut another sentence, the first sentence is effectively gone (without an additional clipboard manager).
This is why they went with the select-and-copy and select-and-move operations instead, and mapped them onto the copy/paste system. A true 'cut' would be too destructive.
I'd expect that nothing will happen, Cut will wait for paste operation. It's not delete, where content is gone immediately. If no paste will follow, then Cut is not executed. Cut marks file for move operation, if no move is executed, then nothing will be lost.
> If I cut a sentence from a document and then cut another sentence, the first sentence is effectively gone (without an additional clipboard manager).
We're talking about files here, not text. Text behaves differently. I'd argue that Cut operation as it is in text editors, is not logical but it is what it is and people are used to it. For deleting there's Delete operation, Cut should not be equal to Delete in some occasions.
Well, that's exactly how Finder works, isn't it? Cmd+C marks files, Cmd+V copies them, Cmd+Opt+V moves them.
On Windows, the cut file is dimmed out after you press [cmd+x] to indicate something has happened.
In my mind the only advantage the Windows way has is that it belongs to the more popular platform.
This bites me on fake FAT filesystems over USB for hardware development kits, and I usually just turn those features off. The heuristics there are often terrible, and I'd rather create a build system that writes a new image, instead of doing manual drag-and-drops.
1. Defaults to the columnar format. It's crazy - to move from a parent to child you've to move the mouse the whole width of the column. Whereas in Windows 3.1 File Manager, you'd have to move less than 10 pixels.
2. Now you could switch to the List View. But in Windows 3.1 File Manager, I can see a tree of directories on the left, and the directory contents on the right. That IMO is way cleaner than a single pane. Navigating to a child directory in the right pane also synchronizes the tree on the left pane. I can't be sure about the last one though because Win 3.1 was nearly 3 decades back, but I that's how it works today.
Gnome File and Finder both have such issue. Gnome file manager at least provide ctrl + L.
If the path bar is showing a folder, you can right click it and select "Open in terminal".
The resulting path input modal even supports tab completion.
The Finder has an equivalent with Command-Shift-G, and if that key shortcut is too cumbersome it (along with all other Mac menu items) can be re-bound in System Preferences under the Keyboard prefpane.
Most of the things mentioned in this comment chain are easily discoverable in the Finder's menus… it really pays to peruse menus in Mac apps when searching for a function.
This will copy either the directory (if no selection) or the selected file(s).
If you enable the path bar, I believe this is also a copyable element.
Finally, dropping a file or directory into a plain text control that cannot take file or folder references (like this HN comment box) will fall back to the path name.
Is that standard now, or did I add it long ago and forget?
#!/usr/bin/env bash
####################
# Description: Get the path of the most recently used Finder window
# Author: Ancapistani
# Version: 1.0.0
####################
osascript -e 'tell application "Finder"'\
-e "if (${1-1} <= (count Finder windows)) then"\
-e "get POSIX path of (target of window ${1-1} as alias)"\
-e 'else' \
-e 'get POSIX path of (desktop as alias)'\
-e 'end if' \
-e 'end tell';