On 15 September 2013 06:18, Glenn Fowler <[email protected]> wrote:
>
> On Sun, 15 Sep 2013 00:10:58 +0200 Lionel Cons wrote:
>> On 14 September 2013 20:14, Cedric Blancher <[email protected]>
>> wrote:
>> > 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.
>
>> Hey, it's weekend. Give Glenn and Roland some rest :)
>> I've looked at Roland's patch (our scripts are heavy users of
>> readlink(1) and resolvepath(1) in some places and there's lots of 3rd
>> party code which uses both commands, too) and its pretty
>> straightforward for readlink(1). My trouble is with resolvepath(1) -
>> Glenn may want to use his pathdev() function and I have no idea how to
>> do that and make it work with shp->pwdfd without having a pathdevat()
>> or resolvepathat() function.
>
>> Lionel
>
>> P.S. pathdev() has no man page
>
> pathdev() was rounded out with resolvepath(1) in mind
> and the first arg to pathdev() is a *at()-style directory fd
Thanks.
Any suggestion how we can implement all the following (crazy?) extra
options in GNU readlink(1):
readlink [OPTION]... FILE
DESCRIPTION
Display value of a symbolic link on standard output.
-f, --canonicalize
canonicalize by following every symlink in every
component of the given name recursively; all but the last component
must exist
-e, --canonicalize-existing
canonicalize by following every symlink in every
component of the given name recursively, all components must exist
-m, --canonicalize-missing
canonicalize by following every symlink in every
component of the given name recursively, without requirements on
components existence
Lionel
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
