Re: Unexpected stdin-behavior

[Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>]

> On 21 October 2021 at 20:14 Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> On Thu, Oct 21, 2021 at 9:47 AM Tycho Kirchner <tychokirchner@xxxxxxx> wrote:
> > thanks for your response. Could you please elaborate how your answer
> > explains the difference in the output between the commands
> > zsh -s and
> > zsh -s -i
> > ?
> 
> When -i is NOT present, stdin is set to line buffered for the stdio library.
> 
> I don't actually see any difference between -s and -s -i except for
> the printing of the prompt, when I try it with the latest development
> version, and the only code difference is the removal of stdio.  This
> is probably an unintentional behavior change in the new code, and may
> bear looking into.
> 
> For zsh-workers (particularly PWS), I'm referring to this bit of code in init.c:
> 
>     /*
>      * Finish setting up SHIN and its relatives.
>      */
>     shinbufalloc();
>     if (isset(SHINSTDIN) && !SHIN && unset(INTERACTIVE)) {
> #ifdef _IONBF
>         setvbuf(stdin, NULL, _IONBF, 0);
> #else
>         setlinebuf(stdin);
> #endif
>     }
> 
> We either don't need the set*buf business at all, or we need its
> equivalent for shinbuf, I think.

That _IONBF is (and has always been) inconsistent with setlinebuf(), surely?
It means no buffering.

As far as shinbuf itself is concerned, is the most logical behaviour
line buffering (i.e. read ahead only up to a \n) if interactive?

pws