On Sat, Sep 21, 2013 at 4:31 PM, Glenn Fowler <[email protected]> wrote:
>
> On Sat, 21 Sep 2013 08:51:38 +0200 Lionel Cons wrote:
>> On 19 September 2013 18:53, Roland Mainz <[email protected]> wrote:
>> > On Thu, Sep 19, 2013 at 6:08 PM, Glenn Fowler <[email protected]> 
>> > wrote:
>> >>
>> >> can someone post urls for the man pages for
>> >>         readlink(1)
>> >>         realpath(1)
>> >
>> > 1. The relevant references:
>> > The all-in-one manpage for busybox can be found here:
>> > http://busybox.net/downloads/BusyBox.html
>> >
>> > FreeBSD readlink(1):
>> > http://www.freebsd.org/cgi/man.cgi?query=readlink&apropos=0&sektion=1&manpath=FreeBSD+9.1-RELEASE&arch=default&format=html
>> > FreeBSD realpath(1):
>> > http://www.freebsd.org/cgi/man.cgi?query=realpath&apropos=0&sektion=1&manpath=FreeBSD+9.1-RELEASE&arch=default&format=html
>> >
>> > 2. Only for reference - GNU coreutils:
>> > http://www.gnu.org/software/coreutils/manual/html_node/readlink-invocation.html
>> > http://www.gnu.org/software/coreutils/manual/html_node/realpath-invocation.html
>> >
>> >>         resolvepath(1)
>> >
>> > AFAIK that's ENOSUCHMANPAGE... out of confusion between
>> > |resolvepath(2)| and the |*(1)| consumers of that API...
>> > ... Lionel... can you verify this, please ?
>
>> Yes, that's correct. resolvepath(1) turned out to be a crazy script of
>> our own making which gets deployed to deal with the lack of a path
>> resolving facility - a standardisation on ksh93/busybox readlink(1)
>> and realpath(1) would eliminate the need.
>
>> Please don't forget option --fd $dirfd for readlink(1) and realpath(1)
>> so we can have a virtual root (for chroot environments without doing
>> an actual (expensive) chroot() call each time we want to get the paths
>> right).
>
> can you provide some more info on dirfd as chroot() surrogate
> I'm a bit confused because the *at() api dirfd has no effect on absolute paths
> and the whole idea of chroot() is to grab all paths, relative and absolute

I think the idea is to to NOT have to use chroot() each time when they
set up a chroot environment. That doesn't include a full emulation of
chroot behaviour, but requires to do some things relative to the
intended root of the environment.
I've seen such hacks before, using perl and custom wrappers for
openat(2), fchownat(2),  fstatat(2), futimesat(2), renameat(2),
unlinkat(2) ...

Josh
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers

Reply via email to