Re: misbehavior in shell window with ksh

[Stephen Berman]

On Tue, 02 May 2017 12:03:54 +0300 Eli Zaretskii <address@hidden> wrote:

>> From: Stephen Berman <address@hidden>
>> Cc: address@hidden,  address@hidden
>> Date: Mon, 01 May 2017 17:52:31 +0200
>> 
>> > Can you show the backtrace for the invocation of comint-output-filter?
>> 
>> After `M-o' in the recipe I did `M-: (debug-on-entry
>> 'comint-output-filter) RET' (when I tried `M-x debug-on-entry RET' the string
>> "> " was then inserted into the *shell* buffer).  This showed this backtrace:
>> 
>>    Debugger entered--entering a function:
>>    * comint-output-filter(#<process shell> "> ")
>> 
>> I typed `q' then proceeded with `M-0' from the recipe, which produced
>> the same backtrace.  Why isn't the caller of comint-output-filter shown?
>
> What if you step into comint-output-filter with Edebug (as you already
> seem to have a way of doing that), then type 'd' to produce a
> backtrace?  Does that show who called comint-output-filter?

Unfortunately not.  FTR: I instrumented comint-output-filter for Edebug
and started the recipe.  On entering `ksh RET' at the shell prompt,
Edebug took control and I typed `d' and got this backtrace:

  comint-output-filter(#<process shell> "address@hidden:/home/steve> ")

I typed `q' and continued with the recipe, and at `C-x 0' (M-o and M-0
above were typos) Edebug again took over, and `d' produced this
backtrace:

  comint-output-filter(#<process shell> "> ")

> It could be that it is called by the process-filter mechanism, which
> is in C.  But what we want to know is where does the 2nd arg of
> comint-output-filter comes from, and why.

If you can advise me what to try in gdb, I can do that.  I did try
setting a breakpoint at Fprocess_filter but subsequently typing `C-x 0'
did not stop execution (but did result in "> " getting inserted).

Steve Berman