On Wed, Dec 11, 2013 at 2:13 PM, Glenn Fowler <[email protected]> wrote: > the "AFAIK" part or roland's test has no mention of /proc or /dev/fd
Roland? > > > > On Wed, Dec 11, 2013 at 5:40 AM, Irek Szczesniak <[email protected]> > wrote: >> >> On Wed, Dec 11, 2013 at 4:55 AM, Glenn Fowler <[email protected]> >> wrote: >> > this fails >> > ksh -c 'mkdir -p f1 ; redirect {d}<f1 ; /bin/pwd ; (cd -f $d ; /bin/pwd) >> > ; >> > /bin/pwd ; : ' >> > this works >> > ksh -c 'mkdir -p f1 ; redirect {d}<f1 ; /bin/pwd ; (cd ~{d} ; /bin/pwd) >> > ; >> > /bin/pwd ; : ' >> > and this works >> > ksh -cx 'mkdir -p f1 ; redirect {d}<f1 ; /bin/pwd ; (cd /dev/fd/$d ; >> > /bin/pwd) ; /bin/pwd ; : ' >> > >> > this quick fix to bltins/cd_pwd.c translates -f N to /dev/fd/N and goes >> > through the path-based code -- it should do until the shp->pwdfd code >> > hardens >> > or maybe it can simplify the logic? >> > -- >> > --- /home/gsf/src/cmd/ksh93/bltins/cd_pwd.c Thu Dec 5 11:13:32 2013 >> > +++ bltins/cd_pwd.c Tue Dec 10 22:01:54 2013 >> > @@ -137,9 +137,25 @@ >> > j = sfprintf(shp->strbuf2,"%s",dir); >> > dir = sfstruse(shp->strbuf2); >> > pathcanon(dir, j + 1, 0); >> > +#if 1 >> > + if (*dir!='/' && dirfd!=shp->pwdfd) >> > + { >> > + sfprintf(shp->strbuf, >> > "/dev/file/xattr@/dev/fd/%d/%s//@//", dirfd, dir); >> > + dirfd = shp->pwdfd; >> > + } >> > + else >> > +#endif >> > sfprintf(shp->strbuf, "/dev/file/xattr@%s//@//", dir); >> > dir = sfstruse(shp->strbuf); >> > } >> > +#if 1 >> > + else if (*dir!='/' && dirfd!=shp->pwdfd) >> > + { >> > + sfprintf(shp->strbuf, "/dev/fd/%d/%s", dirfd, dir); >> > + dirfd = shp->pwdfd; >> > + dir = sfstruse(shp->strbuf); >> > + } >> > +#endif >> > #if _WINIX >> > if(*dir != '/' && (dir[1]!=':')) >> > #else >> > >> > >> > On Tue, Dec 10, 2013 at 5:07 PM, Roland Mainz <[email protected]> >> > wrote: >> >> >> >> Hi! >> >> >> >> ---- >> >> >> >> The following testcase... >> >> -- snip -- >> >> redirect {basefd}<"." >> >> touch "x5" >> >> cd -@ "x5" >> >> redirect {n}<"." >> >> cd -f ${basefd} >> >> (cd -f "$n" ; print "hello5" >"myxattr5") >> >> /usr/bin/runat "x5" "cat myxattr5" >> >> (cd -@ "x5" ; cat "myxattr5" ) >> >> rm "x5" >> >> -- snip -- >> >> ... shows an issue with cd -f $fd in subshells in ast-ksh.2013-12-06 >> >> on Solaris 11/B145/64bit... it seems it doesn't restore the cwd of the >> >> parent shell level when the non-|fork()|'ing subshell terminates: >> >> -- snip -- >> >> $ ~/bin/ksh -x xattr_cd_fd002.sh >> >> + command exec >> >> + {basefd}< . >> >> + touch x5 >> >> + cd -@ x5 >> >> + command exec >> >> + {n}< . >> >> + cd -f 12 >> >> + cd -f 10 >> >> + print hello5 >> >> + 1> myxattr5 >> >> + /usr/bin/runat x5 'cat myxattr5' >> >> runat: cannot open x5: No such file or directory >> >> + cd -@ x5 >> >> xxx.sh[8]: cd: /dev/file/xattr@x5//@//: [Not a directory] >> >> + cat myxattr5 >> >> hello5 >> >> + rm x5 >> >> rm: x5: not found >> >> -- snip -- >> >> >> >> Here is a reduced testcase which should work on all platforms: >> >> -- snip -- >> >> $ ~/bin/ksh -c 'mkdir -p f1 ; redirect {d}<f1 ; /bin/pwd ; (cd -f $d ; >> >> /bin/pwd) ; /bin/pwd ; true ' >> >> -- snip -- >> >> >> >> On Solaris 11/b145/AMD64/64bit and SuSE 12.3/AMD64/64bit it prints >> >> this... >> >> -- snip -- >> >> /home/test001/x1 >> >> /home/test001/x1/f1 >> >> /home/test001/x1/f1 >> >> -- snip -- >> >> >> >> ... but AFAIK it should print: >> >> -- snip -- >> >> /home/test001/x1 >> >> /home/test001/x1/f1 >> >> /home/test001/x1 >> >> -- snip -- >> >> I don't like the patch because the /dev/file paths are not very >> portable. IMHO, if cd -f $fd is used, $PWD should return a path >> relative to /proc/$$/$fd/, which is obviously not happening for >> Roland's testcase. >> >> About the original bug, does spawnvex() support directory fds? Maybe >> we need a spawnvexat() function? It looks the shell is behaving >> correctly, but as soon as external processes get involved they hit the >> wrong directory. >> >> Irek >> >> PS: What happened to the patch which added shp->pwdfd support for the >> builtin commands in libcmd? > > -- Irek _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
