53

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?

Improve this question
8
  • 1
    Can't you just do unset EDITOR or EDITOR="" instead? Commented Jul 8, 2020 at 17:27
  • 4
    @terdon: well if you want to open ed or some other silly default. Commented 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. Commented 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. Commented Jul 8, 2020 at 19:29
  • Ah, ouch. Yeah, that's no good. Commented Jul 8, 2020 at 20:46

6 Answers 6

Reset to default
127

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
18
  • 7
    That must be /bin/true. Otherwise it would usually be a shell builtin which is not really "a standard dummy executable file". Commented 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. Commented 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. Commented 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... Commented 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.) Commented Jul 9, 2020 at 21:04
28

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
12
  • 3
    : will not work in many cases that expect to exec something. /bin/true will, though. Commented 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. Commented 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... Commented 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. Commented 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). Commented Jul 8, 2020 at 19:57
5

@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
6
  • 2
    I didn't suggest /bin/true, but true (without a path). Commented 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. Commented Jul 8, 2020 at 14:49
  • 3
    @jpaugh, hah! It's indeed in /usr/bin on macOS, why didn't I check it before. Commented 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. Commented 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. Commented Jul 8, 2020 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
6
  • 1
    Just echo without any arguments should also do (it still outputs the newline, of course) Commented Jul 9, 2020 at 9:58
  • I think many of the examples are like "Build 0 houses". Commented Jul 10, 2020 at 16:45
  • @VolkerSiegel Oh, sure, that is true. But isn't that what the OP asked for? Commented 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. Commented 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. Commented Jul 11, 2020 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
1
  • Note that they still (on GN_U systems) parse arguments and react to e.g. --help. The safe way would be to use true -- ... if arguments can be used. Commented Jul 5 at 21:47
0

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)
Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.