Emacs on macOS, Part 2
The next issue I ran into was more complex. After fixing the packages, I wanted to browse my home folder on the Mac with Dired. I got an error that stated:
"Listing directory failed but 'access-file' worked". Huh? What’s that about?
When contents of a folder fails to list on a Mac, especially on more recent macOS versions, it usually means there’s a permission issue. In Catalina and Big Sur, even the Native Terminal app needs explicit access to the hard drive from the user. I always found this odd, but I guess I can see why: if you don’t know what the Terminal is and why it needs access (many users don’t, unfortunately), it’s a good idea to keep it locked. Giving Emacs explicit access to the hard drive and folders was a no-brainer, However, that didn’t help. I still received the same error message.
After some research on Stackexchange, I learned that the list (“ls”) command in macOS is different than the one in Linux. They both do the same thing and both historically date back to Unix, but they’ve developed somewhat differently. the Linux ls program is the GNU ls command, which is the one Emacs “knows” how to use. This version of ls is bundled with other command line tools inside a package called coreutils, which can be installed with Homebrew. That was my next step, but I still encountered the error.
The same place online that suggested installing coreutils also gave instructions to change the path for Bash on macOS, so it can be found. This made sense; after all, if Emacs can’t find the ls program, it would give the same error as if it’s not installed. So that was the next step. Zilch. The error persisted.
I was puzzled until a co-worker looked at this with me and noticed the path instructions are for bash (in
~/.bash_profile). Bash, as the Mac users among you know, is not the default shell on macOS since macOS Catalina; it is now ZSH. The file to configure ZSH is
~/.zshrc. That was a mistake that someone like me, who’s coming from Linux and used to Bash, would not know to change.
With the path changed in the ZSH configuration file, Emacs was finally able to find the ls program and list the directories. Well, most of them. The Desktop and the Documents folder were giving me permission denied error when I tried to list their contents. This was strange since I already gave Emacs full access to the hard drive. More online research followed. What I found was interesting.
On macOS, Emacs runs inside a Ruby wrapper (this detail is buried on the Emacs wiki). So, while it’s nice that I gave Emacs access to the hard drive, Ruby, which is (from my understanding) the “messenger” Emacs sends out to use the ls command in Dired, was denied access. The fix was to add Ruby to the access list under Security in macOS settings1.
Only after Ruby had access I was able to see all the local directories I wanted. It’s odd just how alienated macOS “feels” Emacs is. I understand the logic of what’s going on, but still, the notion that I need to customize so many things to let something as free and good as Emacs is something I’d grown to expect from Windows, not macOS. Oh well. C’est la Vie.
This doesn’t explain why other directories worked fine without giving Ruby explicit access. For example, I could view my Downloads folder just fine on the Mac. From what I read, I understand this has to do with the integration of iCloud, which the Desktop and the Document folders are a part of. My guess is that Ruby needs access to iCloud, or, that you don’t access these directories at all, but some sort of cloud integration that just seems like folders, when in fact they are not. Whatever the case may be, that was the fix. ↩︎