bug-bash
[Top][All Lists]
Advanced

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

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


From: David Thomas
Subject: Re: edit-and-execute-command is appropriately named, weird
Date: Tue, 31 May 2011 08:44:29 -0700

Oh, I wasn't asking you to do it, I was volunteering to.  I just
wanted to be sure there wasn't some overriding reason it was done the
way it was, and that there wouldn't be too many people relying on the
present behavior.  As it is, I think I'll be taking a swing at it once
my home internet is hooked up (which should be any day now...).

On Sat, May 28, 2011 at 3:42 PM, Chet Ramey <chet.ramey@case.edu> wrote:
> On 5/27/11 6:20 PM, David Thomas wrote:
>> 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.
>
> Quite true: it doesn't strictly apply to read -e or to emacs editing mode
> at all.  However, the specification is well-suited to being implemented
> using `fc', which is also specified by Posix.  It's also never seemed
> important enough to disable that particular command when running
> `read -e'.
>
>> 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.
>
> That's probably true, but not quite how it works.  The contents of the
> edited file are executed directly rather than being placed back into the
> editing buffer and accepted because that's how `fc' does its job.  It
> would take some work to redo the implementation.
>
> It might be an interesting exercise to reimplement that editing function
> as you suggest, and it might even be more closely Posix-conformant, but
> I'm not inclined to do it right now.  There are other, higher-priority
> issues.  Maybe someday.
>
> In the meantime, the function I provided does what you would like at the
> cost of a single extra keystroke.
>
> 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/
>



reply via email to

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