Re: [PATCH] input: Reset eof in reset_input

Nathan Royce <[email protected]> Wed, 28 May 2025 14:47:49 -0500
Newsgroups org.kernel.vger.dash
Message-ID <CALaQ_hq1d7=ySGSHeczuGC=SUD=o6P9CkZTeHC0wFdZF9gb=Nw@mail.gmail.com>
On Wed, May 28, 2025 at 6:33 AM Herbert Xu <[email protected]> wrote:
>
> On Tue, May 27, 2025 at 07:09:17PM -0500, Nathan Royce wrote:
> > I hope I'm doing this correctly by contacting you, as I saw no process
> > to go by (eg. via README)...
>
> Thanks for the report.  This should go to the mailing list which
> I have now cc'ed.
>
> > Using the script sample below, the "read" for the "After" prompt which
> > happens after the "loopRead" function which reads from a redirected
> > "heredoc", ends up being skipped over (or rather, not waiting for user
> > tty stdin, as if it was somehow still being read by the loop, even
> > though it's out of scope?).
> >
> > Success: 0.5.12
> > Fail: b3e38adf6718801e7f06267b438c45caec9523bb
> > Success: Bash - 5.2.037
>
> It's the new EOF handling patch, which was not reset correctly
> when stdin is redirected, causing the EOF to persist after redirection.
>
> Here is a reproducer:
>
> echo ok | {
>         read x < /dev/null
>         read x
>         echo $x
> }
>
> ---8<---
> Ensure that the EOF state is reset in reset_input as otherwise
> the new stdin may be treated as empty.
>
> Reported-by: Nathan Royce <[email protected]>
> Fixes: 69786bc79f9b ("input: Fix pungetc on PEOF")
> Signed-off-by: Herbert Xu <[email protected]>
>
> diff --git a/src/input.c b/src/input.c
> index 6388b83..1aff3d4 100644
> --- a/src/input.c
> +++ b/src/input.c
> @@ -684,6 +684,7 @@ void __attribute__((noinline)) flush_input(void)
>
>  void reset_input(void)
>  {
> -       flush_input();
>         stdin_istty = -1;
> +       basepf.eof = 0;
> +       flush_input();
>  }
> --
> Email: Herbert Xu <[email protected]>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Confirmed patch success.
Might I suggest adding a README to at least contain information on
reporting procedure? Maybe I was missing something and it's just
assumed everyone would know that everything under the kernel umbrella
would have a ML as "<project>@vger.kernel.org"?