2013/6/20 David Korn <[email protected]>:
> cc: [email protected]
> Subject: Re: Re: Re: [ast-developers] When will the tree reopen for normal
> patches?
> --------
>
>> ~{fd}/.. doesn't work. It returns the /proc/pid/fd directory and not
>> the parent of the directory opened via openat().
>
> This is a bug which I will fix.
How should a fix work? ~{fd}/ extends to a /dev/fd/$fd/ or
/proc/pid/fd/$fd/ path, and then relpath is appended. if this is
passed to the kernel it will still be relative to a /dev/fd/$fd/ or
/proc/pid/fd/$fd/ path.
Caching the path on the shell side will NOT work because if the
directory $fd is pointing to moves (which is, like openat(), the
purpose we use the $fd directories for - keep track of moving
directories).
I don't see an option here.
>>
>> The bash and dash camps have already rejected ~{fd}/rel_path as "not
>> in the spirit of POSIX", and that implementing relative paths via
>> ~{fd} creates too much code bloat.
> Since ksh93 already supports exec {fd}< file, supporting ~{fd} fits
> in naturally. I will consider adding -f fd, if bash and dash add it,
> but it will be equivalent to ~{fd}/rel_path.
it should work the same way if rel_path doesn't go above the directory
location specified by $fd. but I see no chance to fix this in case
rel_path goes above $fd. Doesn't work, never.
Ced
--
Cedric Blancher <[email protected]>
Institute Pasteur
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
