current dir from .command scripts

[Hacker Scot]

On Aug 4, 2007, at 12:13 PM, Macs R We 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?

> it means the directory the user is using for his current base of  
> operations.  When you execute the command from the Terminal it  
> gives the desired results only because you, too, are "sitting at"  
> the Desktop.  But if you "cd" anyplace else and then execute the  
> command by absolute or relative pathname, you will see that the  
> result is wherever you have just cd'ed to, and not the Desktop.
>
> All your experiment shows is that the working directory of a user  
> using the GUI is his home directory.

I can see that that's true, but I don't see why.  If I were writing a  
GUI app and it had to find its current location, my "reasonable  
expectation" (note the quotes) is that there would be something in  
the API that would let it get at that information. Similarly, I would  
expect Finder and Terminal to have a secret handshake so that  
Terminal would be able to pass the current location into the shell as  
an environment variable -- so that pwd, and any relative path  
references in a .command script would work regardless the location of  
the script.

Ultimately it doesn't matter since I've got a workable workaround  
now. I suppose if ".command" usage were more common, something like  
this would have been added to Terminal by now, since it inhibits the  
usefulness of double-clickable scripts. It is at least conceptually  
possible that Terminal could pass this information into the shell,  
isn't it?

./s