We're now using the feature of directory relative paths in our
production system in months but today ran into a bug on Solaris 10:
ksh -c 'builtin mkdir ; redirect {d}<$HOME ; mkdir /dev/fd/$d/x'
mkdir: /dev/fd/11/x: [Not a directory]The same line works on all other platforms (Linux, OpenBSD, FreeBSD). Wendy ---------- Forwarded message ---------- From: Roland Mainz <[email protected]> Date: 28 September 2012 20:31 Subject: Re: [ast-developers] [patch] New patch to make $ cd /dev/fd/$fd/$path # work in a chroot and to add $ cd -f $fd $path # ... / was: Re: [patch] Patch to make $ cd /dev/fd/$fd/$path # work in a chroot and to add $ cd -f $fd $path # ... To: Lionel Cons <[email protected]> Cc: [email protected] 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 ... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [email protected] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) _______________________________________________ ast-developers mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/ast-developers -- Wendy _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
