Is there a standard dummy executable file that does nothing in Linux?

Question

Is there a standard dummy executable file that does nothing in Linux? I have a shell command that always opens $EDITOR before the build process to input arguments manually. In my case, my arguments are always already set (this is an automated script) so I never need it, but it still pops up and awaits user input.

To solve this, I created an empty executable file that does nothing, so I can set EDITOR=dummy and the build script calls it, it exits and the build process can start.

My question is, is there an existing official file in Linux that when executed does nothing, a sort of placeholder that I could use for this purpose?

Answer 1

There's the standard utilities true and false. The first does nothing but return an exit status of 0 for successful execution, the second does nothing but return a non-zero value indicating a non-successful result^(*). You probably want the first one.

Though some systems that really want you to enter some text (commit messages, etc.) will check if the "edited" file was actually modified, and just running true wouldn't fly in that case. Instead, touch might work; it updates the timestamps of any files it gets as arguments.

However, if the editor gets any other arguments than the filename touch would create those as files. Many editors support an argument like +NNN to tell the initial line to put the cursor in, and so the editor may be called as $EDITOR +123 filename.txt. (E.g. less does this, git doesn't seem to.)

---

Note that you'll want to use true, not e.g. /bin/true. First, if there's a shell involved, specifying the command without a path will allow the shell to use a builtin implementation, and if a shell is not used, the binary file will be found in PATH anyway. Second, not all systems have /bin/true; e.g. on macOS, it's /usr/bin/true. (Thanks @jpaugh.)

_{(* or as the GNU man page puts it, false "[does] nothing, unsuccessfully". Thanks @8bittree.)}

Answer 2

In the shell, you can use the built-in :. It's not an executable file, but in a shell script or anything executed from a shell script it will do:

$ help :
:: :
    Null command.
     
    No effect; the command does nothing.
     
    Exit Status:
    Always succeeds.

This is perhaps best known for use in a while statement (while :; do break; done), but is not limited to such use. In case you need to do this many times, it's much faster to not start a separate process:

$ time for i in $(seq 1000); do :; done

real    0m0,007s
user    0m0,002s
sys     0m0,004s
$ time for i in $(seq 1000); do /bin/true; done

real    0m0,686s
user    0m0,462s
sys     0m0,217s

Answer 3

@ilkkachu's suggestion of using the true command is probably the best answer, but you could also use the command

sleep 0

Answer 4

There are several do nothing solutions in a shell. Most notably :, a POSIX required null utility.

But you also require that it is an external file.

So: the POSIX standard specified dummy executable files that do nothing could be:

1. Utilities that output nothing and their exit status is success (0) (except were noted) (in order of relevance (IMO):

printf ''             # requires a format. The format may be empty.
test 1                # requires a non-empty string (or number).
[ 1 ]                 # equivalent to test.
true                  # requires no argument.
false                 # requires no argument (exit code IS 1 ).
rm -f ''              # DO NOT USE. requires a file name and will remove it.
sh -c ''              # may load init files into memory, not a clean solution.
                      # but it is almost unheard of that `sh` is missing.
                      # sh -c '' /path/to/file will not damage the file.

2. Utilities that also end on an exit code of 0 but have some output:

echo ''
date +''
expr ''

There may be others ?. search yourself list of executables

But your query also specify (If I understand you correctly) that the called executable is compatible with:

> the actual invocation done by the build system is $EDITOR /path/to/file

That seem to imply that the executable should not use any argument, or, accept one argument and do nothing to it.

I do not know the exact details of your build system, but probably a:

test /path/to/file

Given that EDITOR is set to test should work perfectly fine (or true, or false).

If some output is not a problem (the build system discard the output of the EDITOR), then echo or printf may be suitable also.

Answer 5

/bin/true

true does nothing successfully.

false attempts to do nothing, but fails.

They are implemented in /bin/true and /bin/false.

But because it's sometimes good to do nothing really fast, there is also a shell builtin true. Sometimes you want to fail with doing nothing really fast, so there is a shell builtin false.

The difference between succeeding and failing is the exit status $?. It is 0 for success and anything other than that for failure. Exit status 1 is used to simply indicate failure, but it can be an error code up to 254 to explain what went wrong in detail.

$ true
$ echo $?
0
$ false
$ echo $?
1
$ false
$ echo $?
1
$ echo $?
0

Note how the last echo returns 0 because the echo preceding it succeded.

The exit status is used with the logic operators, like "and" (&&) and "or" (||):

$ true && echo "success"
success
$ false && echo "failure"
$ true || echo "success"
$ false || echo "failure"
failure

Note how after false && echo "failure" and true || echo "success" nothing is printed.

Answer 6

My answer is for a more general case where nothing can mean multiple things. When it means:

• Stopping with a "normal" return code you can use the suggestions mentioned in all other answers
• Stopping without return code: Not possible
• Avoiding a return code by just never stopping sleep 100000d should work for a couple of centuries
• Not handling when it receives signals: Not possible, some signals can't be blocked (e.g. SIGKILL)
  (In theory something similar is possible by creating a forkbomb, but you do not want that)