Geoff Clare wrote in
<20220225152553.GA4559@localhost>:
|Robert Elz wrote, on 25 Feb 2022:
|>
|> OK. I have looked at the coreutils realpath man page (gnu licensing
|> stupidity means I cannot look at their code), and I can see the
|> possibility (subject to community agreement) of implementing
|> some of the options it has. Not all.
|>
|> I'm not sure a -E option is needed, if the whole path exists it
|> makes no difference, if just the last component is missing, I
|> can't really imagine and BSD usage requiring an error in that case
|> (and anyone who needs tgat could use -e if I implement this).
|
|The point is it's a difference in behaviour between the two
|implementations. Rather than just making it unspecified whether
|the last component has to exist, it seemed to me that it would
|be more useful to have -e and -E options so that users have a
|way to ensure they get the same behaviour on both.
|
|So my preferences are (in descending order):
|
|1. POSIX adds realpath with -e and -E, and readlink without -f.
Why adjust a closed issue if all known implementations of
readlink(1) do support an identical -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.
POSIX could also mention the possibility to handle these two
commands via "argv[0] tricks", "realpath like readlink -f"?
It portability is not an issue.
I looked in my things, i do have two use cases for realpath(1),
quite some more for readlink(1), which i even "fake" in my
~/.profile as necessary:
# UnixWare plus does not have readlink(1)
if command -v readlink >/dev/null 2>&1; then
:
else
readlink() {
echo "${*}"
}
fi
What a mess. POSIX has readlink(2) and realpath(3), coming from
that i would assume many programmers who "live" in a modern *x
environment simply take this for granted?
Ok, the manuals say
readlink - print resolved symbolic links or canonical file names
realpath - print the resolved path
but this is GNU only; On OpenBSD one can read
.Nd display target of symbolic link on standard output
.Nd print the canonicalized absolute pathname
and on FreeBSD (in /bin even!)
.Nd return resolved physical path
letting aside readlink for now.
The latter is why i personally would "naturally" think, as it
mirrors readlink(2) and realpath(3).
|3. POSIX adds realpath without -e and -E, and readlink without -f.
|Unspecified whether realpath needs last component to exist.
|
|I wasn't proposing any other options be included for realpath
|(except perhaps -q, depending on whether it behaves the same in
|both implementations).
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
