Could Apple consider replacing traditional BSD utilities with uutils?

As far as I know, back in the early 2000s, Steve Jobs frequently used Linux as a point of comparison to explain Mac OS X's POSIX compatibility in an accessible way. In my personal view, Apple has indeed been consciously or unconsciously aligning its development experience closer to Linux (perhaps even more so than traditional BSD).

Could Apple consider replacing traditional BSD utilities with uutils?

If you don't mind me asking, what are the specific behavior/tools/changes you'd like us to adopt?

The biggest reason our tools diverge from other systems is that their underlying implementations are in fact different. For example, "copyfile()", which has become the system core copy API, doesn't exist on Linux. In a similar vein, fts() (the directory enumeration API underneath copyfile) does exist on Linux (at least some versions), but it's generally considered a legacy API and isn't in wide use.

Critically, these differences aren't purely cosmetic. copyfile() doesn't just duplicate bytes from one file to another. Within a filesystem, it uses clonefile() to avoid unnecessary duplication and, in the even more complicated case, when copying between APFS volumes, it preserves clone state (copying an initial file, then using that file as the "source" for any related clones) to minimize directory growth crossing file systems. It also handles the complexity of determining exactly which file system attributes (and you'd be surprised at how complicated this is) should/should not be preserved, an issue which is both operating system and file system specific.

Switching to fts(), our adoption of it is tied to a very long (all the way back to Classic MacOS) preference for using "bulk" file metadata retrieval[1] instead of making individual syscalls for every file. Historically, this approach was less common on other operating systems, but it was a critical performance optimization on HFS+ and has significant benefits on HFS+.

That's an extended example from one area of the system, but the basic dynamic is common to many other system components. The core reason we maintain our own command line tools is simple: macOS doesn't work differently than other Unix systems[2].

All of that's why I asked my original question. That is, while the reasons above make it unlikely that we'll simply move to a different tool chain, it's certainly possible that we might include tools or implement options that were particularly useful. If there are specific things you'd like us to adopt, then the best approach is to file bugs explaining what you'd like us to do and why. Note that the "why" is the most important point there, not the what.

[1] Using a single syscall to retrieve the metadata about multiple files using a single syscall instead of making multiple syscalls for every file.

[2] Developers familiar with the history of Unix's divergence and evolution will note how broadly that statement could be applied.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

@DTS Engineer Thank you for your detailed explanation, especially the part about the underlying implementation of macOS. I realize that my original use of the word “replace” may have been too strong.

My main concern is not “uutils for the sake of uutils,” nor do I expect macOS to abandon its own underlying implementation. More precisely, what I want to discuss is whether macOS could adopt some common Linux command-line behaviors as a compatibility target for developers.

The underlying implementation can still be Apple’s own, and it can still use macOS’s own filesystem interfaces and optimized paths. What I am really concerned about is the user-visible behavior layer—for example command-line options, argument formats, output formats, and the portability of common scripts.

Many developers’ real workflows involve using macOS for local development environments, while servers, containers, and CI environments heavily use Linux. Problems often arise at this boundary. Installation scripts, build scripts, release scripts, and commands in project documentation may run directly on Linux, but fail in a clean macOS environment due to differences in basic tool options.

I do not think Apple should silently change long-standing BSD behaviors, as that could also break existing scripts. A safer direction might be incremental compatibility: preserving existing behavior, but adding some common Linux-compatible options where the semantics are clear, do not break macOS features, and do not break old scripts.

For example, issues like sed -i, common parsing options for date, output format options for stat, the behavior of readlink or realpath, and formatting capabilities of find. Each of these problems is small on its own, but together they affect script portability between macOS as a development environment and Linux servers and container environments.

Third-party package managers can help experienced users solve some of these problems (for example brew install coreutils uutils), but many scripts and project documentation must assume a clean macOS installation as the baseline. Therefore, the behavior of system-provided tools remains important.

So I would like to rephrase the request as: not replacing Apple’s existing tools, but selectively adding high-frequency Linux command-line compatibility support, provided it does not harm macOS filesystem semantics or system stability.