44

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 at 17:27
  • 4
    @terdon: well if you want to open ed or some other silly default. – Joshua Jul 8 at 18:24
  • 1
    @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 at 19:14
  • 7
    @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 at 19:29
  • Ah, ouch. Yeah, that's no good. – terdon Jul 8 at 20:46
117

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

| improve this answer | |
  • 6
    That must be /bin/true. Otherwise it would usually be a shell builtin which is not really "a standard dummy executable file". – Hauke Laging Jul 7 at 20:51
  • 10
    @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 at 20:54
  • 20
    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 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... – Lee Daniel Crocker Jul 8 at 16:39
  • 5
    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 at 21:04
26

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
| improve this answer | |
  • 3
    : will not work in many cases that expect to exec something. /bin/true will, though. – Jan Hudec Jul 8 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 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 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 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 at 19:57
4

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

sleep 0
| improve this answer | |
  • 2
    I didn't suggest /bin/true, but true (without a path). – ilkkachu Jul 8 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 at 14:49
  • 3
    @jpaugh, hah! It's indeed in /usr/bin on macOS, why didn't I check it before. – ilkkachu Jul 8 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 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. – rexkogitans Jul 8 at 18:14
3

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.

| improve this answer | |
  • 1
    Just echo without any arguments should also do (it still outputs the newline, of course) – ilkkachu Jul 9 at 9:58
  • I think many of the examples are like "Build 0 houses". – Volker Siegel Jul 10 at 16:45
  • @VolkerSiegel Oh, sure, that is true. But isn't that what the OP asked for? – Isaac Jul 11 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. – Volker Siegel Jul 11 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. – Volker Siegel Jul 11 at 4:01
0

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

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.