Re: [AOLSERVER] BIG problem with Tcl8.4.(1|2)
On Wednesday 26 March 2003 20:03, you wrote: > 1. Are there ANY cases where a TLS (thread local storage) cd/pwd would > be the WRONG thing? E.g., could we reasonally expect there to be any > cases where one thread A does "pwd", gets "/home/my", does "cd /foo", > and then thread B does "pwd" and EXPECTS to get "/foo" back as the > result? Any such cases in Tcl? In AOLserver? In libgcc? Anywhere > in any C libraries whatsoever? I did not understand. The scenario you've used (thread A/B) is what *is* usually happening. The thread B gets "/foo" and this is what is expected. But, this is not the source of the problem. The source of the problem is that Tcl internal code remembers the process-wide current working directory in an global Tcl object and neglects to properly lock access to this object for ALL operations, in addition to blindly passing the same object to other threads. We'd need to talk to the Tcl FS implementor and get him/them abandon the object storage in favour of simple char* or put the object into the TSD. > 2. At what level would this hypothetical TLS cd/pwd implementation > need to be inserted? Are there OS-provided library functions that > themselves use cd/pwd, and would thus need to be overriden or > otherwise worked around? Or do Tcl and AOLserver have their own entry > points to all C function calls using cd/pwd, and we could implement > the TLS stuff there? Tcl has all FS-code abstracted in a form of pluggable filesystems. So, you never actually go down to the OS-level without passing N layers of Tcl code. The whole stuff is pretty frightening (just go and look into the generic/tclIOUtil.c and you will see why) but it does gives you a powerful abstraction. Again, I'm sorry if I misunderstood your question(s). I think that you can't protect yourself from the effects of the [cd]. You will, however need to know (from the docs, I suspect) wether some code does change the cwd, and if it does, ypu must take care to put the locks arround it, if necessary for your app. I think it would be good to know what exact spots in Tcl might be potential [cd] doers. I will try to grep the code and see what is done where. Cheers, Zoran -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
Re: [AOLSERVER] Database handles not being released in 4.0
On Wednesday, March 26, 2003, at 10:15 PM, paul cannon wrote: So http://aolserver.com/docs/devel/tcl/api/db.html is at best misleading: "ns_db releasehandle puts the handle back in the pool. When your operation has finished running, the server will automatically return any handles to their pools, so you don't normally have to call this function." I may have misunderstood the meaning of "operation". No, I think you have it right. I never noticed this, and I just checked and it was in the 2.x docs. That'll teach me not to read the docs carefully enough. In my opinion, it's a bug. You should file it in SourceForge. At this point, I think my superstition about not trusting AOLserver to clean up the handles is probably still appropriate. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
Re: [AOLSERVER] Fwd: AOLServer 4
On Thursday, March 27, 2003, at 02:22 AM, Andrey Chichak wrote: I want migrate from apache+php to aolserver+python :o) Do you know about PyWX? http://pywx.idyll.org/ -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
Re: [AOLSERVER] Fwd: AOLServer 4
> I want migrate from apache+php to aolserver+python :o) Ehrm, if you are porting anyway, why not go with the native language for AOLserver? Bas. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
[AOLSERVER] AOLserver 4.x and MacOSX: cwd problem
For all you Mac OSX users out there... This is kind of continuation of the [cd] and [pwd] problem(s) I've already covered in my last posting. The Tcl8.4.x uses the OS-call realpath() to figure-out the real physical path of the file on the filesystem, stripped of all "./", "../", constructs, symlinks and alike. BANG: this function uses chdir/fchdir internally which changes the process current working directory for each invocation. It is called for just about *every* path you pass to the Tcl library! Wow! The funny thing: the man page does not care to mention this *important* side-effect! Of course, this defeats *any* multithreading code. There is no single point like [cd] command which mingles with the current dir; *all* path arithmetics eventually call into the realpath() and it will swap the current dir under your feet. This is not the case in Solaris and/or Linux OS. It appears to me that it only happens on Mac OSX (aka Darwin). First corrective measure is to define NO_REALPATH variable on Tcl compilation time. I have yet to figure out how to do this from the configure step, but the quick/dirty way is to go to the unix/tclUnixFCmd.c file and put at the very top of the file: #define NO_REALPATH and recompile/reinstall the Tcl. This solves this issue cleanly. The ultimate fix, of course, is to modify the Darwin realpath() to behave better. Concerning the memory trashing problems described in my previous mail, I have made a fix and will try to negotiate with the Tcl people to get it into the Tcl project asap. Cheers, Zoran -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
Re: [AOLSERVER] AOLserver 4.x and MacOSX: cwd problem
+-- On Mar 27, Zoran Vasiljevic said: > Tcl. This solves this issue cleanly. The ultimate fix, of course, is > to modify the Darwin realpath() to behave better. I wonder what you mean by "behave better". Does realpath() leave the cwd changed? Or do you simply mean that you don't want realpath() to ever use chdir()? A correctly working realpath() must use chdir() at least sometimes. System calls only accept paths up to PATH_MAX bytes long, but the filesystem allows us to construct paths of any length. The only reliable way to access those long paths is by using chdir(). realpath() could safely use chdir() even in a multithreaded program by forking, computing the path (possibly using chdir()) in the child, and passing the result back to the parent over a pipe. Obviously this could be optimized to only fork when it discovers that it must call chdir(). -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
Re: [AOLSERVER] AOLserver 4.x and MacOSX: cwd problem
+-- On Mar 27, Rob Mayoff said: > A correctly working realpath() must use chdir() at least sometimes. > System calls only accept paths up to PATH_MAX bytes long, but the > filesystem allows us to construct paths of any length. The only reliable > way to access those long paths is by using chdir(). Actually, now that I think about it, realpath is documented to take an output buffer of only PATH_MAX bytes, so this doesn't apply to PATH_MAX. But the problem remains for any program that wants to reliably compute pathnames. And realpath should have been written to allocate a suitably-sized output buffer... -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
Re: [AOLSERVER] AOLserver 4.x and MacOSX: cwd problem
+-- On Mar 27, Rob Mayoff said: > Actually, now that I think about it, realpath is documented to take > an output buffer of only PATH_MAX bytes, so this doesn't apply to > PATH_MAX. It meant "doesn't apply to realpath()", of course. Darn it. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
Re: [AOLSERVER] AOLserver 4.x and MacOSX: cwd problem
On Thursday 27 March 2003 18:51, you wrote: > +-- On Mar 27, Zoran Vasiljevic said: > > Tcl. This solves this issue cleanly. The ultimate fix, of course, is > > to modify the Darwin realpath() to behave better. > > I wonder what you mean by "behave better". Does realpath() leave the cwd > changed? Or do you simply mean that you don't want realpath() to ever > use chdir()? Well, I havent thought that much of what "behave better" should really mean. I understand that it might need to use chdir eventually but the Apple implementation does this *always*, no matter which path it gets fed. Other implementations, like Solaris, Linux, when feeded with "decent" absolute paths, do not attempt to chdir at all. The thing is that from the outside, everything is ok, i,e. the cwd stays the same before and after entering the function. The problem is that other threads might (and do) creep in between. All this, coupled with recent virtual filesystem changes to Tcl yield a total disaster: the application starts to break all arround. The real net effect is that *whatever* path you pass to Tcl, it eventually gets thru the realpath() and this tweaks your cwd. This is huge PITA. I'm fighting with this already for couple of days. This is how I discovered the memory trashing reported previously. The difference is that this bug is kind of Mac OSX specific, while the other is really applicable to all platforms. Cheers, Zoran -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
Re: [AOLSERVER] AOLserver 4.x and MacOSX: cwd problem
On Thursday 27 March 2003 18:46, you wrote: > Zoran Vasiljevic wrote: > > For all you Mac OSX users out there... > > > > The Tcl8.4.x uses the OS-call realpath() to > > figure-out the real physical path of the > > file on the filesystem, stripped of all "./", > > "../", constructs, symlinks and alike. > > > > BANG: this function uses chdir/fchdir internally > > which changes the process current working directory > > for each invocation. It is called for just about > > *every* path you pass to the Tcl library! Wow! > > The funny thing: the man page does not care to > > mention this *important* side-effect! > > This is truly sick, Zoran. Truly sick. An extremely obnoxious > side-effect, even if it were documented. Does Apple have a process for > filing bug reports that would give us some hope one of their Unix > hackers will see it? I really do not know. I think we might go to Darwin site and try to file a bug report. Cheers, Zoran -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
Re: [AOLSERVER] BIG problem with Tcl8.4.(1|2)
On Thu, Mar 27, 2003 at 10:15:33AM +0100, Zoran Vasiljevic wrote: > On Wednesday 26 March 2003 20:03, you wrote: > > > 1. Are there ANY cases where a TLS (thread local storage) cd/pwd would > > be the WRONG thing? E.g., could we reasonally expect there to be any > > cases where one thread A does "pwd", gets "/home/my", does "cd /foo", > > and then thread B does "pwd" and EXPECTS to get "/foo" back as the > > result? Any such cases in Tcl? In AOLserver? In libgcc? Anywhere > > in any C libraries whatsoever? > > I did not understand. > The scenario you've used (thread A/B) is what *is* usually happening. > The thread B gets "/foo" and this is what is expected. Yes, of course, and it can often breaks things, right? Most users of cd/pwd seem to want to neglect the fact that the pwd state is per-process not per-thread, so perhaps it would be simpler just to give them that, thus side-stepping the locking issues. Therefore, assume a TLS cd/pwd implementation, where each and every thread has it's OWN independent current working directory. Does any code break because of this? In other words, is there any code anywhere that both, a), properly treats pwd as per-process not per-thread, and b), DEPENDS on the sharing of pwd across threads for its correct behavior? > But, this is not the source of the problem. The source of the problem > is that Tcl internal code remembers the process-wide current working > directory in an global Tcl object and neglects to properly lock access > to this object for ALL operations, in addition to blindly passing the > same object to other threads. And if that object were TLS, per-thread, then the error could not occur. It might cause OTHER problems, which is what my questions above were getting at, and it might plain not be feasible to implement. But a TLS pwd would solve the "blindly passing a process-wide object to other threads" problem above, because it wouldn't be process-wide anymore, it'd be per-thread. Clearly from what you say it's at least a bit more complicated than that though. I probably can't contribute any more usefully to the discussion until/unless I go look at the Tcl core code you're talking about... > We'd need to talk to the Tcl FS implementor and get him/them abandon > the object storage in favour of simple char* or put the object > into the TSD. What's the TSD? > Again, I'm sorry if I misunderstood your question(s). I think that > you can't protect yourself from the effects of the [cd]. You will, I wasn't trying to protect myself, I was hypothesizing about possible designs/implementations for fixing the problem in Tcl. :) The fact that some system calls apparently change pwd and then change it back when they complete is really obnoxious, because that means that for proper mt-safe operation, those system calls MUST expose a mutex which any of YOUR pwd-changing code will explicitly lock and unlock as well. This is a general obnoxious feature of multi-threaded programming with multiple libraries - a given mutex sometimes must be seen and used across ALL libraries, not just within one library. I've run into that before and solved it by overriding library functions with my own mt-safe TLS versions of those functions, which let me avoid having to try to share a single mutex across multiple non-cooperatiung libraries. Thus I immediatly wondering about the possibility of using TLS to solve the cd/pwd bugs you described... > I think it would be good to know what exact spots in Tcl might be > potential [cd] doers. I will try to grep the code and see what Definitely, that would be good to know. -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
Re: [AOLSERVER] BIG problem with Tcl8.4.(1|2)
It seems that if people wanted to use generally-available TCL packages inside AOL, it'd be nice if cd worked and was per-thread. Otherwise, even if the TCL internals are fixed to lock around the temporary cd fiddling it does in realpath or wherever else, ordinary TCL packages still won't work in a threaded environment if they use cd. We've run into this problem ourselves, when we had to bring external TCL scripts into the web server, for coordination & scheduling purposes. Jim > > On Thu, Mar 27, 2003 at 10:15:33AM +0100, Zoran Vasiljevic wrote: > > On Wednesday 26 March 2003 20:03, you wrote: > > > > > 1. Are there ANY cases where a TLS (thread local storage) cd/pwd would > > > be the WRONG thing? E.g., could we reasonally expect there to be any > > > cases where one thread A does "pwd", gets "/home/my", does "cd /foo", > > > and then thread B does "pwd" and EXPECTS to get "/foo" back as the > > > result? Any such cases in Tcl? In AOLserver? In libgcc? Anywhere > > > in any C libraries whatsoever? > > > > I did not understand. > > The scenario you've used (thread A/B) is what *is* usually happening. > > The thread B gets "/foo" and this is what is expected. > > Yes, of course, and it can often breaks things, right? Most users of > cd/pwd seem to want to neglect the fact that the pwd state is > per-process not per-thread, so perhaps it would be simpler just to > give them that, thus side-stepping the locking issues. > > Therefore, assume a TLS cd/pwd implementation, where each and every > thread has it's OWN independent current working directory. Does any > code break because of this? In other words, is there any code > anywhere that both, a), properly treats pwd as per-process not > per-thread, and b), DEPENDS on the sharing of pwd across threads for > its correct behavior? > > > But, this is not the source of the problem. The source of the problem > > is that Tcl internal code remembers the process-wide current working > > directory in an global Tcl object and neglects to properly lock access > > to this object for ALL operations, in addition to blindly passing the > > same object to other threads. > > And if that object were TLS, per-thread, then the error could not > occur. It might cause OTHER problems, which is what my questions > above were getting at, and it might plain not be feasible to > implement. But a TLS pwd would solve the "blindly passing a > process-wide object to other threads" problem above, because it > wouldn't be process-wide anymore, it'd be per-thread. > > Clearly from what you say it's at least a bit more complicated than > that though. I probably can't contribute any more usefully to the > discussion until/unless I go look at the Tcl core code you're talking > about... > > > We'd need to talk to the Tcl FS implementor and get him/them abandon > > the object storage in favour of simple char* or put the object > > into the TSD. > > What's the TSD? > > > Again, I'm sorry if I misunderstood your question(s). I think that > > you can't protect yourself from the effects of the [cd]. You will, > > I wasn't trying to protect myself, I was hypothesizing about possible > designs/implementations for fixing the problem in Tcl. :) > > The fact that some system calls apparently change pwd and then change > it back when they complete is really obnoxious, because that means > that for proper mt-safe operation, those system calls MUST expose a > mutex which any of YOUR pwd-changing code will explicitly lock and > unlock as well. This is a general obnoxious feature of multi-threaded > programming with multiple libraries - a given mutex sometimes must be > seen and used across ALL libraries, not just within one library. > > I've run into that before and solved it by overriding library > functions with my own mt-safe TLS versions of those functions, which > let me avoid having to try to share a single mutex across multiple > non-cooperatiung libraries. Thus I immediatly wondering about the > possibility of using TLS to solve the cd/pwd bugs you described... > > > I think it would be good to know what exact spots in Tcl might be > > potential [cd] doers. I will try to grep the code and see what > > Definitely, that would be good to know. > > -- > Andrew Piskorski <[EMAIL PROTECTED]> > http://www.piskorski.com > > > -- > AOLserver - http://www.aolserver.com/ > To Remove yourself from this list: http://www.aolserver.com/listserv.html > List information and options: http://listserv.aol.com/ > -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
Re: [AOLSERVER] BIG problem with Tcl8.4.(1|2)
+-- On Mar 27, Andrew Piskorski said: > And if that object were TLS, per-thread, then the error could not > occur. It might cause OTHER problems, which is what my questions > above were getting at, and it might plain not be feasible to > implement. But a TLS pwd would solve the "blindly passing a > process-wide object to other threads" problem above, because it > wouldn't be process-wide anymore, it'd be per-thread. Perhaps you do not realize that a process's current working directory is tracked by the kernel, not by the process. Tcl keeps track of its CWD for speed, but ultimately it's the kernel, not the process, that resolves relative pathnames, so it's the kernel's idea of the CWD that matters. I believe that POSIX requires that all threads in a process share a working directory. Making each thread appear to have its own working directory requires either non-standard kernel support for per-thread CWD (which Linux has, but I don't think you can get to it through the pthreads interface), or intercepting every system call that involves a pathname (open, link, symlink, unlink, rename, access, stat, lstat, chdir, chroot, chmod, chown, lchown, mknod, mkdir, rmdir, bind, connect, and probably some more that I've forgotten). You might be able to ignore some of these for AOLserver, but intercepting any of them isn't necessarily easy, and it's definitely not possible to do so portably. It still might be the best way to fix this problem, though. > What's the TSD? Thread-specific data. Same thing as TLS. > The fact that some system calls apparently change pwd and then change > it back when they complete is really obnoxious, No. Some library calls change the CWD. The only system calls that change the CWD are chdir() and fchdir(). -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
[AOLSERVER] Ns_PgExec looking in wrong place for plpgsql.so
I've compiled pgdriver version 2.0.1 with the PGLIB=/usr/local/pgsql2/lib and PGINC=/usr/local/pgsql2/include. I also compiled postgres with --prefix=/usr/local/pgsql2. I have a run script to startup aolserver that sets the environment var: LD_LIBRARY_PATH=/usr/local/pgsql2/lib AOLserver starts up fine, connects to the database and even does some queries, but it then seems to need some plpgsql help, and it tries to load: /usr/local/pgsql/lib/plpgsql.so but fails with 'undefined symbol: SPI_cursor_open. AOLserver complains: ns_PgExec: result status: 7 message: ERROR: Load of file /usr/local/pgsql/lib/plpgsql.so failed... Any ideas on what I am doing wrong? Also postgres was compiled on another machine. For some reason, 7.1.3 doesn't compile on RH8.0 --Tom Jackson -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
Re: [AOLSERVER] Ns_PgExec looking in wrong place for plpgsql.so
I changed the procsrc attribute of the system table pg_proc for the function. That seemed to allow plpgsql.so to load, but then I get a seg fault. Oh, well. The plpgsql seems to work when I just use psql. --Tom Jackson -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
Re: [AOLSERVER] Ns_PgExec looking in wrong place for plpgsql.so
On Thursday 27 March 2003 17:53, Tom Jackson wrote: > I've compiled pgdriver version 2.0.1 with the Curious as to why the old version > AOLserver complains: > ns_PgExec: result status: 7 message: ERROR: Load of file > /usr/local/pgsql/lib/plpgsql.so failed... That's the PostgreSQL backend issuing that message. > Any ideas on what I am doing wrong? What is the SQL you are executing that produces this error? AOLserver itself (and the postgres driver) doesn't use, need, or try to load plpgsql.so, which is the handler library for PL/Pgsql and is loaded by the PostgreSQL backend. > Also postgres was compiled on another machine. For some reason, 7.1.3 > doesn't compile on RH8.0 No, 7.1.3 won't compile on RH8 due to 7.1.3 not being gcc3-compliant. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
Re: [AOLSERVER] Ns_PgExec looking in wrong place for plpgsql.so
Once I change the setting in the pg_proc table it worked. The next issue was an immediate segfault at the same point it was dying before, but it turned out to be cause by ns_geturl, nothing db related. So I don't know why ns_geturl from aolserver 3.4 would segfault on rh8.0. This was also compiled on an older RH. Lamar Owen wrote: What is the SQL you are executing that produces this error? AOLserver itself (and the postgres driver) doesn't use, need, or try to load plpgsql.so, which is the handler library for PL/Pgsql and is loaded by the PostgreSQL backend. Some sql with a function was called, causing pg to try to load the library. Thanks! --Tom Jackson -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
Re: [AOLSERVER] Ns_PgExec looking in wrong place for plpgsql.so
Hello,
I'm trying to register a procedure to handle:
http://www.foo.net/~user/
type URLs. I want to redirect the request to:
http://members.foo.net/user/
I tried a couple of registerd procedures like:
ns_register_proc-noinherit GET {/~*} tilde_redirect
ns_register_proc-noinherit POST{/~*} tilde_redirect
But the expression doesn't seem to match
anything. I'm sure there is something very
simple I'm overlooking.
Does anyone have any suggestions?
-Ayan
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/
[AOLSERVER] ns_register_proc
Sorry -- wrong Subject:. :(
-- Forwarded message --
Date: Thu, 27 Mar 2003 20:14:56 -0500 (EST)
From: Ayan George <[EMAIL PROTECTED]>
To: AOLserver Discussion <[EMAIL PROTECTED]>
Subject: Re: [AOLSERVER] Ns_PgExec looking in wrong place for plpgsql.so
Hello,
I'm trying to register a procedure to handle:
http://www.foo.net/~user/
type URLs. I want to redirect the request to:
http://members.foo.net/user/
I tried a couple of registerd procedures like:
ns_register_proc-noinherit GET {/~*} tilde_redirect
ns_register_proc-noinherit POST{/~*} tilde_redirect
But the expression doesn't seem to match
anything. I'm sure there is something very
simple I'm overlooking.
Does anyone have any suggestions?
-Ayan
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/
Re: [AOLSERVER] AOLserver 4.x and MacOSX: cwd problem
Zoran Vasiljevic wrote: For all you Mac OSX users out there... The Tcl8.4.x uses the OS-call realpath() to figure-out the real physical path of the file on the filesystem, stripped of all "./", "../", constructs, symlinks and alike. BANG: this function uses chdir/fchdir internally which changes the process current working directory for each invocation. It is called for just about *every* path you pass to the Tcl library! Wow! The funny thing: the man page does not care to mention this *important* side-effect! This is truly sick, Zoran. Truly sick. An extremely obnoxious side-effect, even if it were documented. Does Apple have a process for filing bug reports that would give us some hope one of their Unix hackers will see it? -- Don Baccus Portland, OR http://donb.photo.net, http://birdnotes.net, http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
Re: [AOLSERVER] AOLserver 4.x and MacOSX: cwd problem
Rob Mayoff wrote: +-- On Mar 27, Zoran Vasiljevic said: Tcl. This solves this issue cleanly. The ultimate fix, of course, is to modify the Darwin realpath() to behave better. I wonder what you mean by "behave better". Does realpath() leave the cwd changed? If I read him correctly it does leave the process cwd changed. -- Don Baccus Portland, OR http://donb.photo.net, http://birdnotes.net, http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list: http://www.aolserver.com/listserv.html List information and options: http://listserv.aol.com/
