Upstream coreutils 8.15 added a new realpath(1) utility: > Usage: src/realpath [OPTION]... FILE... > Print the resolved absolute file name; > all but the last component must exist > > -e, --canonicalize-existing all components of the path must exist > -m, --canonicalize-missing no components of the path need exist > -L, --logical resolve '..' components before symlinks > -P, --physical resolve symlinks as encountered (default) > -q, --quiet suppress most error messages > --relative-to=FILE print the resolved path relative to FILE > --relative-base=FILE print absolute paths unless paths below FILE > -s, --strip, --no-symlinks don't expand symlinks > -z, --zero separate output with NUL rather than newline > > --help display this help and exit > --version output version information and exit > > Report realpath bugs to bug-coreut...@gnu.org > GNU coreutils home page: <http://www.gnu.org/software/coreutils/> > General help using GNU software: <http://www.gnu.org/gethelp/> > Report realpath translation bugs to <http://translationproject.org/team/> > For complete documentation, run: info coreutils 'realpath invocation'
In particular, it is much more powerful than the realpath(1) currently offered by cygutils. Should I build my next coreutils package with realpath included, and wait to upload it until we can coordinate a build with cygutils dropping the weaker variant? Or do we want to keep the cygutils variant for a while longer? -- Eric Blake ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature