Re: edit-and-execute-command is appropriately named, weird

[David Thomas]

Hi Chet,

Thank you for the response, and the attempt at assistance.

I was unaware of the POSIX specifications relating to editing modes.
After reading the specs, however, I don't think they conflict with
what I propose.  While the description of the [count]v command does
say that it executes the commands in the temporary file, this cannot
be required to apply to line editing in the read builtin when run with
the -e option, as the -e option is not described in the specification
of read at all and so its behavior is up to the developers here to
define.

Note that I am not proposing "edit and keep in buffer" semantics (as
you provided an example of below, and which would clearly conflict
with the standard), but rather "edit and accept" which results in
conformant behavior at the command prompt when the accepted line is
then processed as a shell command.

In the short term, I was able to get the behavior I want by overriding
fc in the script in question, but I still think default behavior is
ugly.

Thanks again for the response, and I'm interested in your further thoughts.

- David


On Thu, May 26, 2011 at 9:09 AM, Chet Ramey <chet.ramey@case.edu> wrote:
> On 5/23/11 1:05 PM, David Thomas wrote:
>> Hi all,
>>
>> In using bash over the years, I've been quite happy to be able to hit
>> ctrl-x ctrl-e to pull up an editor when my input has grown too
>> complicated.
>>
>> When using read -e for input, however, the behavior I find makes a lot
>> less sense: the input line is still opened in an editor, but the
>> result is not processed by read - it is executed by bash.  While a
>> means to escape to the shell can certainly be useful it seems like it
>> should generally be done in a more controlled environment.  It is much
>> harder to reason about my scripts when arbitrary variables might be
>> overwritten just because I asked for input.  In any case I'm not sure
>> it makes sense to conflate this with the "open this line in an editor"
>> command.
>
> That editing command exists because Posix standardizes it for vi editing
> mode. (Posix declined to standardize emacs editing mode at all.)  It was
> useful to expose the same behavior when in emacs mode.
>
> If you want an `edit-in-editor' command that just replaces the readline
> editing buffer with the edited result, you should be able to write a shell
> function to do that and use `bind -x' to make it available on any key
> sequence you want (modulo the current restrictions on bind -x, of course).
>
> Something like this:
>
> edit_in_editor()
> {
>        typeset p
>        local TMPF=/tmp/readline-buffer
>
>        p=$(READLINE_POINT}
>        rm -f $TMPF
>        printf "%s\n" "$READLINE_LINE" > "$TMPF"
>        ${VISUAL:-${EDITOR:-emacs}} $TMPF && READLINE_LINE=$(< $TMPF)
>        rm -f $TMPF
>        READLINE_POINT=0        # or p or ${#READLINE_LINE} or ...
> }
>
> Salt to taste.
>
> Chet
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                 ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/
>