On Fri, 27 Sep 2013 02:17:07 +0200 Roland Mainz wrote:
> 2013/9/18 Roland Mainz <[email protected]>:
> > 2013/9/17 Glenn Fowler <[email protected]>:
> >> On Tue, 17 Sep 2013 21:14:38 +0200 Lionel Cons wrote:
> >>> On 17 September 2013 20:49, Glenn Fowler <[email protected]> wrote:
> >>> >
> >>> > from ksh did you try
> >>> >
> >>> > getconf name ~{fd}
> >>> > getconf name /dev/fd/${fd}
> >>
> >>> Forwarding the feedback from a coworker:
> >>> It may work for AST but it is not legal: ~{fd} expands to /proc, which
> >>> is a filesystem, and /dev/fd is a filesystem on Solaris too. What
> >>> happens if I want to find the pathconf properties of /proc or /dev/fd
> >>> in a POSIX conforming way?
> >>
> >> if you want to do fpathconf(2) from the command line in a posix conforming
> >> way then you can't
> >> posix has neither /proc nor /dev/fd
> >>
> >> now for a useful answer
> >> using ~{fd} or /dev/fd will only work for builtins or on systems that
> >> support /proc/<pid>/fd/<fd>
> >> right now the ksh93 getconf builtin defers to /usr/bin/getconf for most
> >> path_var operands
> >> those would have to be instead handled by the builtin to handle fds
> >>
> >> until then something like this should work on most modern unix (with
> >> /dev/fd/<fd> support)
> >>
> >> getconf path_var /dev/fd/0 < ~{fd}
> >
> > Erm... this can't work (and quick testing&&looking at the Solaris and
> > Linux kernel sources confirms it) because |pathconf()|+|fpathconf()|
> > is a syscall which is directly forwarded to the matching filesystem
> > code in the kernel. The syscall passes the path (string for
> > |pathconf(), fd for |fpathconf()|) to the kernel and then the kernel
> > looks-up the matching filesystem and then forwards the call to that
> > filesystem...
> >
> > Regardless how hard we try the current getconf(1) API won't work for a
> > given fd, e.g. it can't work using /dev/fd/ because /dev/fd is a
> > separate filesystem on Solaris and /dev (covering /dev/fd/) on Linux.
> > The same applies to ~{fd} which expands to /proc/$currpid/fd/$fd and
> > therefore refers to the proc filesystem instead of the filesystem the
> > fd is on.
> >
> > AFAIK the only valid way is to add a --fd option to getconf(1) to deal
> > with that trouble because at least the Solaris test suite use
> > /usr/bin/getconf to test the devfs and procfs filesystems... which
> > means if we implement the AST intercept system to convert a /dev/fd or
> > /proc/self/fd/ path to a fd internally to call |fpathconf()| we break
> > such tests... ;-(
can you list the explicit paths used in these tests
I can see
/dev/fd
/proc/self/fd
referring to the specific filesystem
but why would
/dev/fd/${fd}/foo
/proc/self/fd/${fd}/foo
stop at the fs and not resolve through ${fd} to foo
or why whould these stop at the fs and not the ${fd}
/dev/fd/${fd}/foo
/proc/self/fd/${fd}/foo
is this just an incomplete implementation of /dev/fd and /proc/${pid}/fd?
we already have iffe evidence of that on some systems
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
