bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bash stays in the secondary prompt (PS2) after completing a command


From: Eduardo Bustamante
Subject: Re: Bash stays in the secondary prompt (PS2) after completing a command with `edit-and-execute-command'
Date: Fri, 12 May 2017 09:44:18 -0500

On Fri, May 12, 2017 at 8:35 AM, Chet Ramey <chet.ramey@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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]