the "AFAIK" part or roland's test has no mention of /proc or /dev/fd
On Wed, Dec 11, 2013 at 5:40 AM, Irek Szczesniak <iszczesn...@gmail.com>wrote:
> On Wed, Dec 11, 2013 at 4:55 AM, Glenn Fowler <glenn.s.fow...@gmail.com>
> 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 <roland.ma...@nrubsig.org>
> > 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?
>
_______________________________________________
ast-developers mailing list
ast-developers@lists.research.att.com
http://lists.research.att.com/mailman/listinfo/ast-developers
