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?

  • 1
    Looks like a bug. – Satō Katsura Jun 29 '16 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? – coffeMug Jun 30 '16 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. – Ingo Karkat Jun 30 '16 at 11:05
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.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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