On 12/30/12 at 05:47pm, Rob Landley wrote:
> On 12/30/2012 05:16:41 AM, Felix Janda wrote:
> > On 12/30/12 at 04:43am, Rob Landley wrote:
> > POSIX contains many surprises. In the section on environment
> > variables it
> > says that $PWD should be set if "pwd -P" was specified. What happens
> > if an
> > error happens seems unspecified.
Sorry, this is wrong. It has been changed between SUSV4 and SUSV3. Now pwd
must not change $PWD. (It would be really nice to have SUSV4 man pages...)
> Translation: pwd must be a shell builtin running within the shell's
> process ID, and cannot sanely be implemented any other way.
>
> It would be nice if they would just _identify_ these. I did a pass to
> find them (in the roadmap), but missed this.
I agree that it's sensible to have it as a builtin. I'm still not sure
whether an external implementation can't be sane, though.
Let's go back to the situation of a directory /dir deleted in a subshell.
What is then the path name of the current working directory of the shell?
(I'd say it's undefined.) Both getcwd() and stat("/dir") fail in this
situation for both the shell and external commands. Does the builtin pwd
have any advantage over the external pwd in making sure that $PWD is sane?
> > > Sigh. And the whole "PWD defaults to -P unless POSIXLY_CORRECT"
> > thing
> > > above: while I'm sure that code is in there, it's not actually what
> > > it's doing here. Because GNU code is INSANE, and someone somewhere
> > > thought this tangle of corner cases might help somehow.
> > >
> > > Right, in the case of a deleted directory $PWD is all we've got, so
> > > have -L (which is the default) print it but first validate it's an
> > > absolute path with no .. in it. Only validate that current directory
> > > and path directory point to the same place if there IS a current
> > > directory. If that's not what they want, -P exists.
> >
> > In the corner case shouldn't pwd (-L and -P) just give an error
> > message?
> > ($PWD does not contain an absolute pathname of the current working
> > directory.)
>
> If something deletes the directory you're working in, "cd .." should
> work if the directory above you exists. That can't happen if $PWD isn't
> there.
What exactly is the relation of this to the pwd command? "cd .." should
call chdir() with "$PWD/.." after canonicalization. On contrast to pwd, cd
_has_ to be builtin since a chdir() in a child process won't affect the
parent shell.
> Also, when a directory gets deleted and recreated I do cd "$(pwd)" all
> the time. It's useful to still have pwd if some other process takes out
> the directory you're in.
Ok, I see that this is handy. Alternative one could use cd "$PWD".
I find that this application really contradicts POSIX since here "." and
"$PWD" are completely different directories.
Your fun corner case is still strange. From playing a bit around bash seems
to keep the PWD in addition to the environment variable somewhere internally
(pwd still works after unsetting $PWD.) On the other hand "pwd -P" seems to
reset this internal state for some reason. Maybe it's a bug. dash also seems
to keep some internal state, but pwd still works after pwd -P has failed.
Felix
_______________________________________________
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
