Having read all of this thread to date, I'll state a solution which should be elegant and which I'm not sure has been stated yet.

I propose that the concept of "current working directory" in Perl be a completely internal, virtual concept, and each Perl thread has its own "current working directory", and that Perl exclusively talks to the real file-system in terms of absolute paths.


This means that the real file-system's chdir() is never invoked during the execution of a Perl program, and a Perl process' external concept of "current working directory" is static, not changing during its execution, as if the concept didn't actually exist.

When a Perl process starts up, its internal $*CWD starts out identical to the external/system one, but any changes to $*CWD then move them out of sync. When a new Perl thread starts, its own separate $*CWD starts out identical to that of the thread that spawned it, but otherwise evolves separately.

Perl can have a chdir(), but it only affects the virtual concept, same as updates to $*CWD do.

All relative or not-fully-qualified paths used with IO operations in Perl are interpreted relative to the current thread's $*CWD, and then their action takes place external to Perl in terms of absolute/fully-qualified paths in the file system.

If these suggestions are followed, we should have a solution that is all of: simple, thread-safe, portable, no surprises, etc.

(If Perl really must have the ability to change the non-virtual "current working directory", such as because its going to spawn another non-Perl process, then this should use some separate mechanism to what all of Perl's own IO uses, and any such change would have no effect on any Perl $*CWD.)

-- Darren Duncan

Reply via email to