in terms of "what's actually used in the wild", Android uses toybox (0BSD licensed, so anyone can look :-) ) for both on-device *and* for the OS build itself on the host.
toybox readlink ( https://github.com/landley/toybox/blob/master/toys/other/readlink.c) currently supports: usage: readlink FILE... With no options, show what symlink points to, return error if not symlink. Options for producing canonical paths (all symlinks/./.. resolved): -e Canonical path to existing entry (fail if missing) -f Full path (fail if directory missing) -m Ignore missing entries, show where it would be -n No trailing newline -q Quiet (no output, just error code) since toybox tends to add things _as they're needed_, rather than "because coreutils has them", that's probably "solid anecdata" about what gets used in the wild. 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. On Fri, Feb 25, 2022 at 6:56 AM Robert Elz via austin-group-l at The Open Group <austin-group-l@opengroup.org> wrote: > 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 -m opion just looks stupid, at first glance it would mean > that any trailing part of a path could be missing (since if > a subdir is absent, necessarily it cannot have contents, but > there is also the possibility of /e1/e2/m1/../l1/m2/../e3/l2 > where ane e? name is an existing directory, any l? is an > existing symlink, and each m? is non-existing junk. > Dealing with nonsense like this isn't worth the effort, so > -m is unlikely to ever happen. Some other option (maybe > -p for partial) could exist to allow resolving smylinks > in a leading existing prefix of a path, omitting any more > existance checks beyond that (so no more symlink resolution) > but only if there is some demonstrated need for that. > > -L is not an possibility, I could easily add a do nothing -P > option though (just like our shell's cd command). > > The long name options won't happen, and I find it hard to > see a real need for the 2 --relative options in any case, it > seems likely they could better, and more flexibly, be handled > by post processing the results than built in. > > Then we get to the harder choices ... -z looks easy, and > harmless, but in practice probably mostly useless. So I'm > not sure about that one. -s just turns the whole thing into > a simple string processing program, something that could be > done with a fairly simple sed script, so I'm not sure about > that either. > > Their man page is also woefully short on error details. > Eg: what counts as "missing". Obviously ENOENT, but > what about ENOTDIR in the case of /d/f/m > where d is an existing directory (or path), f is some > non directory file, and m is (obviously) missing? > Or EACCESS for /d/n/m? where d is as previously, > n is an existing directory without x permission (perhaps > no r permission either) and m? is presumed missing as > we cannot determine if it is there, and even if r perm > exists, so we can read /d/n and discover m? exists, > we do not know if is is a symlink or not (cannot lstat). > > This is something of a mess, and while I hesitate to say > it, all too typical of linux/gnu software which only > specifies what happens in the cases they think of, and > all else is just "whatever happens" and isn't necassarily > even consistent in one utility. > > With this it would be difficult (and pure fluke if it > happened) for me to implement something compat, and I'd > hesitate to even suggest adding code to be compat, unless > I could promise that is what tge result woukd be. > > Of course if there was a proposed POSIX spec that made it > clear what is intended in all these odd cases, that might > make a big difference. > > kre > >
