Sorry for this repeated hair-splitting. On 01/12/13 at 11:33pm, Rob Landley wrote: > On 01/10/2013 02:25:13 PM, Felix Janda wrote: > > On 01/02/13 at 12:41am, Rob Landley wrote: > > > What I did was disable #3 in the case where cwd doesn't exist. So > > the > > > new rule #3 is: > > > > > > 3) If cwd exists and $PWD doesn't point to it, fall back to -P. > > > > Thanks for the clarification. > > > > Your version of 3) depends on whether pwd is builtin or not. Do you > > mean > > something like "If getcwd() fails ..."? > > cwd is what getcwd() returns. $PWD is an environment variable.
I wanted to differentiate between the current working directory and its name. Doesn't an unliked current working still exist for the processes its the cwd of? (I was wrong about that 3) depends on whether pwd in builtin or not since child processes inherit cwd.) > > > > BTW, in the case that one has deleted and recreated one's current > > > > working > > > > directory one could also use "cd ." to get to the new directory. > > > > > > Good to know. (This means the shell is special casing "." as well as > > > "..". I need to read the susv4 shell stuff thoroughly, it's been > > > years...) > > > > The susv4 page special cases "." and ".." a bit, but it seems to me > > only > > in the $CDPATH handling. Ah, I see that you don't care about $CDPATH > > from > > the about page. > > $CDPATH and $PWD are separate. I just read http://landley.net/toybox/about.html: > And some things (like $CDPATH support in "cd") await a good explanation > of why to bother with them. and interpreted it as a reluctance to implement $CDPATH support. > > Then I think one can leave out step 5 on susv4's page on > > cd, and "cd ." is no more special than "cd dir"; it does a chdir to > > "$PWD/." > > or "$PWD/dir" respectively and then updates $PWD to its canonical > > form. (and > > modifies $OLDPWD also if necessary) > > Um, steps 4 and 8 are the ones that say cd . and .. are special? Step 4 means that $CDPATH shouldn't be taken into account when you do something like "cd ./dir" or "cd ../dir". In Step 8 the usual formal processes of simplifying a path (by removing "." dot components and so on) described. Of course here "." and ".." are treated specially, but this treatment affects only $PWD, since chdir("/some/dir/.") should do the same as chdir("/some/dir"). Step 9 looks like fun... > > Another interesting situation is if your current directory "/dir" has > > been > > moved to "/olddir" and say "/dir" has been recreated. Then "cd ." > > will move > > you to new directory whereas "cd $(pwd -P)" will preserve your cwd > > and fix up > > $PWD. (at least for a shell behaving posixly correct) > > Preserving the cwd is what I wanted to do, yes. > > > Imagine the same situation but with "/dir" not being recreated after > > being > > moved. Then "cd ." should fail according to susv4 since "$PWD/." = > > "/dir/.", > > which does not exist. Would you like to have "cd ." behave the same as > > "cd $(pwd)" in this case? Bash does this if not in POSIX mode. > > Busybox ash > > doesn't do this and for some reason even "cd $(pwd)" fails. > > I want the great mass of existing shell scripts to work, which means > reproducing historical behavior. Posix is (mostly) a reasonable > consensus documentation of historical behavior. Ok Felix _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
