David Green <david.gr...@telus.net> wrote: > Maybe setting $*CWD just calls chdir() under the hood? Same implementation, > brand new shiny Perl-style interface!
I don't think that's a good idea. Suppose you have code like this: $*CWD = '/some/absolute/path'; $*CWD = '../relative/path'; my $cwd = $*CWD; Assuming that no exception was thrown, should $cwd now be '/some/absolute/relative/path' or '../relative/path' ? If the former, you've broken the user's reasonable expectation that a value assigned to a variable can be retrieved by looking in the same variable. If the latter, $*CWD is a relative path name that doesn't exist in the current directory. Now that I think about it, I'm having doubts about whether it makes sense to have a $*CWD variable at all. Suppose the current directory is /a/b/c, and a different process renames /a/b to /surprise. Should reading $*CWD reflect that? Calling a POSIX-like getcwd() would do, but that's surprising in just the same way. But if $*CWD doesn't reflect external changes, you can't expect to be able to opendir its value; at that point, it doesn't seem very useful. If the motivation for $*CWD is simply so that it can be temporized, perhaps it would be better to provide a more direct method of doing that (preferably using fchdir where available). -- Aaron Crane ** http://aaroncrane.co.uk/
