current dir from .command scripts

Macs R We macsrwe at macsrwe.com
Sun Aug 5 13:25:07 PDT 2007


On Aug 5, 2007, at 12:00 PM, macosx-talk-request at omnigroup.com wrote:

>> Sounds to me like you misunderstand what "current working
>> directory" means.
>
> It's true - I'm not understanding this part.
>
>>   It does not mean the directory in which the application is located,
>
> Right - I can see that it doesn't mean that. The question is  *why*
> not?

Ancient, ancient UNIX convention, harking back to Multics in the mid  
'60s.  The directory the user is "sitting" at is much more important  
concept than the directory the command is sitting at.

Say you typed the command:

more subdir/myfile

In order to display this file, more doesn't need to know what  
directory "more" is sitting in, it needs to know what directory the  
user is "sitting" in so that it knows where to look for subdir.  The  
concept of "the directory the user is sitting in" has orders of  
magnitude more utility than "the directory the command is sitting  
in," and so that is what the working directory means.

Plus, realize that "the directory that the command is sitting in" is  
a meaningless concept in the UNIX file system, given the existence of  
hard links.  A command can be located "equally" in two distinct  
directories if the proper hard links are set up.

(Do you recall the little dance that Jaguar Restore Permissions used  
to do every time you ran it -- first "fixing" the access on more, and  
then "fixing" the access to a different value on less, not realizing  
that less was simply a hard link to more and one would immediately  
inherit the access of the other?  That's the same class of problem.)

The Multics OS used to have an API a program could call to get its  
own pathname.  Because of the hard link issue, the UNIX OS never  
did.  There was an API you could use to get the current program's  
inode, instead.  Otherwise, the best you could do was to canoodle  
with the shell (via things like $0) and ask it "how did you invoke me?"
-- 
   Macs R We -- Personal Macintosh Service and Support
     in the Wickenburg and far Northwest Valley Areas.
                             http://macsrwe.com



More information about the MacOSX-talk mailing list