Colour ls and Symbolic Links

2026-10-10

I was looking at files on my macOS machine that were in the /tmp directory. The behaviour of ls confused me:

$ ls /tmp
/tmp
$

Instead of a listing of files and folders, the path was just echoed back at me. Perhaps if I enable colour you can figure out what was happening:

$ ls /tmp
/tmp
$

My shell is configured so ls runs ls --color. With this flag (or the equivalent -G flag) it will use different colours for different file types. Black for standard files, blue for directories, green for executables, and magenta for symbolic links. In macOS, /tmp is a symbolic link to /private/tmp. If we run ls without any flags it works, but if we tell it to use colour or sigils it does not follow the link.

$ /bin/ls /tmp
bashrc.log				dumps
...
$ /bin/ls -G /tmp
/tmp
$ /bin/ls -F /tmp
/tmp@
$ /bin/ls --color /tmp
/tmp

This behaviour doesn't happen on GNU ls, so it's something specific to Apple's ls (or its FreeBSD roots). Luckily, Apple's ls is part of macOS that is open source, so figuring out what's going wasn't too hard:

	/*
	 * If not -F, -P, -d, -i or -l options, follow any symbolic links listed on
	 * the command line, unless in color mode in which case we need to
	 * distinguish file type for a symbolic link itself and its target.
	 */
	if (!f_nofollow && !f_longform && !f_listdir && (!f_type || f_slash)
	    && !f_inode
#ifdef COLORLS
	    && !f_color
#endif
	    )
		fts_options |= FTS_COMFOLLOW;

No bug, intended behaviour. The exact same code and comment can be found in FreeBSD's ls source code.

I'm not sure I fully understand the reasoning in the comment. In my mind, if I'm using colour it only means I want what the output would be, but in colour. I don't see why the link following behaviour needs to be changed.