It would be nice if the bikeshed had aluminum siding.  Er, I mean, if
chdir() changed *CWD and vice-versa, though I'm not sure offhand how
best to code that in idiomatic P6 to avoid the infinite recursion.

Anyway, at the very least, a readonly *CWD holding a cached idea of
the current dir is good.  Not having to call getcwd() is a definite
performance win.  And if it functions like the POSIX shell PWD in
terms of tracking symlinks and translating relative pathnames to match
the apparent cwd instead of the physical one, so much the better.

That is, in ksh/bash, if I do

mkdir -p foo/bar/baz
cd foo
ln -s bar/baz .
cd baz

Now getcwd() (via e.g. /bin/pwd) says I'm in .../foo/bar/baz.  But
$PWD (and the shell builtin "pwd") says ".../foo/baz".  And even
though the directory entry ".."  is a link to ".../foo/bar", if I do
"cd .." I will be back in ".../foo", because the shell translates it
into the equivalent of 'cd "$(basename "$PWD")" '.

Of course, other programs don't apply this logic to their arguments,
which can lead to confusion when e.g. "cd .. && cat myfile" yields a
different result from "cat ../myfile". But in general, this potential
confusion was deemed worth it for the added transparency and utility
of symbolic links.

So perhaps a similar distinction between $*CWD and getcwd() would be
useful in P6. It would cut way down on the "not getting back what you
put in" problem with assigning to $*CWD.  We could minimize that issue
even further by not allowing the assignment of relative pathnames,
only absolute ones (which of course can be constructed by simple ops
on the current value).

On 8/18/09, Carlin Bingham <> wrote:
> 2009/8/18 David Green <>:
>> On 2009-Aug-18, at 3:27 am, Timothy S. Nelson wrote:
>>> On Tue, 18 Aug 2009, David Green wrote:
>> or however that would work in P6.  It may have problems, but by definition
>> they're the same problems as chdir() has.  What am I missing?
> chdir is a familar function with predictable behaviour.
> $*CWD, as a variable that "magically" changes to something other than
> what it was set to, is unfamiliar and unpredictable.
> Now there's nothing wrong with introducing new, unfamiliar
> functionality, if it provides a discernible benefit, but that doesn't
> seem to be the case here.
> --
> Carlin

Sent from my mobile device

Mark J. Reed <>

Reply via email to