misbehavior in shell window with ksh

misbehavior in shell window with ksh

[Mike Kupfer]

From emacs -Q, using Emacs master 6fa9cc05, if I do the following steps

  M-x shell RET
  ksh RET
  C-x o RET
  C-x 0 RET
  
a ">" appears after the shell prompt in the *shell* buffer:

  alto$ ksh
  alto$ >

If I then press RET, I get

  alto$ ksh
  alto$ > 
  : not found [No such file or directory]
  alto$

I've reproduced this behavior a couple different recent versions of
Emacs, including 25.1.91 and 25.2-rc2.  And I've reproduced it on both
Solaris 11 and Debian 8.

Using the version of Emacs that is packaged with Debian 8 (24.4), I
don't see any problems.

TERM is set to dumb; changing it to emacs doesn't help.

Can anyone else reproduce this behavior?

thanks,
mike

Re: misbehavior in shell window with ksh

[Eli Zaretskii]

> From: Mike Kupfer <mkupfer@alum.berkeley.edu>
> Date: Sun, 30 Apr 2017 16:12:26 -0700
> 
> >From emacs -Q, using Emacs master 6fa9cc05, if I do the following steps
> 
>   M-x shell RET
>   ksh RET
>   C-x o RET
>   C-x 0 RET
>   
> a ">" appears after the shell prompt in the *shell* buffer:
> 
>   alto$ ksh
>   alto$ >
> 
> If I then press RET, I get
> 
>   alto$ ksh
>   alto$ > 
>   : not found [No such file or directory]
>   alto$

I cannot reproduce this, neither with Emacs 25.2 nor with the latest
master branch.

Does this happen in a -nw session as well, or only in GUI frames?
Could this be related to some of your shell customizations?

Re: misbehavior in shell window with ksh

[Stephen Berman]

On Mon, 01 May 2017 09:49:41 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Mike Kupfer <mkupfer@alum.berkeley.edu>
>> Date: Sun, 30 Apr 2017 16:12:26 -0700
>> 
>> >From emacs -Q, using Emacs master 6fa9cc05, if I do the following steps
>> 
>>   M-x shell RET
>>   ksh RET
>>   C-x o RET
>>   C-x 0 RET
>>   
>> a ">" appears after the shell prompt in the *shell* buffer:
>> 
>>   alto$ ksh
>>   alto$ >
>> 
>> If I then press RET, I get
>> 
>>   alto$ ksh
>>   alto$ > 
>>   : not found [No such file or directory]
>>   alto$
>
> I cannot reproduce this, neither with Emacs 25.2 nor with the latest
> master branch.
>
> Does this happen in a -nw session as well, or only in GUI frames?

I can reproduce this with both -Q and -Q -nw in latest master (details
below).  I also noticed that (any?) non-self-insertion keyboard events
reproduce the behavior, e.g. `t TAB' adds anoth `>' at the prompt, and
then `C-g' to kill the *Completions* buffer adds another `>', and then
RET returns: 
^L^Lt: not found [No such file or directory]
(Then ^L are really control characters.)

In GNU Emacs 26.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.20.10)
 of 2017-05-01 built on rosalinde
Repository revision: 6c9ec085e2b36e801c967bc0635671dc1880cb80
Repository revision: edc63bf94f3cd3f52fab86fe7b92a3ec6a19de40
Windowing system distributor 'The X.Org Foundation', version 11.0.11803000
System Description:	openSUSE Leap 42.2

Configured using:
 'configure --with-xwidgets 'CFLAGS=-Og -g3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GSETTINGS NOTIFY
GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS
GTK3 X11 XWIDGETS

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix

Re: misbehavior in shell window with ksh

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: Mike Kupfer <mkupfer@alum.berkeley.edu>,  emacs-devel@gnu.org
> Date: Mon, 01 May 2017 12:59:21 +0200
> 
> > I cannot reproduce this, neither with Emacs 25.2 nor with the latest
> > master branch.
> >
> > Does this happen in a -nw session as well, or only in GUI frames?
> 
> I can reproduce this with both -Q and -Q -nw in latest master (details
> below).  I also noticed that (any?) non-self-insertion keyboard events
> reproduce the behavior, e.g. `t TAB' adds anoth `>' at the prompt, and
> then `C-g' to kill the *Completions* buffer adds another `>', and then
> RET returns: 
> ^L^Lt: not found [No such file or directory]
> (Then ^L are really control characters.)

Thanks, can you debug this to see what's causing the problem?

Re: misbehavior in shell window with ksh

[Stephen Berman]

On Mon, 01 May 2017 14:31:11 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: Mike Kupfer <mkupfer@alum.berkeley.edu>,  emacs-devel@gnu.org
>> Date: Mon, 01 May 2017 12:59:21 +0200
>> 
>> > I cannot reproduce this, neither with Emacs 25.2 nor with the latest
>> > master branch.
>> >
>> > Does this happen in a -nw session as well, or only in GUI frames?
>> 
>> I can reproduce this with both -Q and -Q -nw in latest master (details
>> below).  I also noticed that (any?) non-self-insertion keyboard events
>> reproduce the behavior, e.g. `t TAB' adds anoth `>' at the prompt, and
>> then `C-g' to kill the *Completions* buffer adds another `>', and then
>> RET returns: 
>> ^L^Lt: not found [No such file or directory]
>> (Then ^L are really control characters.)
>
> Thanks, can you debug this to see what's causing the problem?

By edebugging shell.el and comint.el I see that after typing `C-x 0' in
the recipe, the function comint-output-filter is invoked with the value
#<process shell> for its argument `proc' and the value "> " for its
argument `string', and the latter value is what is inserted into the
*shell* buffer.  I have failed to find out how that argument gets that
value or even how comint-output-filter gets invoked.  If anyone has any
advice for how to proceed, I can try it.

Steve Berman

Re: misbehavior in shell window with ksh

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: mkupfer@alum.berkeley.edu,  emacs-devel@gnu.org
> Date: Mon, 01 May 2017 16:41:06 +0200
> 
> By edebugging shell.el and comint.el I see that after typing `C-x 0' in
> the recipe, the function comint-output-filter is invoked with the value
> #<process shell> for its argument `proc' and the value "> " for its
> argument `string', and the latter value is what is inserted into the
> *shell* buffer.  I have failed to find out how that argument gets that
> value or even how comint-output-filter gets invoked.  If anyone has any
> advice for how to proceed, I can try it.

Thanks.

Can you show the backtrace for the invocation of comint-output-filter?

Re: misbehavior in shell window with ksh

[Stephen Berman]

On Mon, 01 May 2017 18:09:36 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: mkupfer@alum.berkeley.edu,  emacs-devel@gnu.org
>> Date: Mon, 01 May 2017 16:41:06 +0200
>> 
>> By edebugging shell.el and comint.el I see that after typing `C-x 0' in
>> the recipe, the function comint-output-filter is invoked with the value
>> #<process shell> for its argument `proc' and the value "> " for its
>> argument `string', and the latter value is what is inserted into the
>> *shell* buffer.  I have failed to find out how that argument gets that
>> value or even how comint-output-filter gets invoked.  If anyone has any
>> advice for how to proceed, I can try it.
>
> Thanks.
>
> 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?

On Mon, 01 May 2017 08:29:13 -0700 Mike Kupfer <mkupfer@alum.berkeley.edu> wrote:

> Stephen Berman wrote:
>
>> By edebugging shell.el and comint.el I see that after typing `C-x 0' in
>> the recipe, the function comint-output-filter is invoked with the value
>> #<process shell> for its argument `proc' and the value "> " for its
>> argument `string', and the latter value is what is inserted into the
>> *shell* buffer.  I have failed to find out how that argument gets that
>> value or even how comint-output-filter gets invoked.  If anyone has any
>> advice for how to proceed, I can try it.
>
> The "> " is coming from the PS2 environment variable (secondary prompt
> string).  If I change PS2 to "foo> ", then "foo> " is what gets
> inserted.  (This probably isn't what you were asking for, but I thought
> I'd note it.)

FTR the same thing happens here.

> Also, I looked into Eli's question
>
>> Could this be related to some of your shell customizations?
>
> Having EDITOR set to emacs (or emacsclient) seems to be required for me
> to reproduce the problem.
>
>   $ export EDITOR=emacs
>   $ emacs -Q -nw
>   => problem reproduces
>
>   $ emacs -Q -nw (w/o EDITOR set)
>   M-x shell RET
>   export EDITOR=emacs RET
>   ksh RET
>   => problem reproduces
>
>   $ export EDITOR=emacs
>   $ emacs -Q -nw
>   M-x shell RET
>   unset EDITOR RET
>   ksh RET
>   => problem does not reproduce

Here, EDITOR had not been set when I tested previously, and it makes no
difference if I set it and execute the recipe, also after unsetting it;
in all cases I get the problematic behavior.

Steve Berman

Re: misbehavior in shell window with ksh

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: mkupfer@alum.berkeley.edu,  emacs-devel@gnu.org
> 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?

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.

Thanks.

Re: misbehavior in shell window with ksh

[Stephen Berman]

On Tue, 02 May 2017 12:03:54 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: mkupfer@alum.berkeley.edu,  emacs-devel@gnu.org
>> 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> "steve@rosalinde:/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

Re: misbehavior in shell window with ksh

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: mkupfer@alum.berkeley.edu,  emacs-devel@gnu.org
> Date: Tue, 02 May 2017 14:35:44 +0200
> 
> > 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> "steve@rosalinde:/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.

Get Emacs to stop in comint-output-filter using Edebug, then attach
GDB, make sure src/.gdbinit is being source'd by GDB, and type

  (gdb) bt

This should producve both C-level backtrace and Lisp-level backtrace.

Re: misbehavior in shell window with ksh

[Stephen Berman]

On Tue, 02 May 2017 19:32:31 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: mkupfer@alum.berkeley.edu,  emacs-devel@gnu.org
>> Date: Tue, 02 May 2017 14:35:44 +0200
>> 
>> > 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> "steve@rosalinde:/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.
>
> Get Emacs to stop in comint-output-filter using Edebug, then attach
> GDB, make sure src/.gdbinit is being source'd by GDB, and type
>
>   (gdb) bt
>
> This should producve both C-level backtrace and Lisp-level backtrace.

Here they are:

#0  0x00007fd0f3733bd9 in pselect () at /lib64/libc.so.6
#1  0x00000000005ab745 in really_call_select (arg=arg@entry=0x7ffcbb813cc0)
    at /home/steve/git/emacs-master/src/thread.c:566
#2  0x000000000053d8c6 in flush_stack_call_func (func=func@entry=0x5ab6fa <really_call_select>, arg=arg@entry=0x7ffcbb813cc0)
    at /home/steve/git/emacs-master/src/alloc.c:5153
#3  0x00000000005abc0b in thread_select (func=<optimized out>, max_fds=max_fds@entry=19, rfds=rfds@entry=0x7ffcbb8141e0, wfds=<optimized out>, efds=efds@entry=0x0, timeout=timeout@entry=0x7ffcbb814430, sigmask=sigmask@entry=0x0)
    at /home/steve/git/emacs-master/src/thread.c:589
#4  0x00000000005c6391 in xg_select (fds_lim=19, rfds=rfds@entry=0x7ffcbb8144d0, wfds=0x7ffcbb814450, efds=efds@entry=0x0, timeout=timeout@entry=0x7ffcbb814430, sigmask=sigmask@entry=0x0) at /home/steve/git/emacs-master/src/xgselect.c:117
#5  0x00000000005903da in wait_reading_process_output (time_limit=time_limit@entry=67, nsecs=nsecs@entry=0, read_kbd=<optimized out>, do_display=do_display@entry=true, wait_for_cell=wait_for_cell@entry=0, wait_proc=wait_proc@entry=0x0, just_wait_proc=just_wait_proc@entry=0) at /home/steve/git/emacs-master/src/process.c:5355
#6  0x0000000000421953 in sit_for (timeout=timeout@entry=270, reading=reading@entry=true, display_option=display_option@entry=1)
    at /home/steve/git/emacs-master/src/dispnew.c:5763
#7  0x00000000004f313e in read_char (commandflag=1, map=map@entry=55836707, prev_event=0, used_mouse_menu=used_mouse_menu@entry=0x7ffcbb8148eb, end_time=end_time@entry=0x0) at /home/steve/git/emacs-master/src/keyboard.c:2722
#8  0x00000000004f4252 in read_key_sequence (keybuf=keybuf@entry=0x7ffcbb8149a0, bufsize=bufsize@entry=30, prompt=prompt@entry=0, dont_downcase_last=dont_downcase_last@entry=false, can_return_switch_frame=can_return_switch_frame@entry=true, fix_current_buffer=fix_current_buffer@entry=true, prevent_redisplay=prevent_redisplay@entry=false)
    at /home/steve/git/emacs-master/src/keyboard.c:9122
#9  0x00000000004f57aa in command_loop_1 ()
---Type <return> to continue, or q <return> to quit---
    at /home/steve/git/emacs-master/src/keyboard.c:1370
#10 0x00000000005533cd in internal_condition_case (bfun=bfun@entry=0x4f54cf <command_loop_1>, handlers=handlers@entry=19968, hfun=hfun@entry=0x4eca3d <cmd_error>)
    at /home/steve/git/emacs-master/src/eval.c:1324
#11 0x00000000004e840f in command_loop_2 (ignore=ignore@entry=0)
    at /home/steve/git/emacs-master/src/keyboard.c:1112
#12 0x0000000000553347 in internal_catch (tag=tag@entry=20640, func=func@entry=0x4e83f7 <command_loop_2>, arg=arg@entry=0)
    at /home/steve/git/emacs-master/src/eval.c:1091
#13 0x00000000004e83e7 in command_loop ()
    at /home/steve/git/emacs-master/src/keyboard.c:1083
#14 0x00000000004ec6c1 in recursive_edit_1 ()
    at /home/steve/git/emacs-master/src/keyboard.c:697
#15 0x00000000004ec98a in Frecursive_edit ()
    at /home/steve/git/emacs-master/src/keyboard.c:768
#16 0x00000000005554bb in funcall_subr (subr=0x843120 <Srecursive_edit>, numargs=numargs@entry=0, args=args@entry=0x7ffcbb814c58)
    at /home/steve/git/emacs-master/src/eval.c:2815
#17 0x000000000055497a in Ffuncall (nargs=nargs@entry=1, args=args@entry=0x7ffcbb814c50) at /home/steve/git/emacs-master/src/eval.c:2742
#18 0x0000000000585ea3 in exec_byte_code (bytestr=<optimized out>, vector=47927725, maxdepth=<optimized out>, args_template=args_template@entry=1030, nargs=nargs@entry=1, args=<optimized out>, args@entry=0x7ffcbb814f78)
    at /home/steve/git/emacs-master/src/bytecode.c:641
#19 0x00000000005545e4 in funcall_lambda (fun=47928061, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7ffcbb814f78) at /home/steve/git/emacs-master/src/eval.c:2942
#20 0x00000000005549a6 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7ffcbb814f70) at /home/steve/git/emacs-master/src/eval.c:2744
#21 0x0000000000585ea3 in exec_byte_code (bytestr=<optimized out>, vector=47926757, m---Type <return> to continue, or q <return> to quit---
axdepth=<optimized out>, args_template=args_template@entry=3086, nargs=nargs@entry=3, args=<optimized out>, args@entry=0x7ffcbb815338)
    at /home/steve/git/emacs-master/src/bytecode.c:641
#22 0x00000000005545e4 in funcall_lambda (fun=47927453, nargs=nargs@entry=3, arg_vector=arg_vector@entry=0x7ffcbb815338) at /home/steve/git/emacs-master/src/eval.c:2942
#23 0x00000000005549a6 in Ffuncall (nargs=nargs@entry=4, args=args@entry=0x7ffcbb815330) at /home/steve/git/emacs-master/src/eval.c:2744
#24 0x0000000000585ea3 in exec_byte_code (bytestr=<optimized out>, vector=18637573, maxdepth=<optimized out>, args_template=args_template@entry=3086, nargs=nargs@entry=3, args=<optimized out>, args@entry=0x7ffcbb815508)
    at /home/steve/git/emacs-master/src/bytecode.c:641
#25 0x00000000005545e4 in funcall_lambda (fun=47926149, nargs=nargs@entry=3, arg_vector=arg_vector@entry=0x7ffcbb815508) at /home/steve/git/emacs-master/src/eval.c:2942
#26 0x00000000005549a6 in Ffuncall (nargs=nargs@entry=4, args=args@entry=0x7ffcbb815500) at /home/steve/git/emacs-master/src/eval.c:2744
#27 0x0000000000585ea3 in exec_byte_code (bytestr=<optimized out>, vector=47925941, maxdepth=<optimized out>, args_template=args_template@entry=3086, nargs=nargs@entry=3, args=<optimized out>, args@entry=0x7ffcbb815738)
    at /home/steve/git/emacs-master/src/bytecode.c:641
#28 0x00000000005545e4 in funcall_lambda (fun=47926101, nargs=nargs@entry=3, arg_vector=arg_vector@entry=0x7ffcbb815738) at /home/steve/git/emacs-master/src/eval.c:2942
#29 0x00000000005549a6 in Ffuncall (nargs=nargs@entry=4, args=args@entry=0x7ffcbb815730) at /home/steve/git/emacs-master/src/eval.c:2744
#30 0x0000000000585ea3 in exec_byte_code (bytestr=<optimized out>, vector=47925357, maxdepth=<optimized out>, args_template=args_template@entry=1030, nargs=nargs@entry=1, args=<optimized out>, args@entry=0x7ffcbb8158b0)
    at /home/steve/git/emacs-master/src/bytecode.c:641
#31 0x00000000005545e4 in funcall_lambda (fun=fun@entry=47925437, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7ffcbb8158b0)
---Type <return> to continue, or q <return> to quit---
    at /home/steve/git/emacs-master/src/eval.c:2942
#32 0x0000000000553cad in apply_lambda (fun=fun@entry=47925437, args=<optimized out>, count=count@entry=32) at /home/steve/git/emacs-master/src/eval.c:2879
#33 0x0000000000554290 in eval_sub (form=form@entry=52890883)
    at /home/steve/git/emacs-master/src/eval.c:2263
#34 0x0000000000553c6c in apply_lambda (fun=fun@entry=47925621, args=<optimized out>, count=count@entry=31) at /home/steve/git/emacs-master/src/eval.c:2874
#35 0x0000000000554290 in eval_sub (form=<optimized out>)
    at /home/steve/git/emacs-master/src/eval.c:2263
#36 0x0000000000554469 in Fprogn (body=53182579)
    at /home/steve/git/emacs-master/src/eval.c:449
#37 0x00000000005547c2 in funcall_lambda (fun=50274099, nargs=nargs@entry=0, arg_vector=arg_vector@entry=0x7ffcbb815c38) at /home/steve/git/emacs-master/src/eval.c:3013
#38 0x0000000000554a04 in Ffuncall (nargs=nargs@entry=1, args=args@entry=0x7ffcbb815c30) at /home/steve/git/emacs-master/src/eval.c:2756
#39 0x0000000000585ea3 in exec_byte_code (bytestr=<optimized out>, vector=47981685, maxdepth=<optimized out>, args_template=args_template@entry=3086, nargs=nargs@entry=3, args=<optimized out>, args@entry=0x7ffcbb815eb8)
    at /home/steve/git/emacs-master/src/bytecode.c:641
#40 0x00000000005545e4 in funcall_lambda (fun=47982005, nargs=nargs@entry=3, arg_vector=arg_vector@entry=0x7ffcbb815eb8) at /home/steve/git/emacs-master/src/eval.c:2942
#41 0x00000000005549a6 in Ffuncall (nargs=nargs@entry=4, args=args@entry=0x7ffcbb815eb0) at /home/steve/git/emacs-master/src/eval.c:2744
#42 0x0000000000585ea3 in exec_byte_code (bytestr=<optimized out>, vector=47981685, maxdepth=<optimized out>, args_template=args_template@entry=3086, nargs=nargs@entry=3, args=<optimized out>, args@entry=0x7ffcbb8160c0)
    at /home/steve/git/emacs-master/src/bytecode.c:641
#43 0x00000000005545e4 in funcall_lambda (fun=fun@entry=47982005, nargs=nargs@entry=3, arg_vector=arg_vector@entry=0x7ffcbb8160c0)
---Type <return> to continue, or q <return> to quit---
    at /home/steve/git/emacs-master/src/eval.c:2942
#44 0x0000000000553cad in apply_lambda (fun=fun@entry=47982005, args=<optimized out>, count=count@entry=9) at /home/steve/git/emacs-master/src/eval.c:2879
#45 0x0000000000554290 in eval_sub (form=<optimized out>)
    at /home/steve/git/emacs-master/src/eval.c:2263
#46 0x0000000000554469 in Fprogn (body=53182403)
    at /home/steve/git/emacs-master/src/eval.c:449
#47 0x00000000005547c2 in funcall_lambda (fun=53178035, nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x7ffcbb8162e8) at /home/steve/git/emacs-master/src/eval.c:3013
#48 0x0000000000554a04 in Ffuncall (nargs=nargs@entry=3, args=args@entry=0x7ffcbb8162e0) at /home/steve/git/emacs-master/src/eval.c:2756
#49 0x0000000000555f85 in Fapply (nargs=nargs@entry=2, args=args@entry=0x7ffcbb816380) at /home/steve/git/emacs-master/src/eval.c:2373
#50 0x0000000000555feb in apply1 (fn=4150696, arg=<optimized out>)
    at /home/steve/git/emacs-master/src/eval.c:2589
#51 0x0000000000589297 in read_process_output_call (fun_and_args=fun_and_args@entry=50273987) at /home/steve/git/emacs-master/src/process.c:5771
#52 0x0000000000553443 in internal_condition_case_1 (bfun=bfun@entry=0x589286 <read_process_output_call>, arg=50273987, handlers=handlers@entry=19968, hfun=hfun@entry=0x589218 <read_process_output_error_handler>)
    at /home/steve/git/emacs-master/src/eval.c:1348
#53 0x0000000000588e2f in read_and_dispose_of_process_output (p=p@entry=0x1365d60, chars=chars@entry=0x7ffcbb816460 "> ", nbytes=nbytes@entry=2, coding=coding@entry=0x105c330) at /home/steve/git/emacs-master/src/process.c:5979
#54 0x0000000000589095 in read_process_output (proc=proc@entry=20340069, channel=channel@entry=18) at /home/steve/git/emacs-master/src/process.c:5890
#55 0x0000000000590a0a in wait_reading_process_output (time_limit=time_limit@entry=30, nsecs=nsecs@entry=0, read_kbd=<optimized out>, do_display=do_display@entry=true, wait_for_cell=wait_for_cell@entry=0, wait_proc=wait_proc@entry=0x0, just_wait_proc=just---Type <return> to continue, or q <return> to quit---
_wait_proc@entry=0) at /home/steve/git/emacs-master/src/process.c:5589
#56 0x0000000000421953 in sit_for (timeout=timeout@entry=122, reading=reading@entry=true, display_option=display_option@entry=1)
    at /home/steve/git/emacs-master/src/dispnew.c:5763
#57 0x00000000004f313e in read_char (commandflag=1, map=map@entry=13473155, prev_event=0, used_mouse_menu=used_mouse_menu@entry=0x7ffcbb817b2b, end_time=end_time@entry=0x0) at /home/steve/git/emacs-master/src/keyboard.c:2722
#58 0x00000000004f4252 in read_key_sequence (keybuf=keybuf@entry=0x7ffcbb817be0, bufsize=bufsize@entry=30, prompt=prompt@entry=0, dont_downcase_last=dont_downcase_last@entry=false, can_return_switch_frame=can_return_switch_frame@entry=true, fix_current_buffer=fix_current_buffer@entry=true, prevent_redisplay=prevent_redisplay@entry=false)
    at /home/steve/git/emacs-master/src/keyboard.c:9122
#59 0x00000000004f57aa in command_loop_1 ()
    at /home/steve/git/emacs-master/src/keyboard.c:1370
#60 0x00000000005533cd in internal_condition_case (bfun=bfun@entry=0x4f54cf <command_loop_1>, handlers=handlers@entry=19968, hfun=hfun@entry=0x4eca3d <cmd_error>)
    at /home/steve/git/emacs-master/src/eval.c:1324
#61 0x00000000004e840f in command_loop_2 (ignore=ignore@entry=0)
    at /home/steve/git/emacs-master/src/keyboard.c:1112
#62 0x0000000000553347 in internal_catch (tag=tag@entry=48192, func=func@entry=0x4e83f7 <command_loop_2>, arg=arg@entry=0)
    at /home/steve/git/emacs-master/src/eval.c:1091
#63 0x00000000004e83b5 in command_loop ()
    at /home/steve/git/emacs-master/src/keyboard.c:1091
#64 0x00000000004ec6c1 in recursive_edit_1 ()
    at /home/steve/git/emacs-master/src/keyboard.c:697
#65 0x00000000004ec98a in Frecursive_edit ()
    at /home/steve/git/emacs-master/src/keyboard.c:768
#66 0x00000000004e7fc9 in main (argc=2, argv=0x7ffcbb817f28)
---Type <return> to continue, or q <return> to quit---
    at /home/steve/git/emacs-master/src/emacs.c:1687

Lisp Backtrace:
"recursive-edit" (0xbb814c58)
"edebug--recursive-edit" (0xbb814f78)
"edebug--display-1" (0xbb815338)
"edebug--display" (0xbb815508)
"edebug-debugger" (0xbb815738)
"edebug-before" (0xbb8158b0)
"edebug-after" (0xbb815af8)
0x2ff1f40 Lisp type 3
"edebug-enter" (0xbb815eb8)
"edebug-enter" (0xbb8160c0)
"comint-output-filter" (0xbb8162e8)

Re: misbehavior in shell window with ksh

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: mkupfer@alum.berkeley.edu,  emacs-devel@gnu.org
> Date: Tue, 02 May 2017 18:55:01 +0200
> 
> #52 0x0000000000553443 in internal_condition_case_1 (bfun=bfun@entry=0x589286 <read_process_output_call>, arg=50273987, handlers=handlers@entry=19968, hfun=hfun@entry=0x589218 <read_process_output_error_handler>)
>     at /home/steve/git/emacs-master/src/eval.c:1348
> #53 0x0000000000588e2f in read_and_dispose_of_process_output (p=p@entry=0x1365d60, chars=chars@entry=0x7ffcbb816460 "> ", nbytes=nbytes@entry=2, coding=coding@entry=0x105c330) at /home/steve/git/emacs-master/src/process.c:5979
> #54 0x0000000000589095 in read_process_output (proc=proc@entry=20340069, channel=channel@entry=18) at /home/steve/git/emacs-master/src/process.c:5890
> #55 0x0000000000590a0a in wait_reading_process_output (time_limit=time_limit@entry=30, nsecs=nsecs@entry=0, read_kbd=<optimized out>, do_display=do_display@entry=true, wait_for_cell=wait_for_cell@entry=0, wait_proc=wait_proc@entry=0x0, just_wait_proc=just---Type <return> to continue, or q <return> to quit---
> _wait_proc@entry=0) at /home/steve/git/emacs-master/src/process.c:5589
> #56 0x0000000000421953 in sit_for (timeout=timeout@entry=122, reading=reading@entry=true, display_option=display_option@entry=1)
>     at /home/steve/git/emacs-master/src/dispnew.c:5763
> #57 0x00000000004f313e in read_char (commandflag=1, map=map@entry=13473155, prev_event=0, used_mouse_menu=used_mouse_menu@entry=0x7ffcbb817b2b, end_time=end_time@entry=0x0) at /home/steve/git/emacs-master/src/keyboard.c:2722

The above is the interesting part: it shows that the "> " string was
received from the shell subprocess.  And that rings a bell: we have
this window-adjust-process-window-size-function feature, which is new
in Emacs 25.  It sends a TIOCSWINSZ or TIOCSSIZE ioctl to the shell's
pty; perhaps that causes the shell to respond with PS2?  Can you play
with the value of this variable, like set it to a function that
returns nil, so that set-process-window-size is not called, and see if
that helps to avoid the issue?

Re: misbehavior in shell window with ksh

[Stephen Berman]

On Wed, 03 May 2017 20:51:47 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: mkupfer@alum.berkeley.edu,  emacs-devel@gnu.org
>> Date: Tue, 02 May 2017 18:55:01 +0200
>> 
>> #52 0x0000000000553443 in internal_condition_case_1
>> (bfun=bfun@entry=0x589286 <read_process_output_call>, arg=50273987,
>> handlers=handlers@entry=19968, hfun=hfun@entry=0x589218
>> <read_process_output_error_handler>)
>>     at /home/steve/git/emacs-master/src/eval.c:1348
>> #53 0x0000000000588e2f in read_and_dispose_of_process_output
>> (p=p@entry=0x1365d60, chars=chars@entry=0x7ffcbb816460 "> ",
>> nbytes=nbytes@entry=2, coding=coding@entry=0x105c330) at
>> /home/steve/git/emacs-master/src/process.c:5979
>> #54 0x0000000000589095 in read_process_output (proc=proc@entry=20340069,
>> channel=channel@entry=18) at /home/steve/git/emacs-master/src/process.c:5890
>> #55 0x0000000000590a0a in wait_reading_process_output
>> (time_limit=time_limit@entry=30, nsecs=nsecs@entry=0, read_kbd=<optimized
>> out>, do_display=do_display@entry=true, wait_for_cell=wait_for_cell@entry=0,
>> wait_proc=wait_proc@entry=0x0, just_wait_proc=just---Type <return> to
>> continue, or q <return> to quit---
>> _wait_proc@entry=0) at /home/steve/git/emacs-master/src/process.c:5589
>> #56 0x0000000000421953 in sit_for (timeout=timeout@entry=122,
>> reading=reading@entry=true, display_option=display_option@entry=1)
>>     at /home/steve/git/emacs-master/src/dispnew.c:5763
>> #57 0x00000000004f313e in read_char (commandflag=1, map=map@entry=13473155,
>> prev_event=0, used_mouse_menu=used_mouse_menu@entry=0x7ffcbb817b2b,
>> end_time=end_time@entry=0x0) at
>> /home/steve/git/emacs-master/src/keyboard.c:2722
>
> The above is the interesting part: it shows that the "> " string was
> received from the shell subprocess.  And that rings a bell: we have
> this window-adjust-process-window-size-function feature, which is new
> in Emacs 25.  It sends a TIOCSWINSZ or TIOCSSIZE ioctl to the shell's
> pty; perhaps that causes the shell to respond with PS2?  Can you play
> with the value of this variable, like set it to a function that
> returns nil, so that set-process-window-size is not called, and see if
> that helps to avoid the issue?

Bingo!  That variable is a user option and when I change its value with
M-x customize-option to "Do not adjust process window sizes" (i.e. the
function `ignore') and then execute the recipe, "> " is not inserted.
When I return to the customization buffer and change the value back to
the default "Minimum area of any window" (i.e. the function
`window-adjust-process-window-size-smallest') and then switch back to
the *shell* buffer, "> " I see that has now been inserted.

Steve Berman

Re: misbehavior in shell window with ksh

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: mkupfer@alum.berkeley.edu,  emacs-devel@gnu.org
> Date: Thu, 04 May 2017 09:54:23 +0200
> 
> > The above is the interesting part: it shows that the "> " string was
> > received from the shell subprocess.  And that rings a bell: we have
> > this window-adjust-process-window-size-function feature, which is new
> > in Emacs 25.  It sends a TIOCSWINSZ or TIOCSSIZE ioctl to the shell's
> > pty; perhaps that causes the shell to respond with PS2?  Can you play
> > with the value of this variable, like set it to a function that
> > returns nil, so that set-process-window-size is not called, and see if
> > that helps to avoid the issue?
> 
> Bingo!  That variable is a user option and when I change its value with
> M-x customize-option to "Do not adjust process window sizes" (i.e. the
> function `ignore') and then execute the recipe, "> " is not inserted.
> When I return to the customization buffer and change the value back to
> the default "Minimum area of any window" (i.e. the function
> `window-adjust-process-window-size-smallest') and then switch back to
> the *shell* buffer, "> " I see that has now been inserted.

Thanks for looking into this.

Can the shell experts among us please tell whether this is an expected
reaction of a shell to window-resizing ioctl?  And why this is only
seen with ksh?  And why in some cases one needs to set EDITOR in the
environment?

IOW, the window-adjust-process-window-size-function is a standard
feature that is turned on by default; if it turns out that it has
annoying unintended consequences in some use cases, we will have to
rethink when we turn it on and off, IMO.

Re: misbehavior in shell window with ksh

[Mike Kupfer]

Eli Zaretskii wrote:

> Can the shell experts among us please tell whether this is an expected
> reaction of a shell to window-resizing ioctl?  And why this is only
> seen with ksh?  And why in some cases one needs to set EDITOR in the
> environment?

I'm not a shell expert, but I did spend a little time with strace to see
what ksh is doing.

In a regular terminal emulator (xfce4-terminal), when ksh gets SIGWINCH,
it queries for the size of the screen, and it generates one or more
carriage returns before (re)writing the PS1 prompt.

  --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} ---
  rt_sigaction(SIGWINCH, {0x41c250, [], SA_RESTORER|SA_INTERRUPT, 0x7f91cb7cd0e0}, {0x41c250, [], SA_RESTORER|SA_INTERRUPT, 0x7f91cb7cd0e0}, 8) = 0
  ioctl(2, TIOCGWINSZ, {ws_row=25, ws_col=80, ws_xpixel=0, ws_ypixel=0}) = 0
  rt_sigprocmask(SIG_UNBLOCK, [WINCH], NULL, 8) = 0
  rt_sigreturn()                          = -1 EINTR (Interrupted system call)
  write(2, "\r", 1)                       = 1
  ioctl(2, TIOCGWINSZ, {ws_row=25, ws_col=80, ws_xpixel=0, ws_ypixel=0}) = 0
  poll(0x7ffcc1e41dc0, 0, 50)             = 0 (Timeout)
  ioctl(2, TIOCGWINSZ, {ws_row=25, ws_col=80, ws_xpixel=0, ws_ypixel=0}) = 0
  write(2, "\ralto$ ", 7)                 = 7
  select(1, [0], NULL, NULL, NULL)        = ? ERESTARTNOHAND (To be restarted if no handler)

Its behavior in a shell buffer is similar, except it just writes out the
PS2 prompt.

  --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} ---
  rt_sigaction(SIGWINCH, {0x41c250, [], SA_RESTORER|SA_INTERRUPT, 0x7fc02802d0e0}, {0x41c250, [], SA_RESTORER|SA_INTERRUPT, 0x7fc02802d0e0}, 8) = 0
  ioctl(2, TIOCGWINSZ, {ws_row=32, ws_col=78, ws_xpixel=0, ws_ypixel=0}) = 0
  rt_sigprocmask(SIG_UNBLOCK, [WINCH], NULL, 8) = 0
  rt_sigreturn()                          = -1 EINTR (Interrupted system call)
  ioctl(2, TIOCGWINSZ, {ws_row=32, ws_col=78, ws_xpixel=0, ws_ypixel=0}) = 0
  poll(0x7ffc9eb5abf0, 0, 50)             = 0 (Timeout)
  ioctl(2, TIOCGWINSZ, {ws_row=32, ws_col=78, ws_xpixel=0, ws_ypixel=0}) = 0
  select(1, [0], NULL, NULL, {0, 0})      = 0 (Timeout)
  write(2, "> ", 2)                       = 2

I can't explain the difference.

I also checked bash's behavior.  It does not query the current screen
size.

bash in an Emacs shell buffer:

  read(0, 0x6fdc00, 128)                  = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
  --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} ---
  rt_sigreturn()                          = -1 EINTR (Interrupted system call)
  read(0,  <detached ...>

bash in an xfce4-terminal:

  read(0, 0x7ffd51136837, 1)              = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
  --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} ---
  rt_sigreturn()                          = 0
  read(0, 0x7ffd51136837, 1)              = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
  [...]
  --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} ---
  rt_sigreturn()                          = 0
  read(0, 0x7ffd51136837, 1)              = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
  --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} ---
  rt_sigreturn()                          = 0
  read(0, 0x7ffd51136837, 1)              = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
  --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} ---
  rt_sigreturn()                          = 0
  read(0,  <detached ...>

regards,
mike

Re: misbehavior in shell window with ksh

[Eli Zaretskii]

> From: Mike Kupfer <mkupfer@alum.berkeley.edu>
> cc: Stephen Berman <stephen.berman@gmx.net>, emacs-devel@gnu.org
> Date: Thu, 04 May 2017 20:04:03 -0700
> 
> I'm not a shell expert, but I did spend a little time with strace to see
> what ksh is doing.

OK, thanks for looking into this.  AFAIU, the conclusion is that
indeed the offending string comes from the shell as result of Emacs's
telling the shell that its screen size has changed.

So is it enough to conclude that users of shells like this should
customize window-adjust-process-window-size-function to avoid telling
the shell its screen has been resized?  Or do we need a more thorough
solution for this problem?

Re: misbehavior in shell window with ksh

[Mike Kupfer]

Eli Zaretskii wrote:

> AFAIU, the conclusion is that
> indeed the offending string comes from the shell as result of Emacs's
> telling the shell that its screen size has changed.

Agreed.

> So is it enough to conclude that users of shells like this should
> customize window-adjust-process-window-size-function to avoid telling
> the shell its screen has been resized?  Or do we need a more thorough
> solution for this problem?

My testing on Debian 8 shows no problem with bash, zsh, tcsh, csh, mksh,
yash, or rc.  Since it appears to be just a problem with ksh, I'd be
fine with documenting the issue and workaround (in PROBLEMS, I guess,
next to the other shell-related issues).

mike

Re: misbehavior in shell window with ksh

[Eli Zaretskii]

> From: Mike Kupfer <mkupfer@alum.berkeley.edu>
> cc: stephen.berman@gmx.net, emacs-devel@gnu.org
> Date: Sat, 06 May 2017 11:41:38 -0700
> 
> Since it appears to be just a problem with ksh, I'd be fine with
> documenting the issue and workaround (in PROBLEMS, I guess, next to
> the other shell-related issues).

Done.  Thanks.

Re: misbehavior in shell window with ksh

[Mike Kupfer]

Stephen Berman wrote:

> By edebugging shell.el and comint.el I see that after typing `C-x 0' in
> the recipe, the function comint-output-filter is invoked with the value
> #<process shell> for its argument `proc' and the value "> " for its
> argument `string', and the latter value is what is inserted into the
> *shell* buffer.  I have failed to find out how that argument gets that
> value or even how comint-output-filter gets invoked.  If anyone has any
> advice for how to proceed, I can try it.

The "> " is coming from the PS2 environment variable (secondary prompt
string).  If I change PS2 to "foo> ", then "foo> " is what gets
inserted.  (This probably isn't what you were asking for, but I thought
I'd note it.)

Also, I looked into Eli's question

> Could this be related to some of your shell customizations?

Having EDITOR set to emacs (or emacsclient) seems to be required for me
to reproduce the problem.

  $ export EDITOR=emacs
  $ emacs -Q -nw
  => problem reproduces

  $ emacs -Q -nw (w/o EDITOR set)
  M-x shell RET
  export EDITOR=emacs RET
  ksh RET
  => problem reproduces

  $ export EDITOR=emacs
  $ emacs -Q -nw
  M-x shell RET
  unset EDITOR RET
  ksh RET
  => problem does not reproduce

mike

Re: misbehavior in shell window with ksh

[Tino Calancha]

On Mon, 1 May 2017, Mike Kupfer wrote:

> Stephen Berman wrote:
>> Could this be related to some of your shell customizations?
>
> Having EDITOR set to emacs (or emacsclient) seems to be required for me
> to reproduce the problem.
>
>  $ export EDITOR=emacs
>  $ emacs -Q -nw
>  => problem reproduces
>
>  $ emacs -Q -nw (w/o EDITOR set)
>  M-x shell RET
>  export EDITOR=emacs RET
>  ksh RET
>  => problem reproduces
>
>  $ export EDITOR=emacs
>  $ emacs -Q -nw
>  M-x shell RET
>  unset EDITOR RET
>  ksh RET
>  => problem does not reproduce
Thanks.  I can reproduce the issue if i set EDITOR as you do.

*) Originally, with EDITOR set to
'/home/calancha/bin/edit'
i don't see the bug.

M-x emacs -Q RET
M-x shell RET
$ ksh RET
$ echo $EDITOR
/home/calancha/bin/edit
$ export EDITOR=$EDITOR ; No issue.

**) If i set EDITOR equal to some unexistant file like
'foo', i don't see the bug (but it depends of the name).

M-x emacs -Q RET
M-x shell RET
$ ksh RET
$ [ "" != "$(which emasc)" ] || [ "" != "$(which foo)" ] || echo "Both unset"
Both unset
$ export EDITOR=foo ; no issue
$ export EDITOR=emasc ; no issue

***) If i set EDITOR to some unexistant file containing some keywords,
then i might the issue:

M-x emacs -Q RET
M-x shell RET
$ ksh RET
$ [ "" != "$(which foo-vi)" ] || [ "" != "$(which foo-emacs)" ] || echo "Both unset"
Both unset

$ export EDITOR=foo-vi ; It shows the bug.
$ export EDITOR=foo-emacs ; Same.

****) Once the bug appears, reseting EDITOR to the original value
doesn't help.  You must kill the buffer and call again:
M-x shell.

M-x emacs -Q RET
M-x shell RET
$ ksh RET
$ EDITOR_ORIG=$EDITOR
$ export EDITOR=foo-emacs ; It shows the bug.
$ export EDITOR=$EDITOR_ORIG ; It doesn't help.

Regards,
Tino

Re: misbehavior in shell window with ksh

[Tino Calancha]

On Sun, 30 Apr 2017, Mike Kupfer wrote:

> From emacs -Q, using Emacs master 6fa9cc05, if I do the following steps
>
>  M-x shell RET
>  ksh RET
>  C-x o RET
>  C-x 0 RET
>
> a ">" appears after the shell prompt in the *shell* buffer:
>
>  alto$ ksh
>  alto$ >
>
> If I then press RET, I get
>
>  alto$ ksh
>  alto$ >
>  : not found [No such file or directory]
>  alto$
>
> I've reproduced this behavior a couple different recent versions of
> Emacs, including 25.1.91 and 25.2-rc2.  And I've reproduced it on both
> Solaris 11 and Debian 8.
Cannot reproduce this neither with 'emacs -Q' nor 'emacs -nw -Q'.
I have used:

* Debian 8 
* Emacs-25.2-rc2

Regards,
Tino