PWD parameter

PWD parameter

[Zoltan Hidvegi]

The standard does not mention PWD or OLDPWD in the descriprion of the
shell special parameters, they are only mentioned for the `cd' command:

     The cd utility will change the working directory of the current
     shell execution environment; see Shell Execution Environment .  If
     the current working directory is successfully changed, it will save
     an absolute pathname of the old working directory in the environment
     variable OLDPWD and it will save an absolute pathname of the new
     working directory in the environment variable PWD .

This means that PWD is nothing special for the shell, it is just set by
cd.  But between cd's the user is free to use it.  And many scripts in
fact do assign PWD, but they always set it to the current directory.  For
example some configure scripts have this:

# if PWD already has a value, it is probably wrong.
if [ -n "$PWD" ]; then PWD=`pwd`; fi

On zsh PWD is read-only so the shell will complain, although the script
does not terminate.  Also zsh did not export OLDPWD as required above by
the standard.  The quoted standard is `The Single UNIX (r) Specification'
from OpenGroup, I'm not sure that POSIX has these requirements.

The patch is for 3.0.5, it does not work for 3.1.3, I'll post a patch for
that later.

Zoltan


*** Src/builtin.c.orig	Mon Aug 25 22:40:43 1997
--- Src/builtin.c	Sat May 23 23:29:36 1998
***************
*** 986,991 ****
--- 986,1024 ----
  
  /* cd, chdir, pushd, popd */
  
+ /**/
+ void
+ set_pwd_env(void)
+ {
+     Param pm;
+ 
+     pm = (Param) paramtab->getnode(paramtab, "PWD");
+     if (pm && PM_TYPE(pm->flags) != PM_SCALAR) {
+ 	pm->flags &= ~PM_READONLY;
+ 	unsetparam_pm(pm, 0);
+     }
+ 
+     pm = (Param) paramtab->getnode(paramtab, "OLDPWD");
+     if (pm && PM_TYPE(pm->flags) != PM_SCALAR) {
+ 	pm->flags &= ~PM_READONLY;
+ 	unsetparam_pm(pm, 0);
+     }
+ 
+     setsparam("PWD", ztrdup(pwd));
+     setsparam("OLDPWD", ztrdup(oldpwd));
+ 
+     pm = (Param) paramtab->getnode(paramtab, "PWD");
+     if (!(pm->flags & PM_EXPORTED)) {
+ 	pm->flags |= PM_EXPORTED;
+ 	pm->env = addenv("PWD", pwd);
+     }
+     pm = (Param) paramtab->getnode(paramtab, "OLDPWD");
+     if (!(pm->flags & PM_EXPORTED)) {
+ 	pm->flags |= PM_EXPORTED;
+ 	pm->env = addenv("PWD", pwd);
+     }
+ }
+ 
  /* The main pwd changing function.  The real work is done by other     *
   * functions.  cd_get_dest() does the initial argument processing;     *
   * cd_do_chdir() actually changes directory, if possible; cd_new_pwd() *
***************
*** 1023,1028 ****
--- 1056,1062 ----
  	    chdir(unmeta(pwd));
  	}
      }
+     set_pwd_env();
      return 0;
  }
  
*** Src/hashtable.h.orig	Tue Jun  3 02:01:01 1997
--- Src/hashtable.h	Sat May 23 23:05:11 1998
***************
*** 144,154 ****
  IPDEF5("OPTIND", &zoptind, intvarsetfn),
  IPDEF5("SHLVL", &shlvl, intvarsetfn),
  
- #define IPDEF6(A,B) {NULL,A,PM_SCALAR|PM_READONLY|PM_SPECIAL,BR(NULL),SFN(nullsetfn),BR(strvargetfn),0,(void *)B,NULL,NULL,NULL,0}
- IPDEF6("PWD", &pwd),
- 
  #define IPDEF7(A,B) {NULL,A,PM_SCALAR|PM_SPECIAL,BR(NULL),BR(strvarsetfn),BR(strvargetfn),0,(void *)B,NULL,NULL,NULL,0}
- IPDEF7("OLDPWD", &oldpwd),
  IPDEF7("OPTARG", &zoptarg),
  IPDEF7("NULLCMD", &nullcmd),
  IPDEF7("POSTEDIT", &postedit),
--- 144,150 ----
*** Src/params.c.orig	Thu May 14 23:32:24 1998
--- Src/params.c	Sat May 23 23:23:56 1998
***************
*** 135,145 ****
  	    pm->flags |= PM_EXPORTED;
  	    pm->env = addenv("HOME", home);
  	}
- 	pm = (Param) paramtab->getnode(paramtab, "PWD");
- 	if (!(pm->flags & PM_EXPORTED)) {
- 	    pm->flags |= PM_EXPORTED;
- 	    pm->env = addenv("PWD", pwd);
- 	}
  	pm = (Param) paramtab->getnode(paramtab, "LOGNAME");
  	if (!(pm->flags & PM_EXPORTED)) {
  	    pm->flags |= PM_EXPORTED;
--- 135,140 ----
***************
*** 152,157 ****
--- 147,153 ----
  	pm->env = addenv("SHLVL", buf);
  
  	/* Add the standard non-special parameters */
+ 	set_pwd_env();
  	setsparam("MACHTYPE", ztrdup(MACHTYPE));
  	setsparam("OSTYPE", ztrdup(OSTYPE));
  	setsparam("TTY", ztrdup(ttystrname));

Re: PWD parameter

[Bart Schaefer]

On May 23, 11:44pm, Zoltan Hidvegi wrote:
} Subject: PWD parameter
}
} The standard does not mention PWD or OLDPWD in the descriprion of the
} shell special parameters

Personally, I rather like having PWD be a special parameter.  If you go
by the letter of that standard you quoted, PWD would not be set at all
when the shell first started up; it would only become set after a "cd".
That's surely bogus.

I'm all for following standards when the difference is meaningful in some
way, but this seems entirely gratuitous.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: PWD parameter

[Zoltan Hidvegi]

Bart Schaefer wrote:
> On May 23, 11:44pm, Zoltan Hidvegi wrote:
> } Subject: PWD parameter
> }
> } The standard does not mention PWD or OLDPWD in the descriprion of the
> } shell special parameters
> 
> Personally, I rather like having PWD be a special parameter.  If you go
> by the letter of that standard you quoted, PWD would not be set at all
> when the shell first started up; it would only become set after a "cd".
> That's surely bogus.

My patch does set PWD and OLDPWD on startup.  The standard allows that
but does not require it.  Why do you think that PWD is better be a
special parameter?  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.  That was my
main reason for the patch, not the standard, since I link /bin/sh to zsh.
If PWD is special, assignments will write directly to the internal pwd
variable which can cause unexpected shell behavior.  That's why PWD was
read-only.  Alternatively, you can just ignore assignments to PWD without
giving an error message, but that's a bad solution.

As long as you do not try to assign PWD, my patch does not change zsh's
behavior, other than exporting OLDPWD which was not exported before.

Zoltan

Re: PWD parameter

[Bart Schaefer]

On May 24,  2:51am, Zoltan Hidvegi wrote:
} Subject: Re: PWD parameter
}
} 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.

} 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).

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.")

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: PWD parameter

[Zoltan Hidvegi]

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

Re: PWD parameter

[Bart Schaefer]

On May 24, 12:38pm, Zoltan Hidvegi wrote:
} Subject: Re: PWD parameter
}
} Note that PWD can be unset even without my patch after typeset +r PWD.

Hmm, and it doesn't become set again upon "cd".  That, at least, I'd say
is (was) a bug, though I suppose it might be useful in some rare cases.

} And right now you can unset any writable special parameters.

I don't really have a problem with that, in the general case.

} It is always good to reduce the number of special parameters, since they
} are more complicated to handle in various places

I'd definitely agree that we shouldn't be *increasing* the number of special
paramters.  Do the ones that are already there very often need handling that
they don't already get?

} and sometimes special
} parameters behave differently from non-special parameters.

Chuckle.  Well, yes; I imagine that's why they're called "special".

} 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.

The latter, but I wouldn't go so far in defining "correct" as to require
that `cd $PWD` and `cd ~+` put you in the same place -- just that both
ought to succeed.

This is probably wandering farther into philosophy than it's worth ....

} This is exacly how zsh behaves after typeset +r PWD.

Not quite.  For example, my $HOME is /home/schaefer, but that's really a
symlink to /extra/home/schaefer.  In zsh 3.0.5, if I do

	cd $HOME
	typeset +r PWD
	unset PWD
	PWD=/extra/home/schaefer
	echo $PWD

then what I get back is /home/schaefer.  *That* seems a bit odd.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: PWD parameter

[Zoltan Hidvegi]

> } This is exacly how zsh behaves after typeset +r PWD.
> 
> Not quite.  For example, my $HOME is /home/schaefer, but that's really a
> symlink to /extra/home/schaefer.  In zsh 3.0.5, if I do
> 
> 	cd $HOME
> 	typeset +r PWD
> 	unset PWD
> 	PWD=/extra/home/schaefer
> 	echo $PWD
> 
> then what I get back is /home/schaefer.  *That* seems a bit odd.

PWD has nullsetfn as the write function.  Since PWD is special, unset
just sets a flag in the Param node, it does not really unset anything.
The PWD=... assignment clears this flag, restoring the old value of PWD.
The assigned value is lost.

Zoltan

Re: PWD parameter

[Bart Schaefer]

On May 24, 10:02pm, Zoltan Hidvegi wrote:
} Subject: Re: PWD parameter
}
} > 	unset PWD
} > 	PWD=/extra/home/schaefer
} > 	echo $PWD
} > 
} > then what I get back is /home/schaefer.  *That* seems a bit odd.
} 
} PWD has nullsetfn as the write function.

Yes, I know.  What I meant was, I wouldn't mind seeing that particular
aspect change.  But I'm undecided on what exactly I'd like to see happen
upon
	unset PWD
	PWD=randomgarbage

I just think I'd rather it didn't become set to randomgarbage.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com