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? Lionel _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
