I've been using bash's edit-and-execute-command
function:
edit-and-execute-command (C-x C-e)
Invoke an editor on the current command line, and execute the result as shell commands. Bash attempts to invoke
$VISUAL
,$EDITOR
, andemacs
as the editor, in that order.
https://www.gnu.org/software/bash/manual/html_node/Miscellaneous-Commands.html
I've noticed that if I invoke an editor,
use Ctrl-Z to put it into the background,
and then use fg
to put it back into the foreground,
the shell no longer executes the temporary file.
This is handy if I want to abort the command,
but I found the behavior a little surprising the first time it happened.
My questions:
-
Why does this happen?
I know from the source code
thatedit_and_execute_command
eventually callsfc
,
but it's not immediately clear to me
why sending SIGTSTP prevents bash from executing the temporary file. -
If I had accidentally hit Ctrl-Z
and still wanted to execute the script in the temporary file still open by the editor,
what would be the best way of doing that?
Best Answer
You could try using and editor wrapper which would save the last command somewhere, and a readline binding which could bring it back. Example which saves the last buffer to
~/.last_fcedit
and bindsEsc-/
(Alt-/
) to replace the command line with it:Then
I'm not able to find a convincing rationale for it, but it's the same with plain
fc
(and related keybindings) on all the shell implementations I could check.My idea is that it has do with the shell not being able to recursively background or foreground itself, but only its child jobs (process groups). The same thing you could notice with:
or
Unlike in
bash
, the first example will actually "work" inksh93
orzsh
; but the second will be unkillable inksh93
orzsh
;-)