21.4.13: ^c in shell now works, but now shell output only shows up when cursor moves

[Karr, David]

I have "process-connection-type" set to t in both 21.4.13 and 21.4.18.
In 21.4.18, the output is not blocky, but it is in 21.4.13.  What's
curious is that in 21.4.13, when I first run my test case of running an
app from the shell prompt, the first run comes out fine.  Each time
after that, however, I only see a block of output when I move the
cursor.

> -----Original Message-----
> From: Glynn Clements [mailto:glynn at gclements.plus.com] 
> 
> Karr, David wrote:
> 
> > No, I'm not compiling them, I just download with the installer.  In 
> > testing 21.4.18 installed on the same box, I see that the "blocky 
> > output" does NOT occur (and ^c^c still works).
> > 
> > Would this have something to do with "process-connection-type"?
> 
> As Ben says, quite likely. If it's set to nil, processes will 
> use pipes unless something explicitly binds it to t.
> 
> One consequence of using pipes is that stdout will normally 
> be block-buffered by default, whereas it will be 
> line-buffered if it is associated with a terminal.
> 
> Another consequence is that Ctrl-C, Ctrl-Z etc don't work with pipes.
> 
> Also, some programs explicitly modify their behaviour if 
> stdin/stdout correspond to a terminal (e.g. only displaying 
> prompts for a terminal).
> 
> It isn't really clear (to me) how process-connection-type is 
> meant to be used. Obviously, if a particular process really 
> needs a specific setting, then the caller should bind it 
> appropriately.
> 
> But how it should be set globally, or when the global setting 
> should be honoured, isn't clear. E.g. should "shell" be 
> explicitly binding it to t, or using the global setting? It 
> seems unlikely that you would actually want to use pipes for 
> an interactive shell.
> 
> -- 
> Glynn Clements <glynn at gclements.plus.com>
>