Thus spake Larry Wall:
> Offhand, I guess my main semantic problem with it is that if a chdir
> fails, you aren't in an undefined location, which the new value of $CWD
> would seem to indicate. You're just where you were. Then the user
> either has to remember that, or there still has to be some other
> means of finding out the real location.
To be clear: Only the store operation will return undef on failure.
Additional fetches on $CWD will continue to return the cwd.
$CWD = '/path/which/exists';
$CWD = '/i/do/not/exist' err warn $!;
print $CWD;
This prints /path/which/exists/.
> The other problem with it is the fact that people will assign relative
> paths to it and expect to get the relative path back out instead
> of the absolute path.
I honestly never had this problem until I sat down and thought about it. :)
THEN I got all confused and started to do things like $CWD .= '/subdir';
instead of simply $CWD = 'subdir';. But the rule is simple and natural.
It takes a relative or absolute directory and ALWAYS returns an absolute
path. Lax in what inputs it accepts, strict in what it emits. This is no
more to remember than what chdir() and cwd() would do.
The result from $CWD would simply be a Dir object similar to Ken Williams'
Path::Class or Ruby's Dir object. One of the methods would be .relative.
I didn't bring up @CWD because I thought it would be too much in one sitting.
Basically it allows you to do this:
pop @CWD; # chdir ('..');
push @CWD, 'dir'; # chdir ('dir');
print $CWD[0]; # (File::Spec->splitdir(abs_path()))[0];
# ie. What top level directory am I in?
and all sorts of other operations that would normally involve a lot of
splitdir'ing.
And then there's %CWD which I'm toying with being a per-volume chdir like
you can do on Windows but that may be too much of a questionable thing.
> Your assumption there is a bit inaccurate--in P6 you are allowed to
> temporize (localize) the effects of functions and methods that are
> prepared to deal with it.
Yeah, we were talking about it on #perl6 a bit. That seems to me the more
bizarre idea than assigning to something which can fail. Localizing an
assignment is easy, there's just one thing to revert. But function calls can
do lots of things. Just how much does it reverse? I guess if its used
sensibly on sharp functions, such as chdir, and the behavior is
user-definable it can work but I don't know if the behavior will ever
be obvious for anything beyond the trivial.
FWIW my prompting to write File::chdir was a desire was for "local chdir".
So if "temp chdir" can be made to work that would solve most of the problem.
If nothing else perhaps chdir() should be eliminated and cwd() simply takes
an argument to make it a getter/setter.
> However, I agree that it's nice to have an
> easily interpolatable value. So I think I'd rather see $CWD always
> return the current absolute path even after failure
The problem there is it leaves $CWD without an error mechanism and thus
becomes an unverifiable operation. You have to use chdir() if you want to
error check and $CWD is reduced to a "scripting" feature.
It could throw an exception but then you have to wrap everything in a try
block. Unless Perl 6 is going this route for I/O errors in general I'd
rather not.
I'll give the error mechanism some more thought.
Anyhow, I encourage folks to play with File::chdir and see what they think
of the idea. I'm fixing up the Windows nits in the tests now.
