3

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?

3
  • 1
    Looks like a bug. Commented Jun 29, 2016 at 16:18
  • Could you report this here https://www.gnu.org/software/bash/manual/html_node/Reporting-Bugs.html and see what do they say?
    – Vombat
    Commented Jun 30, 2016 at 6:06
  • @coffeMug: Alright, done. I think I even found the issue, and submitted a patch. I'll update this question once I have received feedback. Commented Jun 30, 2016 at 11:05

1 Answer 1

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.

You must log in to answer this question.

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