Standard Command That Always Exits with a Failure

1. A return based function would work, and avoids the need to open and close another shell, (as per Tim Kennedy's comment):

   freturn() { return "$1" ; } 
   freturn 56 ; echo $?
   

   Output:

   56
   

2. using exit in a subshell:

   (exit 56)
   

   With shells other than ksh93, that implies forking an extra process so is less efficient than the above.

3. bash/zsh/ksh93 only trick:

   . <( echo return 56 )
   

   (that also implies an extra process (and IPC with a pipe)).

4. zsh's lambda functions:

   (){return 56}
   

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