On 30 August 2013 07:28, Glenn Fowler <[email protected]> wrote: > > 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
Glenn, Roland: Could the next ast-ksh update *PLEASE* focus on libcmd updates? The availability of readlink(1) and realpath(1) has become *VERY* high priority for us, even more important than bugfixes for signal handling. Ced -- Cedric Blancher <[email protected]> Institute Pasteur _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
