0

What is the difference between the following

./executable and executable. Why is it, sometimes, some executable (non-Linux commands) don't require ./?

If I have installed an executable through a makefile (a physics code) how can I remove it and install an updated version? Is removing rm the code sufficient? The executable, in this case, is executed without ./

PseudoYousef
  • 13
  • 2
  • 2
    IMHO this is really 2 questions - for the first, see [Why do we use “./” (dot slash) to execute a file in Linux/UNIX?](https://unix.stackexchange.com/questions/4430/why-do-we-use-dot-slash-to-execute-a-file-in-linux-unix) – steeldriver Jul 12 '20 at 20:08
  • That is a different question! I understand the ./ but not sure of the one without it. The question there is concerning a linux command where as I am asking about an executable. – PseudoYousef Jul 12 '20 at 20:19
  • They are the same thing. All commands are executable, and all executables can be a command – roaima Jul 12 '20 at 20:24
  • What does "(non-Linux commands)" mean here? – ilkkachu Jul 12 '20 at 20:43
  • @ilkkachu for example executable obtained from compiling a code or makefile – PseudoYousef Jul 13 '20 at 16:42

1 Answers1

4

In an UNIX environment (and even in other systems like DOS, Windows, etc) there are directories where the shell looks for executables. In an Unix environment it's defined in the PATH variable. You can see the directories in the PATH variable executing the following command:

$ echo $PATH

The result will be something like:

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin

As you can see, the variable is a list of directories separated by a colon. When you run a command, e.g. ls, the system will search for an executable in the first directory of the list (in the example, /usr/local/sbin). If it doesn't find a file named ls there, it will try the next directory, until it finds it. So if your ls command is located on /usr/bin, it will execute. Or, you'll get a command not found error if the shell cannot find it anywhere.

However, there are other ways to call an executable. Imagine you have two programs named ls in two directories in the PATH, and you want to run the second one. The way of doing that might be running /usr/bin/ls, so you specify which one you want.

The . is a shortcut for the current directory. So if you're at /home/user, ./configure is a shortcut for /home/user/configure.

You can remove a file from the PATH by looking for the place it's located and removing it. However, you might prefer to manage binaries installed into your system through a package manager, available in most modern distributions (like rpm, dpkg, pacman, etc). If the Makefile creates several executables, it's going to be easier to remove them this way (also, the makefile might create some library files and several other things, that's why it's easier to use a package management tool). Sometimes a Makefile might bring an uninstall routine (i.e. make uninstall), but I'm not sure how often it happens. If you are updating a program through a new makefile, a new make install would likely replace the old binaries, but there's no guarantee of that.

You can always find out what is the executable for a certain command by running which. For instance, if you want to know where ls is:

$ which ls
/usr/bin/ls
roaima
  • 107,089
  • 14
  • 139
  • 261
Bruno
  • 107
  • 7
  • 1
    Question /85429/ deprecates `which`. `command -V myCmd` is considered safer on Linux. – Paul_Pedant Jul 12 '20 at 22:09
  • Thanks for your input, @Paul_Pedant, I'm really "outdated" as I haven't been using Linux for almost a decade and just returned last week. If you're familiar with the command would you please edit it? I'll take a closer look at it next weekend and don't feel confident enough to do it right now. By now I wasn't table to reproduce the same results yet in certain situations, i.e. my ls command, which is an alias (I assume there might be an option for that case, but I'll need sometime until I fully understand it). – Bruno Jul 15 '20 at 01:01