On Thu, Jun 20, 2013 at 8:55 PM, Roland Mainz <[email protected]> wrote: > On Thu, Jun 20, 2013 at 8:30 PM, Roland Mainz <[email protected]> > wrote: >> On Thu, Jun 20, 2013 at 1:13 PM, Roland Mainz <[email protected]> >> wrote: >>> On Wed, Jun 19, 2013 at 5:49 PM, Cedric Blancher >>> <[email protected]> wrote: >>>> On 19 June 2013 16:16, David Korn <[email protected]> wrote: >>>>> cc: [email protected] >>>>> Subject: Re: [ast-developers] When will the tree reopen for normal >>>>> patches? >>>>> -------- >>>>> >>>>>> cd /dev/fd/$d no longer works >>>>> >>>>> What do you mean that it no longer works, I just did >>>>> exec 9< /tmp >>>>> and was able to do >>>>> cd /dev/fd/9/foo >>>>> to change to /tmp/foo. >>>>> >>>> >>>> /bin/ksh -c 'exec {n}</etc ; cd /dev/fd/$n/ ; true' >>>> /bin/ksh: cd: /dev/fd/11/: [Bad address] >>>> >>>> This has been reported to [email protected] several >>>> times. Search for '[Bad address]'. >>>> >>>> There were also requests for cd -f $n relative_path to allow relative >>>> paths which go above the starting point of fd, e.g. cd -f $n ../../a/b >>>> The other reason for cd -f $fd relative_path was that POSIX does not >>>> standardise absolute paths and that bash and dash developers see it as >>>> a cleaner API to openat() than using /dev/fd >>> >>> Attached (as "astksh_20130613_cd_f_dirfd_002.diff.txt") is the patch >>> to add $ cd -f $fd # ... it's more or less the same solution which was >>> proposed for bash4&&dash, too. >> >> Attached (as "astksh_20130613_cd_f_dirfd_003.diff.txt") is an updated >> patch which fixes the issue that the "pwd" builtin was unable to >> determinate the current cwd location. >> >> The fix works the same way how Sun's Solaris and other OSes with NFSv4 >> XATTR support handled the issue in their Bourne shell+csh versions. >> >> Example: >> -- snip -- >> $ ksh -c 'redirect {n}<"/etc" ; cd -f $n X11 ; pwd -P; pwd -L ; true' >> -- snip -- >> ... will print... >> -- snip -- >> /etc/X11 >> . >> -- snip -- >> ... "/etc/X11" is the physical location... but we use "." as the >> logical location since the logical cwd can not successfully be >> determinated... for example because the directory the descriptor $n is >> pointing to may have moved or the location wasn't know from the >> beginning (David: No... a tracking cache doesn't help if an external >> process or filesystem deamon renames the directory). We can't let >> "pwd" return an error... Sun once determinated that it breaks too many >> scripts (while using "." as logical name seems to work) ... ;-( >> >> More complex example: >> -- snip -- >> $ bash -c 'rm -Rf transaction_done ;mkdir transaction1 ; exec >> {n}<"transaction1" ; n=$n ~/bin/ksh -c "mv transaction1 >> transaction_done ; cd -f \$n . ; pwd -L ; pwd -P ; true"' >> . >> /home/test001/tmp/l1/transaction_done >> -- snip -- >> "." is used as logical name since there is no name associated with the >> file descriptor at the time the shell obtains the fd. > > ... and finally... in the case David&&Glenn do not like the idea of > "." being returned as logical directory by the "pwd" builtin is a > patch (as > "astksh_20130613_cd_f_dirfd_003_alternative1_no_logicalpwd_dot.diff.txt") > which throws an error if someone wants to access the logical > directory.
I think this is the better solution because POSIX (in http://pubs.opengroup.org/onlinepubs/9699919799/utilities/pwd.html) says "...The pwd utility shall write to standard output an absolute pathname of the current working directory, which does not contain the filenames dot or dot-dot...". If the pwd utility can't determinate the name of the cwd it should return an error. The hard case aren't the directories relative to a directory file descriptor, the hard cases are the NFSv4 and CIFS/SMBFS O_XATTR directories which neither have logical or physical names. Obtaining the logical path can fail - but what should we return as physical name in such a case? Let pwd fail with an error message too? I'll test the patch against CIFS today. Irek _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
