I'm just curious if there's a standard computer term that encompasses everything in a directory, instead of always having to mention "files" and "(sub)directories/folders" separately. So you could say, loop through all the terms in dir_1.

And just to be clear, I'm looking for a singular term, as in my example sentence.

  • 5
    There are things that can be stored in a directory (the "objects" that you deal with), and there are the structural components of the filesystem (the metadata about those objects that the system uses internally). What you call them depends on the context, the perspective you're referring to. That's one reason why you're getting answers that range from "files" to "inodes". And terms like "entries" and "content" make sense in the context of what the directory contains, but you wouldn't refer to your files & subdirectories by those terms. Can you clarify which type of word you're looking for?
    – fixer1234
    Aug 3, 2019 at 6:17

6 Answers 6


The POSIX readdir documentation uses the word entry:

The readdir() function shall return a pointer to a structure representing the directory entry at the current position in the directory stream specified by the argument dirp, and position the directory stream at the next entry. It shall return a null pointer upon reaching the end of the directory stream. The structure dirent defined in the <dirent.h> header describes a directory entry.

  • 8
    Strictly, a file (in the POSIX sense) may have multiple directory entries (hard linked files, or any directory), or none at all (unlinked but still open files). The file and the entry are separate objects.
    – Kevin
    Aug 4, 2019 at 23:35

File. At least in POSIX-compliant systems.

3.164 File

An object that can be written to, or read from, or both. A file has certain attributes, including access permissions and type. File types include regular file, character special file, block special file, FIFO special file, symbolic link, socket, and directory. Other types of files may be supported by the implementation.


People saying "files" when they mean only "regular files" are not really POSIX-compliant. :)

You can learn what POSIX is from answers to this question. Various operating systems are POSIX-compliant (fully or mostly) or not. Without going into details, this answer applies to Unix and Unix-like systems (including macOS, Linux, BSD), but not to Windows family in general.

  • 27
    I really miss truly POSIX-compliant people :( Aug 3, 2019 at 19:56
  • 7
    @val unfortunately most people have an illegal space character in their name
    – OrangeDog
    Aug 5, 2019 at 13:57
  • 3
    @OrangeDog That could explain why many bash scripts fail on them Aug 5, 2019 at 14:10

Good question.

I use "contents" as a term that encompasses both files and subfolders.

For example: "We need to copy all of the contents of that directory."

  • 1
    This kinda duplicates Hannu's answer.
    – fixer1234
    Aug 2, 2019 at 20:44
  • 1
    Nope. "Content" is grammatically incorrect. "Contents" is the correct term here. "In the plural, 'contents' refers to the things contained in something." jakubmarian.com/content-vs-contents-in-english Aug 2, 2019 at 20:57
  • 1
    I guess it was kind of ambiguous, but I was looking for a singular term. I just added a clarification to my question.
    – Mason
    Aug 2, 2019 at 22:01

There are good answers that propose files and entries. (Go read them if you don't understand why those words fit, and remember that in POSIX "file" includes all types of inode (including directory), not just regular files). Directory entries (filenames) are references to files / inodes.

A file can have multiple names in different directories (link count > 1). The actual file data/inode isn't stored in the directory containing a filename for it.

But sane humans have no problem saying things like "read a file that's in some directory". It would be needlessly pedantic to bother always making the distinction between a file (inode + data) and the filename(s) / directory entries that refer to it.

Also note that directory entries in modern filesystems often also store a "type" field so programs like find don't need to stat(2) each file to check predicates like find -type f (regular file) vs. symlink or something. Or to find entries that are directories themselves when recursing. See Checking if a dir. entry returned by readdir is a directory, link or file. dent->d_type isn't showing the type on Stack Overflow.

A "path" like foo/bar or /a/b/foo/bar is a string that ends with a filename, but can use directories to refer to a filename that's not in the current directory. foo is a simple path and also a filename. But foo/bar is the name of a file, and also a path. But you could argue semantics that it's not "a filename". A path or pathname is something you can pass to a system call like POSIX open(2) or chdir(2) or Win32 OpenFile()

Your choice of terminology (file vs. filename vs. directory entry) will probably depend on context and what you're doing. e.g. reading the contents or inode metadata involves the actual file.

But just matching a glob expression against the name doesn't involve the file at all, just the filename / dir entry.

Directory entry is most appropriate when actually looping on a function like readdir(3), or for example "use ln to create a new directory entry referring to this file". When dealing with hardlinks, the term "dir entry" is usefully distinct from file, moreso than "filename".

But "name" also works. e.g. "a file with 2 names".

More often, you'd write a shell script using variable names like c_files=( *.c ). Or fn (for filename) is also a good local-use variable name.

Using entries=( *.c ) would feel weird. "entries" only feels right when talking about the process of looping over them to get filenames, not for the resulting set of filenames that match some filter.


Why not raise the abstraction level instead of using just "computer terms":
Step up to more general wording...

A mature filesystem stores content.

It allows 'files' and 'folders' as basic content.
Most often a 'folder' then may store sublevels of content...

Depending on the choice of filesystem there may be other content types.

  • Only Windows (and perhaps MacIntosh) systems have folders. Real filesystems have (sub)directories. And directories may contain many things other than files (though they may be abstracted to look like files). E.g. /dev and /proc on Linux, the entries of which arguably don't contain "content".
    – jamesqf
    Aug 4, 2019 at 5:28
  • I refer to content as being folder/directory entries of differing types; all inclusive. Data files in themselves have content, but that content not normally for filesystem administration. (do you really need to differentiate folder/dir - on the general level?). /proc and /dev being volatile and dynamic in kind doesn't make the folder/dir have less of "content".
    – Hannu
    Aug 4, 2019 at 11:49

I like the term tree and indeed in Linux there is a command called tree that lists everything in the current directory and all directories below along with their files and sub-directories.

Here is an example to install and use the tree command. An example from the link:


Although screenshots of terminals are normally frowned upon, because copy and paste of pure text is favoured, I think the transgression in this instance will probably be forgiven by most readers.

You must log in to answer this question.

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