On Fri, May 12, 2017 at 8:35 AM, Chet Ramey <chet.ra...@case.edu> wrote: [...] > The command is executed in a separate context, exactly the same as > running fc on a command from the history file (in fact, that's what > happens). It's meant to not affect the contents of the current > command line. That's how Posix specifies it.
Hm, I'm reading: 1. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html#tag_20_117_13_03 "Command Line Editing (vi-mode)" 2. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html#tag_20_117_13_05 "vi Line Editing Command Mode" 3. And http://pubs.opengroup.org/onlinepubs/9699919799/utilities/fc.html I find: (from 2, i.e. command mode) | [number]v | Invoke the vi editor to edit the current command line in a temporary file. When | the editor exits, the commands in the temporary file shall be executed and | placed in the command history. If a number is included, it specifies the | command number in the command history to be edited, rather than the current | command line. (from 1, i.e. vi-mode) | If sh receives a SIGINT signal in command mode (whether generated by typing the | interrupt character or by other means), it shall terminate command line editing | on the current command line, reissue the prompt on the next line of the | terminal, and reset the command history (see fc) so that the most recently | executed command is the previous command (that is, the command that was being | edited when it was interrupted is not re-entered into the history). (from 3, i.e fc) | -e editor | Use the editor named by editor to edit the commands. The editor string is a | utility name, subject to search via the PATH variable (see XBD Environment | Variables). The value in the FCEDIT variable shall be used as a default when -e | is not specified. If FCEDIT is null or unset, ed shall be used as the editor. But other than that, I can't find any reference from POSIX that mandates that the edit line must be restored after running the `v' command. Also, if you run `edit-and-execute-command' when the edit line as a simple command (say ls), it will run ls, and then clear the edit line. Reviewing what other shells do: - ksh93: It won't accept the `v' command while under the secondary prompt - mksh: Same as ksh93 - dash (compiled with libedit support): If you type <echo '> then return, then ESC-v, it will open the editor on an empty file, and... well, it nothing of what it does really makes sense. - zsh's ZLE `edit-command-line': This one works a little different, since it won't execute the command after the editor exits. Rather, it'll just put the result in the edit buffer, and then you have to hit return to execute it. - posh: doesn't seem to support command line editing. - NetBSD's /bin/sh: if you run the `v' command while under the secondary prompt, it will open an editor, but discards what you write after the editor exits and returns back to the secondary prompt state. So there doesn't seem to be consensus here. And I guess that it's more useful if `edit-and-execute-command' behaves the same way for a single line command or a multiline command.
