How can I know the absolute path of a running process?
If I have multiple copies of the same application on the disk, and only one is running, as I can see with ps , how can I know the absolute path to distinguish it from the others?
8 Answers 8
% ps -auxwe | grep 24466 root 24466 0.0 0.0 1476 280 ? S 2009 0:00 supervise sshd % sudo ls -l /proc/24466/exe lrwxrwxrwx 1 root root 0 Feb 1 18:05 /proc/24466/exe -> /package/admin/daemontools-0.76/command/supervise
@jarno ls: cannot read symbolic link /proc/28783/exe: Permission denied — it’s not about running the ls command, it’s about accessing the process info of a process not belonging to you. On my box, about 97% of all processes listed in /proc are root processes, and the others are distributed over 11 different users.
ls: cannot read symbolic link ‘/proc/87/exe’: No such file or directory lrwxrwxrwx 1 root root 0 Oct 9 07:05 /proc/87/exe
This gives you the current working directory of the pid, not its absolute path.
Usually the which command will tell you which is being invoked from the shell:
@Kokizzu No, it doesn’t because it doesn’t answer the question at all. The which command only tells you which binary will be run if you execute the command now. The question was «which binary is already running there». Imagine for example having a dozen jdks on your computer. If you want to know for a running java process which jdk it’s been taken from, which doesn’t help you with that. It will only tell you which jdk it will be taken from, if you execute it now. The accepted answer is also the correct one.
An obvious way this answer is wrong: on my machine I run processes with different JDK versions and some 32bits/64bits. If I want to identify the correct jstack/jmap version for the process the answer above will not work while the accepted answer will.
@Kokizzu This only answers the question, «What is the current working directory of the process $pid ?» The edited post still doesn’t answer the question. which merely tells «If the command is on the path, then what is it?»
pwdx return me the absolute path of the exectuable program of the process depending on pid on redhat x64 6.3.
How to find path from where current process/executable is running?
I am running some executables while connected to a local unix server box. Say, I’m trying to run an executable ‘abc’. Now the server might have provided an alias for ‘abc’.. How do I get to know of this path? As in, if I invoke ‘abc’, it might actually run it from, say, /opt/corp/xyz/abc .. How do I get to know from what path I’m invoking the executable? By the way I’m running on HP-UX 😀
6 Answers 6
» which abc » to show which abc you would be calling
or » alias » to list aliases
perhaps «echo $0» from inside a script, or retrieving argv[0] some other way.
If you are running using the PATH environment variable, you could try:
If there is a symbolic link for the command and you want to know the «real» target, you can use something like:
I do not have access to an HPUX system in front of me right now, but this should work:
$ ls -l /opt/local/bin/wish lrwxr-xr-x 1 root admin 22 Feb 3 21:56 /opt/local/bin/wish@ -> /opt/local/bin/wish8.5 $ readlink /opt/local/bin/wish /opt/local/bin/wish8.5 If the command is based on an alias, the following will reveal the alias definition.
depending on how your system is configured, the above commands should provide answers to multiple variations of your question.
Does HP-UX have the «which» command? Run:
If you have it, the which command will tell you which abc program will run from your $PATH .
Thanks all! ‘which’ was the commmand I was after! I’m facepalming myself now as I had already known the command (in Ubuntu).. And it does work like a charm in HP-UX!
EDIT : ‘whereis’ suggested by popcnt is even more appropriate! Thanx a lot man!
if you like mine, go ahead and +1 it, and if satisfactory, you could mark it as the answer to your question. That is typically what you’ll see here on SO, instead of an «answer» from the original poster.
From a command line terminal:
The correct way to get the path of a script on Unix is:
Background: $0 is the filename+path of the script relative to the current directory. It can be absolute ( /. ) or relative ( ../ , dir/. ). So the $(dirname «$0») returns the path (without the filename). Mind the quotes; «$0» can contain spaces and other weird stuff.
We then cd into that directory and pwd will return the absolute path where we end up.
In a C program, you should check argv[0] . I’m not sure whether the shell will put the complete path in there. If you have trouble, I suggest to wrap your executable in a small script which prepares the environment and then invoke your executable with:
Search for executable files using find command
Not all implementations of find are created equal. The option recommended by @sje397 and @William may not be available. It’s better to use the accepted solution shown below.
Me dislikes all proposals shown below which are based on file permissions. Argumentation: for my GNU operating system (Ubuntu) it is possible to set «x» (executable) flag for for instance ASCII text file. No mimics prevented this operation from successful completion. It needs just small mistake/bug for multiple non-intentioned files to get x flag assigned. Therefore gniourf_gniourf’ solutions is my personal favorite. It has however that drawback that for cross-compiled executables needs an emulator or target device.
10 Answers 10
On GNU versions of find you can use -executable :
find . -type f -executable -print For BSD versions of find, you can use -perm with + and an octal mask:
find . -type f -perm +111 -print In this context «+» means «any of these bits are set» and 111 is the execute bits.
Note that this is not identical to the -executable predicate in GNU find. In particular, -executable tests that the file can be executed by the current user, while -perm +111 just tests if any execute permissions are set.
Older versions of GNU find also support the -perm +111 syntax, but as of 4.5.12 this syntax is no longer supported. Instead, you can use -perm /111 to get this behavior.
@sourcejedi Thanks. I was actually only talking about non-GNU versions of find (BSD, in particular) but older versions of GNU find actually did support that syntax too. In newer versions you’ll have to use / instead of + . See the updated answer for more details.
It took me a while to understand the implications of «not identical to the -executable predicate» and «just tests if any execute permissions are set»: It means that -perm +111 may yield false positives, i.e., files that the current user cannot actually execute. There’s no way to emulate -executable by testing permissions alone, because what’s needed is to relate the file’s user and group identity to the current user’s.
Tip of the hat to @gniourf_gniourf for clearing up a fundamental misconception.
This answer attempts to provide an overview of the existing answers and to discuss their subtleties and relative merits as well as to provide background information, especially with respect to portability.
Finding files that are executable can refer to two distinct use cases:
- user-centric: find files that are executable by the current user.
- file-centric: find files that have (one or more) executable permission bits set.
Note that in either scenario it may make sense to use find -L . instead of just find . in order to also find symlinks to executables.
Note that the simplest file-centric case — looking for executables with the executable permissions bit set for ALL three security principals (user, group, other) — will typically, but not necessarily yield the same results as the user-centric scenario — and it’s important to understand the difference.
User-centric ( -executable )
- The accepted answer commendably recommends -executable , IF GNU find is available.
- GNU find comes with most Linux distros
- By contrast, BSD-based platforms, including macOS, come with BSD find, which is less powerful.
find . -type f -perm -111 # or: find . -type f -perm -a=xfind . -type f \( -perm -u=x -o -perm -g=x -o -perm -o=x \) -exec test -x <> \; -printFile-centric ( -perm )
- To answer file-centric questions, it issufficient to use the POSIX-compliant -perm primary (known as a test in GNU find terminology).
- -perm allows you to test for any file permissions, not just executability.
- Permissions are specified as either octal or symbolic modes. Octal modes are octal numbers (e.g., 111 ), whereas symbolic modes are strings (e.g., a=x ).
- Symbolic modes identify the security principals as u (user), g (group) and o (other), or a to refer to all three. Permissions are expressed as x for executable, for instance, and assigned to principals using operators = , + and — ; for a full discussion, including of octal modes, see the POSIX spec for the chmod utility.
- In the context of find :
- Prefixing a mode with — (e.g., -ug=x ) means: match files that have all the permissions specified (but matching files may have additional permissions).
- Having NO prefix (e.g. 755 ) means: match files that have this full, exact set of permissions.
- Caveat: Both GNU find and BSD find implement an additional, nonstandard prefix with are-ANY-of-the-specified-permission-bits-set logic, but do so with incompatible syntax:
- BSD find: +
- GNU find: / [2]
File-centric command examples
- The following examples are POSIX-compliant, meaning they should work in any POSIX-compatible implementation, including GNU find and BSD find; specifically, this requires:
- NOT using nonstandard mode prefixes + or / .
- Using the POSIX forms of the logical-operator primaries:
- ! for NOT (GNU find and BSD find also allow -not ); note that \! is used in the examples so as to protect ! from shell history expansions
- -a for AND (GNU find and BSD find also allow -and )
- -o for OR (GNU find and BSD find also allow -or )
- With mode prefix — , the = and + operators can be used interchangeably (e.g., -u=x is equivalent to -u+x — unless you apply -x later, but there’s no point in doing that).
- Use , to join partial modes; AND logic is implied; e.g., -u=x,g=x means that both the user and the group executable bit must be set.
- Modes cannot themselves express negative matching in the sense of «match only if this bit is NOT set»; you must use a separate -perm expression with the NOT primary, ! .
- -L instructs find to evaluate the targets of symlinks instead of the symlinks themselves; therefore, without -L , -type f would ignore symlinks altogether.
# Match files that have ALL executable bits set - for ALL 3 security # principals (u (user), g (group), o (others)) and are therefore executable # by *anyone*. # This is the typical case, and applies to executables in _system_ locations # (e.g., /bin) and user-installed executables in _shared_ locations # (e.g., /usr/local/bin), for instance. find -L . -type f -perm -a=x # -a=x is the same as -ugo=x # The POSIX-compliant equivalent of `-perm +111` from the accepted answer: # Match files that have ANY executable bit set. # Note the need to group the permission tests using parentheses. find -L . -type f \( -perm -u=x -o -perm -g=x -o -perm -o=x \) # A somewhat contrived example to demonstrate the use of a multi-principial # mode (comma-separated clauses) and negation: # Match files that have _both_ the user and group executable bit set, while # also _not_ having the other executable bit set. find -L . -type f -perm -u=x,g=x \! -perm -o=x[1] Description of -executable from man find as of GNU find 4.4.2:
Matches files which are executable and directories which are searchable (in a file name resolution sense). This takes into account access control lists and other permissions artefacts which the -perm test ignores. This test makes use of the access(2) system call, and so can be fooled by NFS servers which do UID mapping (or root-squashing), since many systems implement access(2) in the client’s kernel and so cannot make use of the UID mapping information held on the server. Because this test is based only on the result of the access(2) system call, there is no guarantee that a file for which this test succeeds can actually be executed.
[2] GNU find versions older than 4.5.12 also allowed prefix + , but this was first deprecated and eventually removed, because combining + with symbolic modes yields likely yields unexpected results due to being interpreted as an exact permissions mask. If you (a) run on a version before 4.5.12 and (b) restrict yourself to octal modes only, you could get away with using + with both GNU find and BSD find, but it’s not a good idea.
- GNU find comes with most Linux distros