Exit status of fc -e is the wrong way around

Question

I'm trying to edit and recall a previous command with Bash's built-in fc command, but somehow the exit status indicates failure on successful edit, even if that is a no-op. Demo:

$ uname
Linux
$ fc -e vi
:q
uname
Linux
$ echo $?
1
$ # Would have expected 0 here: successful re-invocation

From man bash:

   fc [-e ename] [-lnr] [first] [last]
   fc -s [pat=rep] [cmd]
          [...]
          If  the  first  form  is  used,  the return value is 0 unless an
          invalid option is encountered or first or last  specify  history
          lines  out  of  range.  If the -e option is supplied, the return
          value is the value of the last command executed or failure if an
          error occurs with the temporary file of commands.  [...]

Digging further into it:

$ uname
Linux
$ fc -e true -1  # No-op editor, should succeed.
uname
Linux
$ echo $?
1
$ # Why does this recall, but fail?
$ fc -e false -1 # Editor fails, no command invocation and failure, fine.
$ echo $?
1
$ fc -e rm -1    # This removes the temporary file, should fail, too!?
$ echo $?
0
$ # But actually this is the only branch that causes fc to succeed?!

To me, the exit status of fc is messed up: Successful (or no-op) editing should result in success (or the exit status of the recalled command), and removal of the temporary file should be indicated by failure, not the other way around.

I see this in Bash 4.3.11(1)-release on Ubuntu 14.04.4 LTS, in Bash 4.3.42(1)-release on Ubuntu 16.04 LTS, and in Bash 4.2.46(1)-release on CentOS 7. Is this a bug?

Answer 1

Yes, this is a bug. It was already reported and fixed back in November, 2015: http://lists.gnu.org/archive/html/bug-bash/2015-11/msg00107.html

I didn't notice the fix inside the Git repository because I only looked on master. Apparently, development takes place on devel; the fix currently only is in there. I will update this answer once it made its way into a Bash release.