0

Variations similar to what I want to ask exist but I could not find the exact question, so I'll ask it here.

Let's say I have a comiled .c file resulting in the executable ex which is located as /mnt/f/C_F/ex. I can very well execute it from within /mnt/f/C_F by ./ex but what if I want to do that from /mnt/f say (or any directory for that matter). I don't want to add /mnt/f/C_F/ to PATH for this.

I could not find a solution and I suppose it's not possible to do so. Please confirm this.

1

Use an absolute path to that file.

/mnt/f/C_F/ex

This should always work regardless of your current working directory. Generally, you probably should prefer absolute paths within scripts for this reason (though there are important exceptions).

2

You can always use the relative or full path to your executable

When you're in /mnt/f, you can run:

C_F/ex
# or
/mnt/f/C_F/ex
  • For some reason, using only the absolute path works for me. I had been trying the C_F/ex and it didn't work, which is why I asked this. Nevertheless, I have a way now. Thanks. – Madhur Panwar Nov 6 '19 at 12:30
  • @MadhurPanwar C_F/ex should work if you are in the directory that contains C_F--that is, if you are in the /mnt/f directory. Paths that start with a / are absolute paths and they work from anywhere. Paths that do not start with / (but start with a directory name) are relative paths; they are resolved relative to the current directory. – Eliah Kagan Nov 6 '19 at 12:40
  • @EliahKagan I understand the differences between relative and absolute paths. Even I expect C_F/ex to work when I am inside of /mnt/f. But it doesn't work. I don't know why. Could it have something to do with the fact that I am using 'Ubuntu subsystem for Windows' and not vanilla Ubuntu terminal? – Madhur Panwar Nov 6 '19 at 13:07
  • @MadhurPanwar I'm not sure why that's not working. You may want to post a new question about that specifically (since this question doesn't seem to cover it, and since you seem to consider this question to be solved, having accepted that answer). If you do, I recommend including the output of file C_F/ex and ls -l C_F/ex, running both from /mnt/f. This should give some relevant information including whether the problem is specific to attempting to run the file. – Eliah Kagan Nov 6 '19 at 13:13
  • @EliahKagan It was my mistake. Actually the .c whose resulting executable is ex contains exec which executes another executable present only inside C_F. I had been overlooking it the whole time. Problem solved! – Madhur Panwar Nov 6 '19 at 13:22
0

Any path1 to the executable file that contains at least one / works. The presence of a / character in a command name tells the shell that you are asking it to run a specific file and that you are specifying the specific place where that file is to be found. This is part of the syntax the shell expects; in most other contexts it is acceptable for (relative) paths to contain no / character.

For an executable that is not in the current directory, that's any path to it at all. There is no way to write the path of a file in another directory without using at least one /. This makes running files in other directories the simpler case, even though it is less familiar.

  • Absolute paths--like /mnt/f/C_F/ex--start with /.

  • Relative paths to a file in another directory--C_F/ex when you are in the /mnt/f directory--always contain a /, even though it is not at the beginning. A relative path without a / is just a filename, identifying a file in the current directory. (The converse is not true though. A relative path may contain a / yet still refer to a file in the current directory; see below.)

    Note that relative paths must still actually refer to the file you want if they are to work, and whether or not a relative path refers to the file you want depends on what directory you are currently in, since the are resolved relative to the current directory.

For an executable that is in the current directory, the shortest relative path does not generally work, because it does not contain a /. Thus, this is the more complicated case, even though it is more familiar. When you are in the directory where an executable ex is located, you can't just run ex, even though ex is a perfectly good relative path to that executable.

The reason it does not work is that a command name that does not contain a / is not treated as a relative path or any path. Instead, it is treated as a filename and searched for in the directories listed in $PATH.2

This is why you use ./ex when you're in the same directory as ex. Every directory contains a . entry that refers to the directory itself. This provides a way to write a relative path that identifies the same file as ex but has a / in it and is thus usable as a command name that the shell treats as a path.

A ./ prefix is thus not a special syntax, but simply the second-simplest way to write a relative path to a file in the current directory, and the simplest way to do so of those that contain a /.


1 In this answer, I use "path" to mean "pathname." This is the most common use of "path," but not the only one. "Path," as I use the term here, should not be confused with the executable search path, which is the collection of directories whose paths are listed, separated by : characters, in the $PATH environment variable.

2 Command names that do not contain a / may also be resolved as non-external commands, such as shell builtins and shell functions.

  • 1
    Awesome explanation! Thanks. I did not know earlier that why in current directory I needed to do the ./, but now I do. – Madhur Panwar Nov 6 '19 at 13:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.