Is there a general term for the items in a directory?

Question

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.

Edit: Just to be clear, I'm looking for a singular term, as in my example sentence.

Answer 1

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.

Answer 2

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.

^(source)

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.

Answer 3

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."

Answer 4

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.

Answer 5

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.