1
@user-123:~$ Downloads/execfile-3.4/execfile
@user-123:~$ 
@user-123:~$ cd Downloads/execfileparentdir-3.4/
@user-123:~/Downloads/execfileparentdir-3.4$ execfile
execfile: command not found
@user-123:~/Downloads/execfileparentdir-3.4$ ./execfile
@user-123:~/Downloads/execfileparentdir-3.4$

What's exactly the reason of using ./ behind execfile?

Note that I'm not asking about the functionality of ./. In other words, I wanted to know why in order to run an executable file from terminal it requires the address from current directory to the given file? Why when we are in current directory like the way that the terminal behaves in other cases behave and just recognize the file name automatically so that we run it by just typing the file name instead of putting and ./ behind it?

Edit:

One reason might be the security and preventing the user to accidentally execute another (probably malicious) file. That however is a very credible reason to do so but aren't they sacrificing the consistency of a rule for the sake it? And aren't other ways to handle this problem and not make an exception in a unified rule (the prediction of the file names in current dir)? This may sound like a trivial exchange but I want to be sure if it's the tiniest one.

Mazdak
  • 933
  • @Jesse_b The accepted answer of that question has explained what I've already explained in my question. This question is a little bit deeper. – Mazdak Dec 13 '18 at 19:16
  • Both the accepted answer and the other answers explain why. – jesse_b Dec 13 '18 at 19:17
  • @Jesse_b Yeah but not entirely. No worries tho, I have to bring this to a discussion channel. – Mazdak Dec 13 '18 at 19:19
  • 1
    They do explain it entirely, most noteably mattdm's answer. – jesse_b Dec 13 '18 at 19:20
  • if the answers of the duplicate (especially this one) don't answer your question, please [edit] and clarify which part is still confusing you. You can also ping me and ask to reopen after editing. – terdon Dec 13 '18 at 19:25
  • @terdon I just edited the question. – Mazdak Dec 13 '18 at 19:38
  • You still don't explain what you're missing from the other answer. Have you understood how $PATH works? Is your question simply "why is the current directory not added to $PATH by default"? You seem to be confusing filename expansion with the $PATH variable. Filename expansion works just fine, there is no exception here. – terdon Dec 13 '18 at 19:41
  • @terdon File expansion doesn't work for me. My OS is Ubuntu, could it be a difference behavior over different distributions? – Mazdak Dec 13 '18 at 19:43
  • @Kasrâmvd this would be more easily sorted out in /dev/chat I think. – terdon Dec 13 '18 at 19:44
  • @terdon Yeah that's what I thought. Thanks. – Mazdak Dec 13 '18 at 19:50
  • I share everybody else's confusion as to what you are asking, and what part is confusing you.  I'll take a shot in the dark and throw this out for your consideration: the "rule" whose consistency you think is being violated — doesn't exist!  There are, and have always been, two *separate* rules.  Ordinary files (data files), as you say, are always looked for in the current directory if no path is specified.  For example, if you type cat README, cat looks for README in the current directory. … (Cont’d) – G-Man Says 'Reinstate Monica' Dec 14 '18 at 02:56
  • (Cont’d) …  (There may be a few, obscure, exceptions to this;  for example, if you say #include <stdio.h> in a C program, the C compiler looks for /usr/include/stdio.h.)  But the shell, after eliminating cat as a builtin or a keyword, looks for it in /bin and the other directories specified by PATH.  If the "unified rule" that you're talking about actually existed, you'd always have to type /bin/cat, /bin/cp, /bin/ls, etc. – G-Man Says 'Reinstate Monica' Dec 14 '18 at 02:56

1 Answers1

3

This is architecture decision in UNIX and Linux. The main reason is security. You do not want to execute random file just because you are in the directory where the file is located. And this give you more precise control where are the trusted sources of executable files.

Of course you can add current directory in the path and have MS Windows like behaviour. The command is something like below, but don't do it, as it is a security risk.

export PATH=$PATH:.

Romeo Ninov
  • 17,484
  • Yeah that's a very credible reason to do so but aren't they sacrifice the consistency of a rule for its sake? And aren't other ways to handle this problem and not make an exception in a unified rule? This may sound like a trivial exchange but I want to be sure if it's the tiniest one. – Mazdak Dec 13 '18 at 19:29
  • On this time (when UNIX was created) they make the rules. So MS add the idea of current directory :) – Romeo Ninov Dec 13 '18 at 19:31
  • 2
    but don't do it, as it is a security risk. Of course I won't I'm looking for ways to reduce the chaos :)). – Mazdak Dec 13 '18 at 19:39