Date: Fri, 25 Feb 2022 15:25:53 +0000
From: "Geoff Clare via austin-group-l at The Open Group"
<austin-group-l@opengroup.org>
Message-ID: <20220225152553.GA4559@localhost>
| The point is it's a difference in behaviour between the two
| implementations.
Yes, understood. My question (not to you, but to the universe) was
whether that difference needs to exist? That is, perhaps I can change
the NetBSD impl to at least behave wrt -e (and the fictional -E) the
same as the coreutils version. That seems like it would be a better
outcome, if it was possible, right?
Right now I have no idea whether it is possible however (the code
is obviously possible, it is the compat issues/politics that are
questionable).
| 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.
Yes, if it turns out not to be possible to alter the default behaviour
of the default for our version, that would certainly be a reasonable
approach.
| So my preferences are (in descending order):
I'd insert:
0. Make the BSD version compatible with coreutils (at least for
the one issue that seems to matter - though I'm not sure what
its practical uses are).
| 1. POSIX adds realpath with -e and -E,
[...]
| I wasn't proposing any other options be included for realpath
| (except perhaps -q, depending on whether it behaves the same in
| both implementations).
Understood, I was just ruminating on the others on the assumption that
if I can attempt to make ours compatible, just how compat should I aim.
It won't be all the way, but perhaps more than just the -e issue.
The -q seems to be (close enough to, given the other differences) the
same between the two (at least according to the coreutils man page).
It just makes some stderr output vanish (which incidentally might make
realpath do exit(1) without anything on stderr).
e...@google.com said:
| in terms of "what's actually used in the wild", Android uses toybox (0BSD
| licensed, so anyone can look :-) )
OK, I did. Note that we're talking of options for realpath(1), not
readlink(1). It looks as if the toybox version (from what I can gather
from what I guess from that very stylised code) has no options to realpath
at all - and that it is simply a clone of readlink -f, just as Steffen
indicated the busybox version is.
There would be no point including realpath(1) in posix if it is simply
readlink -f with no options possible at all - there has to be some difference
in how it works to be worth including, I would have thought.
e...@google.com also said:
| one thing i haven't seen mentioned so far (but which i added to toybox
| myself, so i know it's definitely in use) is that existing realpath
| implementations support *multiple* file arguments on the command line, not
| just one.
Sure, as best I can tell, all implementations of both readlink and realpath
allow multiple file (path) args.
kre
