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