What is the origin of the -E option of the `realpath` command in POSIX issue 8?

Question

The realpath command utility is now defined by POSIX in its issue 8 (2024): realpath — resolve a pathname

realpath [-E|-e] file

The realpath utility shall canonicalize the pathname specified by the file operand as follows:

If a call to the realpath() function with the specified pathname as its first argument would succeed, the canonicalized pathname shall be the pathname that would be returned by that realpath() call. Otherwise:

• If the -e option is specified, the canonicalization shall fail.

• If the -E option is specified, then if a call to the realpath() function with the specified pathname as its first argument would encounter an error condition other than [ENOENT], the canonicalization shall fail; if the call would encounter an [ENOENT] error, realpath shall expand all symbolic links that would be encountered in an attempt to resolve the specified pathname using the algorithm specified in XBD 4.16 Pathname Resolution, except that any trailing <slash> characters that are not also leading <slash> characters shall be ignored. If this expansion succeeds and the path prefix of the expanded pathname resolves to an existing directory, the canonicalized pathname shall be the expanded pathname. In all other cases, the canonicalization shall fail. If the expanded pathname is not empty, does not begin with a <slash>, and has exactly one pathname component, it shall be treated as if it had a path prefix of "./".

• If no options are specified, realpath shall canonicalize the specified pathname in an unspecified manner such that the resulting absolute pathname does not contain any components that refer to files of type symbolic link and does not contain any components that are dot or dot-dot.

Upon successful canonicalization, realpath shall write the canonicalized pathname, followed by a <newline> character, to standard output.

If canonicalization fails, or the canonicalized pathname is empty, nothing shall be written to standard output, a diagnostic message shall be written to standard error, and realpath shall exit with non-zero status.

[...]

My question is: the -e option of realpath is already supported by at least GNU and Solaris, but I can't find any mention of the -E option in any realpath that I could check (macOS, FreeBSD, Solaris, GNU). Did the OpenGroup invent it?

Answer 1

It is indeed a POSIX invention, added to reconcile incompatible behaviour in different implementations: coreutils realpath doesn’t require the file to exist, unless -e is specified, whereas NetBSD realpath requires the file to exist.

To resolve this, the -E option was invented; it has since been implemented in NetBSD realpath:

With the E option (the default) it is not an error for the final component of the resolved pathname to reference a file which does not exist.

(See the corresponding change for details.)

The -E option first appears in this question:

Would you (or whoever maintains realpath for NetBSD) be willing to add a -E option that makes your version behave like the coreutils default? Then POSIX could specify it with -e and -E options, and say it is unspecified which is the default.

The alternative would be to go back to the original plan of just adding readlink (with the -f option for canonicalisation).

and with the possible ways forward described as follows:

So my preferences are (in descending order):

1. POSIX adds realpath with -e and -E, and readlink without -f. Unspecified which of -e or -E is the default. GNU adds a no-op -E to realpath. NetBSD/FreeBSD adds -E and a no-op -e to realpath.

2. POSIX adds readlink with -f (whose behaviour is the same for both implementations). No realpath.

3. POSIX adds realpath without -e and -E, and readlink without -f. Unspecified whether realpath needs last component to exist.

You can see the history of the POSIX entry in Austin Group issue 1457.