Re: pushd/popd/dirs for es

[Zalman Stern <zstern@mv.us.adobe.com>]

[Noah responds that he likes the way his pwd works.]

Ok, so why don't we redefine getwd in libc since your behavior is so much  
more desirable? (Don't laugh too hard. I actually had this argument with some  
bozo I used to work with at CMU. He modified the Andrew Toolkit's  
im_GetCurrentDirectory(*) function to use the PWD environment variable if it  
was set instead of calling getwd. I found this piece of code after spending  
an hour trying to find out why the editor was writing files in the wrong  
directory. I had a PWD environment variable that was set to some random  
directory and not updated so things broke.)

UNIX filesystems (sans circular symlinks) are DAGs not trees and though this  
may offend your sensibilities, it won't go away because you ignore it. There  
are pieces of code that depend on pwd giving the "real" filename. (Usually  
systems programming stuff.) Also, /bin/pwd is useful with distributed  
filesystems where often the only way to find out what machine the current  
directory really lives on is to look at the reverse of the .. path to the  
root.

The argument "if you don't like it, undefine it" is ridiculous. All sorts of  
dubious functionality gets added to software using such logic. The notion  
should be to have one command to do the right user interface thing and one  
command to give the right system level functionality. Csh says dirs does the  
first and pwd (/bin/pwd) does the second. So the answer to your problem is  
don't use pwd when you mean dirs. Simple no?

Do whatever you want in your own environment, but I'd rather not see pwd  
shadowed in the distributed version. (And adding a variable to change the  
behavior is bogus as hell.) 


(*) im_GetCurrentDirectory and im_SetCurrentDirectory were implemented to  
cache the working directory string to eliminate redundant getwd calls.

-Z-