Re: Bash stays in the secondary prompt (PS2) after completing a command with `edit-and-execute-command'
On Fri, May 12, 2017 at 10:29 AM, Chet Ramey wrote: [...] > Because it doesn't say the equivalent of "execute the current command > line" (as newline does), it's a standard editing command that continues > with the current line buffer. The only thing that gets executed are the > contents of the temp file. I'm not yet convinced. From what I can tell from the standard, there are two basic concepts: - the edit line (rl_line_buffer i guess) - the current command line >From my reading of PS2's description, the current command line is not necessarily a single line. i.e. PS2 will show if the current command line is incomplete. So, the current command line is whatever the shell has parsed up until now, even if that spans multiple lines. Also, the `v' command indicates that it operates on the *current command line* (which if my reading is correct, includes the current edit line plus anything that the parser has accumulated). Also, there's another paragraph that mentions that any command that modifies the current line (which I assume refers to the current command line), will cause the edit line to be replaced by the current line. I won't pursue this matter any further though. I think of this of a minor inconvenience and it's not big of a deal. I usually just run `edit-and-execute-command' on an empty line anyways :) http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html | PS2 | Each time the user enters a prior to completing a command line in an | interactive shell, the value of this variable shall be subjected to parameter | expansion and written to standard error. The default value is "> ". This volume | of POSIX.1-2008 specifies the effects of the variable only for systems | supporting the User Portability Utilities option. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html#tag_20_117_13_05 | [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. | If the current line is not the edit line, any command that modifies the current | line shall cause the content of the current line to replace the content of the | edit line, and the current line shall become the edit line
How to call a bash-func from readline? && how to call rl-func from bash?
How might one programatically call a bash function from readline, and pass information from that function back into readline? Also, is it possible to define a readline function, or only use predefined ones? Ex: On a keypress, I would like to be able to redefine that key in ".bashrc" and have it call a bash-function that could map the key to itself or a sequence of keys based on the shell's current state. How would someone do that? Thanks! -linda
Re: How to call a bash-func from readline? && how to call rl-func from bash?
On Sat, May 13, 2017 at 5:14 PM, L A Walsh wrote:
> How might one programatically call a bash
> function from readline, and pass information from that function
> back into readline?
For that, you'd use a combination of `bind -x', READLINE_LINE and
READLINE_POINT. For example, if you wanted a key sequence to uppercase
the whole rl_line_buffer (READLINE_LINE), then you'd:
dualbus@debian:~$ upcase(){ READLINE_LINE=${READLINE_LINE^^}; }
dualbus@debian:~$ bind -x '"\C-x\C-u": upcase'
dualbus@debian:~$ foo bar baz
dualbus@debian:~$ FOO BAR BAZ
So READLINE_LINE is GNU Readline's `char * rl_line_buffer' <> and READLINE_POINT is `int rl_point' <>.
You can do a lot of things with these two alone. I guess you can
emulate most of Readline's functions with these three alone.
> Also, is it possible to define a readline
> function, or only use predefined ones?
I have been wondering about that same thing today. i.e. a builtin that
allows you to call readline functions from shell functions, e.g. to
avoid re-implementing things like `tilde-expand'.
> Ex: On a keypress, I would like to be able to
> redefine that key in ".bashrc" and have it call a
> bash-function that could map the key to itself or
> a sequence of keys based on the shell's current state.
I don't understand this part.
Re: How to call a bash-func from readline? && how to call rl-func from bash?
Eduardo Bustamante wrote: For that, you'd use a combination of `bind -x', READLINE_LINE and READLINE_POINT. For example, if you wanted a key sequence to uppercase the whole rl_line_buffer (READLINE_LINE), then you'd: You can do a lot of things with these two alone. I guess you can emulate most of Readline's functions with these three alone. Looks convenient, but Also, is it possible to define a readline function, or only use predefined ones? I have been wondering about that same thing today. i.e. a builtin that allows you to call readline functions from shell functions, e.g. to avoid re-implementing things like `tilde-expand'. Ex: On a keypress, I would like to be able to redefine that key in ".bashrc" and have it call a bash-function that could map the key to itself or a sequence of keys based on the shell's current state. I don't understand this part. --- So a key is pressed when there is no visible input on the current display line (which isn't the same as position 0 in the current input line), now say that key is the complete key. Say I want to either insert the the complete key OR call the complete function based on where the input position is on the physical (screen) line and what came before it. (shell-state, current input, and current input column among other things). bash used to not do complete on an empty physical line, but it was pointed out that one could be on an empty physical line, and still want complete, so one no longer has the ability to paste into bash, cleanly. It eats input chars. I prefer to be able to paste than to be able to press complete when the physical line is in col 0 or only whitespace preceeds the complete key. Seemed like it might be a way to get this done if there was sufficient flexibility between the rl & bash layers.
