Robert Elz wrote, on 24 Mar 2022:
>
> | Has there been any progress on the possibility of NetBSD changing
> | realpath to behave like coreutils wrt -e?
>
> Not yet. I cannot work out exactly what I am supposed to
> implement, the coreutils doc is hopeless. Until I know
> what that is, I cannot propose it to NetBSD developers.
>
> I am not sure whether "last component not existing" refers to
> the final component of the given path not appearing in the
> directory to which the earlier path resolves, of if it means
> where that component refers toa symlink which does not
> name an existing file, or both, or something else.
>
> Further if it is impossible to determine whether the final
> component exists or not, or what it is if it can be determined
> to exits (no r or x permission, or just no x) is that supposed to
> be ignored as well?
Do these results (from coreutils 8.30) cover what you need to know:
$ cd /tmp
$ mkdir realpath
$ cd realpath
$ touch file
$ ln -s file filelink
$ ln -s nofile nofilelink
$ mkdir -m a=wx d_nor
$ mkdir -m a=w d_norx
$ realpath ./filelink; echo exit $?
/tmp/realpath/file
exit 0
$ realpath -e ./filelink; echo exit $?
/tmp/realpath/file
exit 0
$ realpath ./nofilelink; echo exit $?
/tmp/realpath/nofile
exit 0
$ realpath -e ./nofilelink; echo exit $?
realpath: ./nofilelink: No such file or directory
exit 1
$ realpath ./d_nor/foo; echo exit $?
/tmp/realpath/d_nor/foo
exit 0
$ realpath -e ./d_nor/foo; echo exit $?
realpath: ./d_nor/foo: No such file or directory
exit 1
$ realpath ./d_norx/foo; echo exit $?
realpath: ./d_norx/foo: Permission denied
exit 1
$ realpath -e ./d_norx/foo; echo exit $?
realpath: ./d_norx/foo: Permission denied
exit 1
> If you were to write a standards worthy description of exactly
> what is to be required (which will eventually be required
> regardless of whether a -E option is needed to enable it on
> BSD systems) that would help.
My bugnote 5700 has what I came up with for readlink -f (without -n),
which I think could be reused for realpath without -e.
It doesn't state anything explicit about the directory permissions,
but I think that's fine because it's normal for utility descriptions
to leave such things to be covered by the general rules on utility errors.
I think the behaviour with -e would simply be described as:
The realpath utility shall write to standard output the absolute
pathname that would be returned by a call to the realpath()
function with the file operand as its first argument, followed by
a <newline> character.
If the realpath() function would return a null pointer, realpath
shall write a diagnostic message to standard error and exit with
non-zero status.
--
Geoff Clare <[email protected]>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
