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?

  • 1
    Can't you just do unset EDITOR or EDITOR="" instead?
    – terdon
    Jul 8, 2020 at 17:27
  • 4
    @terdon: well if you want to open ed or some other silly default.
    – Joshua
    Jul 8, 2020 at 18:24
  • 2
    @terdon, afaik most programs have some fallback, ed or vi perhaps. E.g. less's man page says it takes the editor from "environment variable VISUAL if defined, or EDITOR if VISUAL is not defined, or defaults to "vi" if neither VISUAL nor EDITOR is defined." (Except in Debian it might default to /usr/bin/editor or such.) I think I've also seen shell scripts with ${VISUAL:-${EDITOR:-vi}} or similar. But seldom anything that would just forgo all editing for users that haven't set EDITOR in their startup files.
    – ilkkachu
    Jul 8, 2020 at 19:14
  • 8
    @terdon no, because the actual invocation done by the build system is $EDITOR /path/to/file. When doing EDITOR="", it tries to execute the build file directly.
    – Belval
    Jul 8, 2020 at 19:29
  • Ah, ouch. Yeah, that's no good.
    – terdon
    Jul 8, 2020 at 20:46

6 Answers 6


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.)

  • 7
    That must be /bin/true. Otherwise it would usually be a shell builtin which is not really "a standard dummy executable file". Jul 7, 2020 at 20:51
  • 12
    @HaukeLaging, yes... in practice. The build process or whatever probably doesn't run through the shell, so it'll end up picking /bin/true from the path. Or if it picks the shell builtin, it doesn't really matter. But if I've understood correctly, the standard doesn't really define that it has to be found specifically as /bin/true.
    – ilkkachu
    Jul 7, 2020 at 20:54
  • 22
    The standard allows true and false to be shell builtins but it also requires the commands to be available as executable files in the standard search PATH.
    – schily
    Jul 7, 2020 at 21:21
  • 6
    In SysV Unix, /bin/true was a shell script that contained nothing but a copyright comment. Not sure what they are copyrighting... Jul 8, 2020 at 16:39
  • 7
    I do enjoy the (Gnu) manpages for true: "do nothing, successfully" and false: "do nothing, unsuccessfully." Doesn't that imply that false actually does do something? (Just to be clear, that is a rhetorical question. It is my understanding that false does nothing but exit with a non-zero status.)
    – 8bittree
    Jul 9, 2020 at 21:04

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
  • 3
    : will not work in many cases that expect to exec something. /bin/true will, though.
    – Jan Hudec
    Jul 8, 2020 at 10:20
  • 4
    @JanHudec Correct, because exec is for starting a new process. It may be that for OPs specific purposes, only /bin/true will work; but for others finding this question in the future, it may be that the shell builtin : is more appropriate.
    – gerrit
    Jul 8, 2020 at 11:44
  • 1
    @JanHudec, or just use true instead of /bin/true so if it's launched from a shell, you get the builtin, and from a non-shell the standalone executable can be found in PATH...
    – ilkkachu
    Jul 8, 2020 at 12:48
  • 1
    It's unlikely the script is using exec, as it would not be able to resume after the editor command exits.
    – chepner
    Jul 8, 2020 at 16:46
  • 2
    @ilkkachu: there is posix_spawn (although other than embedded systems you may expect it to be a wrapper combining fork/vfork/clone and execve). Also, still in pedantic mode, the shell exec can do other things other than executing files (it changes the fd on the current process).
    – Ángel
    Jul 8, 2020 at 19:57

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

sleep 0
  • 2
    I didn't suggest /bin/true, but true (without a path).
    – ilkkachu
    Jul 8, 2020 at 12:50
  • 5
    For the record, on my system, which true returns /usr/bin/true, so ikkachu's distinction of whether to supply the path is important.
    – jpaugh
    Jul 8, 2020 at 14:49
  • 3
    @jpaugh, hah! It's indeed in /usr/bin on macOS, why didn't I check it before.
    – ilkkachu
    Jul 8, 2020 at 15:51
  • 1
    There are probably lots of commands one could post that ignore their arguments and return immediately; not every one of them needs their own answer.
    – chepner
    Jul 8, 2020 at 16:45
  • 1
    @jpaugh To add to that record, you may be on an Arch Linux (or one of its derivatives), where /bin is a symlink to /usr/bin. Jul 8, 2020 at 18:14

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.
  1. 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.

  • 1
    Just echo without any arguments should also do (it still outputs the newline, of course)
    – ilkkachu
    Jul 9, 2020 at 9:58
  • I think many of the examples are like "Build 0 houses". Jul 10, 2020 at 16:45
  • @VolkerSiegel Oh, sure, that is true. But isn't that what the OP asked for?
    – user232326
    Jul 11, 2020 at 1:56
  • He wants an executable file, according to the title. Like /bin/true is. (true in an interactive shell does not use the file) All of your examples exist as executable files too: There is even a file /bin/[ - it complains if it does not get the argument ]. Right, there is some redundancy in the examples, but that's not a problem. Jul 11, 2020 at 3:32
  • Reading the examples again, I think the example rm -f '' should be removed. The -f makes it more dangerous than just an rm, You can alias rm to rm -i, making rm interactive, asking you before removing a file. That would result in rm -i -f '', the safety gets canceled by forcing. I do like the examples rm and sh somehow, and there is some academic value in having them. You even describe the problems - I had missed that /bin/sh reads files, also libs. By now, I feel these examples should not be there, even if a reader could learn a lot by understanding them. I'll remove them. Jul 11, 2020 at 4:01


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 $?
$ false
$ echo $?
$ false
$ echo $?
$ echo $?

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"
$ false && echo "failure"
$ true || echo "success"
$ false || echo "failure"

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


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)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .