2012/11/28 Clark WANG <[email protected]>:
> ~{fd} is new to me. Please help me a bit...
>
>>
>> >>>
>> >>> This isn't readlink support. It's a a smart solution to allow child
>> >>> processes to access the shell's inherited file descriptors.
>
>
> Lionel, I don't quite understand this. Can you explain a bit more?
>
>>
>> We already
>> >>> heavily rely on this feature, both for IPC and to shorten very long
>> >>> paths to speed processing up.
>> >>>
>> >
>> > Yes, it's an ingenious solution to the problem of long paths. You pass
>> > a dir fd in which acts as virtual "/" and all paths are appended to
>> > it. Using /proc/.../fd instead of /megalong/path/ is MUCH faster and
>> > easier.
>
>
> Cedric, how can you get a dir fd? All I know about opening a dir is
> opendir(3).
opendir(3) is a layer above open(dir). open(dir) returns a fd for that
directory which can be used with openat(2) to access files relative to
that directory (works like chroot(), i.e. the {fd} defines a new /
from where all paths originate).
ksh93 has with ~{fd} a similar api to use such directory file descriptors.
>>
>>
>> Yes, we like this feature, too. At first it was a bit 'getting used
>> to' but if you imagine that each fd works - as Cedric stated - a
>> virtual root then script hackers will quickly understand the power of
>> this feature. Suddenly you can have as many cwds as you wish and
>> that's worth $$$$.
>
>
> Irek, I don't quite understand you here either. Can't you have as many cwds
> without using ~{x}?
Not that I am aware of. There is only one global cwd per process (cwd
is the current working directory, the one you set with chdir() or
fchdir()). The only other option is that you call open() for a
directory and use openat() to access files relative to that location.
This is the way how ksh93 implements the ~{fd} feature.
Ced
--
Cedric Blancher <[email protected]>
Institute Pasteur
_______________________________________________
ast-users mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-users
