Bash and Paths on macOS

On macOS, there’s a little more than just the order of bash scripts messing with your path. Here’s an updated diagram showing the inside scoop.

I was helping a friend diagnose why a strange script-like string was appearing in their PATH whenever they logged in or created a new bash shell window. (Note: Catalina now defaults to using zsh, not bash.)

Bash has a number of different configuration files it checks, and some of those the user may have chained together. So far, even the best resource on the matter I’ve found doesn’t tell the whole story.

On Apple machines, bash walks through these set of scripts and invokes a path modification tool, too.

macOS Bash Scripts and Path Modifications (validated with macOS Mojave v10.14.6 on 2020-04-08)

In a nutshell, /etc/profile calls a utility called path_helper, and it reads a list from two places the /etc/paths file and everything in the /etc/paths.d directory.

My friend had thought the /etc/paths file was a script and not a list, and years ago had erroneously put an export PATH= statement in there. Because it came last (for his setup), he ignored the problem.

Our false start to correct is was upon seeing an export statement in the PATH itself, we assumed it was a faulty quoting problem in a script, so primarily went looking in the script files on the left side of the graph …and wasted what felt like hours doing so.

Only after using Bash’s return statement to short-circuit script executions and using a blunt hammer of renaming scripts out of execution’s way, and the problem still persisted, did deeper exploration go down the system resources.

I hope this diagram helps get others out of trouble.


UPDATE 2020-07-08: Bob Rudis caught a typo (the text said /etc/profile, where it should have said /etc/paths); he also shared a link to GNU’s Bash Startup Files.

Files with Jan 24, 1984, 3:00am Modification Times

Well, I think I finally figured our a problem that’s been bugging me for quite a while.

Every once in a while, especially if I’m using an external drive that’s acting weird or even the now defunct Lima, I’d occasionally see files that appeared grey in directory listings. You couldn’t rename them, you couldn’t display their contents (regardless of having size), etc.

Doing a ls -@Oaeln filename, showed nothing special.

Except… the date, which was always Jan 24, 1984, 3:00AM.

Ok, yes, that’s the Mac’s birthday — and some even call it an Easter Egg. But it’s likely an Easter Egg with a purpose.

The date appears as kind of a place holder, such as momentarily when a file is downloaded. And during that time, the system knows the file is incomplete, and this is just as good as any other way to mark it as such.

Turns out this also appears to be the way that corrupted files appear too.

For example, I synchronized some files with my Lima (which stores it on a USB disk somewhere), and if the synchronization process fails it’s supposed to pick up and try later. However, if that doesn’t happen, then partially transmitted data can reside there. And Lima’s going out of business was what led me to go try to pull all data, complete or not.

Attempting to inspect the contents of such files, such as on a Lima mount, appears to confirm this, resulting in a message of read error.

So. Grey files. It’s not a Happy Birthday to Us from Mac, but a date long past being used as a magic number.