On 13 May 2013 13:07, Lionel Cons <[email protected]> wrote: > On 28 September 2012 20:31, Roland Mainz <[email protected]> wrote: >> On Mon, Sep 17, 2012 at 5:00 PM, Roland Mainz <[email protected]> >> wrote: >>> On Mon, Sep 17, 2012 at 3:17 PM, Lionel Cons >>> <[email protected]> wrote: >>>> On 14 September 2012 06:01, Roland Mainz <[email protected]> wrote: >>>>> Attached (as "astksh_chroot_cd_devfd_cd_f_20120911_001.diff.txt") is a >>>>> patch which fixes two issues with "cd": >>>>> 1. $ cd /dev/fd/$fd # doesn't work in chroot'ed environments when >>>>> /dev/fd is not mounted (thanks to CERN staff for reporting this). >>>>> 2. POSIX does not mandate _any_ paths. Since doing a "cd" relative to >>>>> a directory fd has become very popular the request was made to add an >>>>> alternative to using /dev/fd which is more or less acceptable for the >>>>> POSIX people. Based on that and a few discussions I added the option >>>>> -f to cd that a directory descriptor can be passed and the path given >>>>> is relative to that file descriptor. >>>>> >>>>> Notes: >>>>> - The code introduces a new function called |pathdevfd2relpathfd()| in >>>>> libast which can extract the fd number from a /dev/fd/$fd path (even >>>>> nested) >>>>> - If files or directories are opened relative to /dev/fd/$fd/$path >>>>> |sfopen()|/|sfopenat()| will now bypass the /dev/fd filesystem >>>>> completely (which gives a nice performance boost). The only exception >>>>> is that this can *NOT* be done for a plain /dev/fd/$fd, e.g. >>>>> /dev/fd/15. The problem is that there is AFAIK no way to open a file >>>>> from a file descriptor without using the /dev/fd filesystem or using >>>>> |dup()| ... but |dup()| rules itself out because the resulting >>>>> "cloned" fd still shares attributes like the current seek position >>>>> with the original fd... >>>>> >>>>> Glenn: Is it acceptable for |sfopen()| to |dup()| the incoming file fd >>>>> (see "Notes" above) ? >>>> >>>> Roland: Are you going to send your new patch to this list? The >>>> feedback of Josef's group has been very positive and rigid testing >>>> didn't show any problems. >>> >>> Attached (as "astksh_chroot_cd_devfd_cd_f_20120916_002.diff.txt") is >>> the patch which adds $ cd -f $fd relpath # and the /dev/fd emulation >>> for chroot environments and older Solaris releases. >>> >>> Changes: >>> - It's intentionally no longer possible to mix $ cd -f $fd ... # with >>> absolute paths. As we figured out this (together with the idea that >>> multiple /dev/fd/$fd could be stacked (they can... but it's not clear >>> whether the results would be relative or absolute paths (basically >>> it's disputed))) will quickly cause breakdown of semantics, logic and >>> the universe >>> >>> Notes: >>> - $ cd -f $fd relpath # more or less creates a "virtual /" at the >>> directory where $fd points to. Doing a cd .. below that point is NOT >>> supported and may result in undefined behaviour. This is more or less >>> a limitation of the underlying technology and semantics... but as we >>> figured out it should not represent an issue for real-world script >>> programming >> >> Mhhh... the patch didn't make it into ast-ksh.2012-09-27 ... >> ... as reference I attached (as >> "astksh_chroot_cd_devfd_cd_f_20120927_001.diff.gz") an updated version >> of the patch... which also fixes problems that $ cd ~{fd}/foo # >> doesn't work on operating systems without /proc, e.g. Apple MacOS X >> ... >> >> Same patch has been send to David a few minutes ago since he ran into >> issues with $ cd ~{fd}/foo # Apple MacOS X ... > > What's the status of this patch?
I realised the patch needs an update to match the changes to ast-ksh since the last patch. Roland, can you provide an updated patch, please? Lionel _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
