On simple filenames as commands versus arguments

Question

I am reading Sobell's A Practical Guide to Linux Commands, Editors, and Shell Programming, 4e, and I am currently starting Chapter 5 on the basics of shells.

On page 135 Sobell explains that

From the command line, there are three ways you can specify the name of a file you want the shell to execute: as an absolute pathname (starts with a slash [/]; page 90), as a relative pathname (includes a slash but does not start with a slash; page 91), or as a simple filename (no slash).

Further, he writes that

When you specify a simple filename (no slash), the shell searches through a list of directories for a filename that matches the specified name and for which you have execute permission. The shell does not look through all directories but only the ones specified by the variable named PATH.

Importantly, he notes that the working directory is generally not part of PATH.

My question is therefore about understanding how (why?) the shell seems to behave differently based on whether a simple filename is passed as a command versus an argument to a command.

Up until this point in the book, I have understood simple filenames to simply be a special case of relative paths wherein we don't need a slash because the given file is directly a child of the working directory. Thus, for example, if I have a file named foo in my home directory and I am in my home directory, then

ls -l foo

will give me detailed information about foo (I have passed foo, a simple filename, as an argument to ls).

Now it seems that the behavior is different with respect to commands which are themselves programs/files/executables (you'll forgive my naivete and lack of precision here I hope). When I simply give the following to the command line, Sobell seems to be saying that the shell looks through directories in the PATH and not through the working directory necessarily (unless that is part of PATH):

ls

That is, in the specific case that a simple filename is given as a command rather than as an argument, the behavior of the shell in terms of where it looks is different. Is this understanding correct?

Answer 1

Yes. Your understanding is correct.

You can see this if you move to the /tmp directory and create a text file containing the word 'text':

cd /tmp
echo 'text' > file.txt

Now these commands are all interchangeable:

cat /tmp/file.txt
cat ./file.txt
cat file.txt

Each of these commands will display the text contents of the file.

But! If you now create an executable file:

cd /tmp
printf '#!/usr/bin/env bash\n\necho "hi"\n' > executable
chmod a+x executable

You can still access the file as before, since it is still a file:

cat /tmp/executable
cat ./executable
cat executable

But, in the Bash shell, you can only RUN it like this:

/tmp/executable
./executable

You cannot run the file like this:

executable

That would cause the shell to search the various $PATH locations for a matching executable. Since there are none, the shell will give up and return an error 127 ("Command 'executable' not found").

Why should it work this way?

This is a conscious security decision! If a hacker were to place an executable file in your /tmp directory with a name matching one of the everyday shell commands (e.g. the ls command), then you could wind up running a malicious command without even knowing it.

The solution is to have the shell execute only those trusted commands that you have installed in a $PATH location.

If there's ever a time where you do want to run a one-off script from your current working directory, you can still do that by specifying the path to the executable (e.g. ./executable or /tmp/executable). By providing that extra path information, you're communicating that you do indeed wish to run the executable at that location, and were not tricked into doing it!