Anecdotally, files called . and .. seem to often (always?) be present inside otherwise 'empty' directories on macOS.


Create a new directory (with nothing in it)

mkdir test

cd into it

cd test

and list its contents

ls -a
.   ..

What exactly are these files . and ..?

  • 4
    If you use ls -aF it should then show that these aren't files. – Dewi Morgan Apr 16 at 0:11
  • 3
    @DewiMorgan nice. It returns ./ ../ which (I think?) confirms they're directories. – stevec Apr 17 at 1:58

Technically and practically, they represent directory entries for the current directory (.) and the parent directory (..), respectively.

So cd . always keeps you in the current directory (useful mainly in scripts when a directory is assigned to a variable and the value should represent just the current directory), whereas cd .. always takes you one level up (unless you are already at /, in which case .. is the same as .).

  • 18
    That makes complete sense now, given commands like cd ../ and ./script.sh. Thank you for joining the... dots – stevec Apr 15 at 5:51
  • 3
    A fun example: cd some/dir/ is exactly equal to cd ./other/./.././some/./././dir (assuming your current directory has some other directory in it too) – scohe001 Apr 15 at 14:16
  • 5
    @scohe001 assumuming no symlinks or a shell who is able to handle them properly – nohillside Apr 15 at 14:19

In practical terms, the folders named . and .. refer to the current folder and its parent folder respectively. For the root directory (referred to as /) the .. name simply refers to itself.

The "." and ".." names are special in that they do not necessarily represent something actually stored in the file system on the disk, like other names. In some file systems there are actually hard links named "." and "..", but other file systems do not store them as such.

Similarly on modern operating systems, like macOS, it is possible to mount several file systems onto the same folder structure. At the boundaries of such intersections, the ".." doesn't refer to a link stored inside that file system, but rather refers to a folder in a completely different file system.

In those case these names are purely virtual, while still providing the same functionality.

The presence of these names are actually dictated by the POSIX standard for operating systems, which macOS has been certified against since 10.5. In particular the standard specifies that:

The special filename dot shall refer to the directory specified by its predecessor. The special filename dot-dot shall refer to the parent directory of its predecessor directory. As a special case, in the root directory, dot-dot may refer to the root directory itself.

When using the command line interface, you'll quickly become used to the .. name, as you often use commands like cd .. to go the parent folder.

The . name serves an important function in terms of security, as it is used to indicate to the shell (the command line interface) that you want to run a program located in the current folder instead of a system supplied command in another location. Imagine that we did not have the . name, and the system simply started the program in the current folder without having it explicitly stated - then a malicious user could add programs with names of common commands to folders on the computer, and when another user came across this folder and intended to run a common command (such as ls for listing files or cd for changing directory) they would instead be starting a malicious program.

Historically these names . and .. have been used on many different operating systems, including for example Windows and Linux. It originates from the Multics operating system (originally from 1969), which was the first operating system to feature a hierarchical file system. Multics was one of the main inspirations behind what eventually became Unix, and in the development process they places files according to a "directory" (current folder) and to "directory's directory" (parent folder). These terms were abbreviated 'd' and 'dd', and were eventually pronounced 'dot' and 'dot-dot' - making way for their current representation

  • 1
    Predates Windows - that was a feature of MS-DOS, on which Windows was (at least originally) based. I'm not sure if Macs have always had this - pre-OS10 this might not have been a thing, but OS10 was based on UNIX, so it inherited that functionality. DOS/Windows and UNIX/Linux machines had it for decades before that. – Darrel Hoffman Apr 15 at 21:26
  • 7
    Ofcourse it predates Windows... if you read the answer, I wrote the origin of it as being in approx 1969... which is about 12 years before MS-DOS... which explains where DOS had the idea from... – jksoegaard Apr 15 at 23:03
  • 4
    Oh, and by the way - DOS didn’t have this feature in its first versions. DOS 1.0 didn’t even have subdirectories at all. It got them later in around DOS 2.x by inspiration from Xenix (Microsoft’s Unix system at the time). And yes, pre-OS10 this was definitely a thing. Mac OS got a hierarchical file system in system 2.1 ~ 1985. This is why the file system was known as HFS, later to become HFS+ which was the default file system until quite recently, when APFS came along. – jksoegaard Apr 15 at 23:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .