On Wed, Aug 29, 2012 at 2:49 PM, Cedric Blancher
<cedric.blanc...@googlemail.com> wrote:
> On 29 August 2012 13:54, Roland Mainz <roland.ma...@nrubsig.org> wrote:
>> [Forwarding since AT&T's spam filter is on drugs... ;-(( ]
>> ---------- Forwarded message ----------
>> From: ольга крыжановская <olga.kryzhanov...@gmail.com>
>> Date: Wed, Aug 29, 2012 at 1:20 PM
>> Subject: Re: [ast-developers] Fwd: Per thread open(), stat(), rename()
>> and so on, and *at() API
>> To: Lionel Cons <lionelcons1...@googlemail.com>
>> Cc: Roland Mainz <roland.ma...@nrubsig.org>, ast-developers@research.att.com
>>
>>
>> Lionel, there are 2 purposes:
>>
>> 1. Allow that ksh93/libshell can be embedded in other applications
>> (Roland calls this 'back end usage', i.e. the user is not aware that
>> he is interacting with a shell, and neither do any other apis know
>> that, or at least should not have to know about that), with out
>> interfering the calling application by changing the current working
>> directory.
>> 2. Allow that ksh93/libshell and the libast api can have a per thread
>> current working directory.
>>
>> There are 2 proposals how to accomplish that:
>> a) Add wrapper functions for open(), stat(), lstat(), chdir(),
>> fchdir(), access(), eaccess(), rename() and so on, and redirect them
>> to their *at() counterparts, with dirfd set to the current threads cwd
>> fd.
>>
>> or
>>
>> b) Add wrapper cpp macros which redirect open(), stat(), lstat(),
>> chdir(), fchdir(), access(), eaccess(), rename() and so on to their
>> *at() counterparts, but define an extra macro which is AT_FDCWD for
>> non threaded applications, and calls a function to obtain the current
>> threads working directory fd for the current thread, but allows to
>> override this macro on a per source file basis, so that applications
>> like libshell, who maintain their own cwd directory fd, can use that.
>>
>> David and Glenn seems to prefer {a}, while I and Roland prefer {b},
>> because {b} will allow an application to work as back end api without
>> interfering with the global cwd or any other, may be libast based apis
>> cwd. This includes nested usage of libshell, like for system() or
>> wordexp().
>
> I'd prefer option {b}, too. Strongly (sorry David and Glenn :)).
> It sounds like the more sane and flexible way to do this. The big road
> block is that you have to find a solution for old platforms which do
> not have openat() and friends, or EOS (end-of-support) them (I'd
> support that if no platform younger than four years lacks openat() and
> friends).
+1
I think {b} is the only viable option. I have to drink a _lot_ of
Martinis to call {a} even sane.
Irek
_______________________________________________
ast-developers mailing list
ast-developers@research.att.com
https://mailman.research.att.com/mailman/listinfo/ast-developers
