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 <car...@theintersect.org> wrote: > 2009/8/18 David Green <david.gr...@telus.net>: >> 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 <markjr...@gmail.com>
