Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail From: Stephane Chazelas Newsgroups: gnu.bash.bug Subject: Re: bash sets O_NONBLOCK on pts Date: Wed, 2 Oct 2019 20:06:34 +0100 Lines: 97 Approved: bug-bash@gnu.org Message-ID: References: <5d94e361.21745@msgid.achurch.org> <20191002190633.gyhz77xgitkwvmov@chaz.gmail.com> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: usenet.stanford.edu 1570043414 15719 209.51.188.17 (2 Oct 2019 19:10:14 GMT) X-Complaints-To: action@cs.stanford.edu To: bug-bash@gnu.org Envelope-to: bug-bash@gnu.org X-Injected-Via-Gmane: http://gmane.org/ User-Agent: NeoMutt/20171215 Content-Disposition: inline In-Reply-To: <5d94e361.21745@msgid.achurch.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Mailman-Original-Message-ID: <20191002190633.gyhz77xgitkwvmov@chaz.gmail.com> X-Mailman-Original-References: <5d94e361.21745@msgid.achurch.org> Xref: csiph.com gnu.bash.bug:15466 2019-10-03 02:49:36 +0900, Andrew Church: > >Well, it's not so uncommon, I had it a few times. Reading on internet > >it seems that other users have it but don't notice it. > > The fault could be in some other program accessing the terminal. Bash > does not clear O_NONBLOCK on displaying a prompt, so if a previously > executed program sets O_NONBLOCK on stdin and then exits, that state > will remain until some other program unsets it. For example: > > $ cat >foo.c > #include > int main(void) {fcntl(0, F_SETFL, O_NONBLOCK); return 0;} > ^D > $ cc foo.c > $ ./a.out > $ cat > cat: -: Resource temporarily unavailable [...] Good point. I see a difference between versions of bash there: With GNU dd: ~$ bash5 --norc bash5-5.0$ dd iflag=nonblock dd: error reading 'standard input': Resource temporarily unavailable 0+0 records in 0+0 records out 0 bytes copied, 0.000150515 s, 0.0 kB/s bash5-5.0$ cat ^C bash5-5.0$ exit ~$ bash --norc bash-4.4$ dd iflag=nonblock dd: error reading 'standard input': Resource temporarily unavailable 0+0 records in 0+0 records out 0 bytes copied, 0.000126312 s, 0.0 kB/s bash-4.4$ cat cat: -: Resource temporarily unavailable In bash5, with strace, we see: fcntl(0, F_GETFL) = 0x8802 (flags O_RDWR|O_NONBLOCK|O_LARGEFILE) fcntl(0, F_SETFL, O_RDWR|O_LARGEFILE) = 0 That seems to be done by sh_unset_nodelay_mode() Which points to this change: commit bc371472444f900d44050414e3472f7349a7aec7 Author: Chet Ramey Date: Mon Jan 30 15:50:08 2017 -0500 commit bash-20170127 snapshot diff --git a/CWRU/CWRU.chlog b/CWRU/CWRU.chlog index b8436d64..74a0463e 100644 --- a/CWRU/CWRU.chlog +++ b/CWRU/CWRU.chlog @@ -13027,3 +13027,21 @@ subst.c after reading a double-quoted string, make sure the W_NOCOMSUB and W_NOPROCSUB flags make it to the recursive invocation. Fixes bug reported by Jens Heyens + + 1/23 + ---- +lib/readline/signals.c + - _rl_orig_sigset: original signal mask, set and restored by + rl_set_signals (rl_clear_signals doesn't block signals). If we + are not installing signal handlers, just save signal mask each + time rl_set_signals is called + +lib/readline/input.c + - rl_getc: use _rl_orig_sigmask in the call to pselect(), so we block + the set of signals originally blocked by the calling application. + Fixes bug reported by Frédéric Brière + +parse.y + - yy_readline_get: try to unset NONBLOCK mode on readline's input + file descriptor before calling readline(). Inspired by report from + Siteshwar Vashisht Given that the OP is running 5.0.7, they should have that change already. Maybe the fcntl(O_NONBLOCK) is done by a command run by a completion widget. -- Stephane