Chip Salzenberg wrote:
As you know, under Unix, there's no such thing as "the current
directory" as a string. The only durable current directory is the
device and inode of C<stat('.')>. It's not wise to conflate the
current directory with a name that at some point in the past could
have been used to reach it.
So can we make a stronger statement, and say that Perl6 won't think of directories as strings, either. When you ask for a directory, it'll give you an object. If you use one in string context then it will try its best to give you a string that your OS might be able to use to access it (or, thinking about cygwin, a string that a different OS might be able to use...). But if it can't (e.g. when you access a directory relative to one whose name it doesn't know), then it will fail.
A directory object could have a method to tell you if it thinks its stringification is currently valid (i.e. if it can stat it and get the same device+inode). It could also have a method that attempts obtain a currently-valid name.
It'd also suggest that C<open> et al should be methods on a directory object (default object for the global forms would be $*ENV.cwd)
And C<system>, C<exec>, C<qx> etc. shoul be methods on an "environment" object, again defaulting to $*ENV. I should be able to do
my Env $env = $*ENV.clone;
$env.cwd ~= "/..";
$env.system("foo");$env.fork might be interesting, too -- I'd expect it to set $*ENV = $env in the child process. Which could be nice if an Env also has stdout, stdin, etc. methods.
You have to because when a new user asks "how do I get the current working directory?" [...]
How do you get the cwd? You call $*ENV.cwd. How to you get its name? You use it in string context. (Of course, a new user probably won't think to ask that second question: they'll print it, and it'll do what they expect ... most of the time).
