2012/9/5 Roland Mainz <roland.ma...@nrubsig.org>:
> 2012/9/5 Roland Mainz <roland.ma...@nrubsig.org>:
>> 2012/9/5 David Korn <d...@research.att.com>:
>> [CC:ing ast-developers@research.att.com so that the patch gets archived]
>>> cc: g...@research.att.com olga.kryzhanov...@gmail.com
>>> Subject: Re: New syntax for paths relative to directory fds
>>> (~{dirfd}/foo/bar.txt) ...
>>>> [Mostly Olga's idea (who is away and can't post anyway here since the
>>>> AT&T spam filters have a grudge against her native name... ;-( )]
>>>>
>>>> Woud the following syntax for paths relative to a directory fd "dirfd"
>>>> be possible without violating POSIX (right now the only way to archive
>>>> this is to use /dev/fd/${dirfd}/ ... which works OK but may not be
>>>> suiteable for a new version of the POSIX standard since POSIX does not
>>>> mandate any absolute paths):
>>>>
>>>> ~{dirfd}/foo/bar/txt
>>>>
>>>> (where "dirfd" is a directory fd and "foo/bar/txt" is a path relative
>>>> to this fd)
>>>>
>>>> Example usage:
>>>> -- snip --
>>>> # print contents of /etc/profile and /etc/ksh.kshrc
>>>> redirect {dirfd}<"/etc"
>>>> cat <~{dirfd}/profile
>>>> cat <~{dirfd}/ksh.kshrc
>>>> -- snip --
>>>>
>>>
>>> That could be done. The code is in sh/macro.c sh_tilde_expand2().
>> [snip]
>>
>> Attached (as "astksh_tilde_fd001.diff.txt") is a prototype patch.
>> Technically it works without problems... but I'm not happy with the
>> |static| variable |devfdname| (short: Ugly |static| variable... which
>> means: Global variable (with function-local scope). Not thread-safe).
>>
>> Question: Is it _valid_ to allocate space from |shp->stk| and return
>> the string as return value of |sh_tilde()| ? Who or what is going to
>> deallocate the memory chunk ?
>
> Short answer from David:
> -- snip --
> Anything on shp->stk will get deleted when the command that it is
> expanding completes.
> -- snip --
>
> Attached (as "astksh_tilde_fd002.diff.txt") is a revised patch
> (without function-static variables) per David&co.'s (code review)
> feedback...
Tried, tested, fell in love :)
My only concern is that redirect {f}<>file never allowed plain numbers
as f, i.e. redirect {512}<>file. IMO you should remove that, or add
support that redirect {512}<>file works (I doubt David Korn is going
to like that and I am not going to like it either).
If you are done please post to ast-us...@research.att.com to that
Chester Ramey <chet.ra...@case.edu> can port this to bash :)
Josh
_______________________________________________
ast-developers mailing list
ast-developers@research.att.com
https://mailman.research.att.com/mailman/listinfo/ast-developers
