Re: PWD parameter

[Zoltan Hidvegi <hzoli@cs.elte.hu>]

Bart Schaefer wrote:
> } Why do you think that PWD is better be a special parameter?
> 
> Because I like that it can't be *un*set.  That means I can always rely
> on using it in zsh scripts, rather than having to do the silly tests for
> it being set and having to assign it from `pwd` to make sure it's there.

In scripts you can rely on it even if it is non-special since zsh does
set it.  It is more difficult in shell functions.  Even if we do not
allow unsetting PWD it can be changed, unless made read-only.  I'd still
use it.  If the user wants to burn himself, let him do it.  In most cases
you can use ~+ instead of $PWD, ~+ always uses the internal pwd variable.

Note that PWD can be unset even without my patch after typeset +r PWD.
After that, PWD can be unset and assigned, although assignments have no
effect.  And right now you can unset any writable special parameters.

> } Scripts do set PWD and if we want to allow people to
> } use zsh as /bin/sh then we have to allow them to write PWD.
> } If PWD is special, assignments will write directly to the internal pwd
> 
> Why is that necessary?  PWD could be a special parameter without tying it
> to any C variable that zsh uses internally.  That just happened to be the
> way it was done (prior to your patch).

It is always good to reduce the number of special parameters, since they
are more complicated to handle in various places, and sometimes special
parameters behave differently from non-special parameters.

> I don't so much care that it's read-only as I do that it's never unset.
> (Thinking about it, I might throw in "and always contains an absolute
> path to a directory that existed at the time the variable was assiged.")

Looks like you'd like to ignore any changes to PWD, or at least when you
assign it you'd like to check that the assigned value is correct.  This
is exacly how zsh behaves after typeset +r PWD.  Do you prefer that
solution (when assignment is allowd but has no effect)?

Zoltan