Jim Meyering wrote:
Matthew Woehlke <[EMAIL PROTECTED]> wrote:
Jim Meyering wrote:
...
I did a survey, some time ago, of reasonable porting targets, and all
had fchdir. Eventually I should remove the test for fchdir, too.
So NSK/OSS has just been demoted to 'unreasonable'? Or can we go with
Bruno's suggestion and implement a wrapper ala Cygwin?
A well-written fchdir module would be welcome. Such a module would have
no effect on coreutils proper, other gnulib modules, or any system with
fchdir support.
Ok, thanks... Anyway, here's a start:
struct fd_heap_node {
int fd;
const char * path;
}
int
fchdir (int fd)
{
struct fd_heap_node n = fdheap_get(fd);
if (!n)
{
errno = EBADF;
return -1;
}
return chdir (n->path);
}
int
open (const char* pathname, int flags)
{
int fd = SYS_open (pathname);
if (fd >= 0)
fdheap_add (fd, pathname);
return fd;
}
int
close (int fd)
{
int res = SYS_close (fd);
if (res == 0)
fdheap_del (fd);
return res;
}
...but as I said, I'm not really familiar with how one needs to overload
open()/close(), or if fopen()/fclose() and who-knows-what-else also need
to be overridden. :-)
What about the FD table; should it be a hash table, a binary tree, an
ordered linked list, or something else entirely?
(Can autotools make compilation of this dependent on HAVE_FCHDIR so that
it doesn't need to be in One Big Preprocessor Condition? Am I guessing
right that this - with overloading open()/close() correctly - would mean
that no header is needed?)
--
Matthew
Emacs is a nice OS - but it lacks a good text editor.
That's why I am using Vim. -- Anonymous
