On Fri, 30 Aug 2013 05:35:43 +0200 Cedric Blancher wrote: > On 31 July 2013 13:36, Cedric Blancher <[email protected]> wrote: > > On 31 July 2013 04:12, Dan Douglas <[email protected]> wrote: > >> `readlink -f' is the most common invocation I see in scripts. I'd > >> recommend making compatibility with at least coreutils' readlink a goal. > >> See path_resolution(7) from the Linux man-pages for details on that part. > > > > Agreed. But as Roland Mainz wrote "the work for the { -e, -f, -m > > }-options has a dependency on |fgetcwd()|.". So we have to wait with > > -f until fgetcwd() appears in libast, and until then take readlink(1) > > as is. Good enough for me, and good enough for users coming from > > FreeBSD or busybox. > >
> Glenn, is there *now* hope to get readlink(1) integrated into libcmd? > I know ls -l could work too but there are existing consumers (mostly > FreeBSD and busybox) relying on readlink(1) and realpath(1) who could > benefit from this work. yes I extended the src/lib/libast/path/pathcanon.c flags to handle resolvepath(2) and readlink(1) options -- do you have a url for the realpath(1) man page? I'm guessing readlink(1) would be sufficient the ast readlink(1) will probably add a few more options to cover the underlying ast pathcanon() and pathdev() PATH_* flags -- then it could be used as a regression test harness just looked at the posix realpath(2) api -- can't believe it doesn't have a buffer size arg, and the linux vs bsd vs solaris behavior is all over the place soem preserve relative path, some always return absolute path _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
