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"?