Can a script know its own location (not cwd)?
 

Elsewhere people have given a great discussion and solution to how a script can find its own cwd.

The best solution seemed to me to be However if you source the script instead of running it, this gives the current working directory from which you called the script, not the directory in which the script itself resides, which makes sense when you think about it.

So, how can a script find out where it actually is?

Here's the scenario: I have a number of slightly different versions of a project in different folders in my home directory, which I want to compile intermittently. Each version contains certain libraries and output folders which have been hard-coded into the build process (not by me) to be located using environment variables. What I want is to be able to have the same script sit in the top level folder of each of these different project versions and source them to set the relevant paths for that version, relative to that top directory, and add them to the environment before I go to build.

So how can the scripts find out where exactly they are, without having to cd into each directory before I source them?



( P.S.
Just to preclude distractions on points of practicality: I liked this quote I found in a related thread:
I agree. A better solution would probably be for the build script to optionally take directory flags and work from the env in their absence, but I don't really have the experience to hack up such a thing. It's a big old project (wxWebKit) and I'm quite unfamiliar with it. Perhaps at some point I can make a feature request for a more flexible build process.

In the meantime I think this is an interesting scripting problem anyway :-] )

The short answer is no.

The long answer is not reliably nor portably. Here’s a hint: if you are willing to live with a dependence on bash, try looking at $BASH_SOURCE.

What am I missing?

No matter what I am doing in a terminal, I can type "pwd" to see where I am. Why cannot a script do the same?

Because he's not asking for his current working directory but for where the script
resides... e.g. if you happened to be in /tmp, and were to source e.g. /etc/bash_profile
he'd like to be able to print /etc from the sourced script, not /tmp


Cheers,
Tink

What's wrong with `which $0` too easy; I must be missing something too.

Too easy; something must be wrong :)
 

Nice one, I like it! We can't *all* be missing something *all* of the time ;) though surely we (I at least) all miss something *some* of the time.

His script, like /etc/bash_profile, may not be in the $PATH,
in which case `which $0` won't work, will it ... worse, there
may be a different script with the same name in the $PATH .



Cheers,
Tink

micxz@phybernuker:/tmp/tester/somewhere> cat where
#!/bin/bash

dirname `which $0`
micxz@phybernuker:/tmp/tester/somewhere> ./where
/tmp/tester/somewhere
micxz@phybernuker:/tmp/tester/somewhere> pwd
/tmp/tester/somewhere
micxz@phybernuker:/tmp/tester/somewhere> echo $PATH | grep tmp

Maybe I'm missing something again' But tmp is not in my path.

How about . ?

This is not possible, bcoz it not (and never,) the current working directory where the executable resides. The current working directory of a process is the path from it was invoked, i.e. process created.

Guru

hello miz,
it will show u always PWD. not the location of script.

Here is something that should work with bash and ksh.

Should work but:

source:
micxz@phybernuker:~/scr> cat where
#!/bin/bash
cd /tmp
echo now in: $(pwd)
scriptDir=$(cd $(dirname $0);pwd)
echo $scriptDir

output:
micxz@phybernuker:~/scr> ./where
now in: /tmp
/tmp

Indeed.
The scriptDir setting should be done before the script change its current directory.

Of course' just trying to stir it up' You can always save the var and us it later; Issue seems solved to me? Where's the original poster'