On Fri, Feb 25, 2022 at 12:20 PM Robert Elz via austin-group-l at The Open Group <austin-group-l@opengroup.org> wrote:
> 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. > correct. > 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. > except readlink isn't in posix either :-) *that's* the portability issue i've seen in practice. in places where we do/did support macOS as well as linux, we'd end up with a python one-liner or whatever to make up for this. my assumption was "readlink(1) has a bunch of options, getting that into POSIX would be a nightmare ... but everyone seems to have got on just fine with a trivial realpath(1) that has no options [apart from the fact that it's also not in POSIX]". fwiw, current macOS does have readlink (with just -n), but still no realpath. > 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. > i don't think that's true of busybox? > kre > >
