Re: bash sets O_NONBLOCK on pts

2019-10-02 Thread Stephane Chazelas
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

Re: bash sets O_NONBLOCK on pts

2019-10-02 Thread Matteo Croce
On Wed, Oct 2, 2019 at 8:16 PM Andreas Schwab wrote: > > On Okt 02 2019, Matteo Croce wrote: > > > It seems to me that bash restores the flag, cat prints an error when not: > > > > $ cat > > $ > > > > the same is not true if running multiple commands: > > > > $ ./foo; cat > > cat: -: Resource

Re: bash sets O_NONBLOCK on pts

2019-10-02 Thread Andreas Schwab
On Okt 02 2019, Matteo Croce wrote: > It seems to me that bash restores the flag, cat prints an error when not: > > $ cat > $ > > the same is not true if running multiple commands: > > $ ./foo; cat > cat: -: Resource temporarily unavailable > $ > > Why this different behaviour? Because it's

Re: bash sets O_NONBLOCK on pts

2019-10-02 Thread Matteo Croce
On Wed, Oct 2, 2019 at 7:50 PM Andrew Church wrote: > > >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

Re: bash sets O_NONBLOCK on pts

2019-10-02 Thread 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

Re: bash sets O_NONBLOCK on pts

2019-10-02 Thread Matteo Croce
On Wed, Oct 2, 2019 at 4:28 PM Chet Ramey wrote: > > On 10/2/19 8:27 AM, Matteo Croce wrote: > > > Bash Version: 5.0 > > Patch Level: 7 > > Release Status: release > > > > Description: > > Sometimes bash leaves the pts with O_NONBLOCK set, and all programs > > reading from stdin will get an

Re: bash sets O_NONBLOCK on pts

2019-10-02 Thread Stephane Chazelas
2019-10-02 14:27:48 +0200, Matteo Croce: [...] > Sometimes bash leaves the pts with O_NONBLOCK set, and all programs > reading from stdin will get an EAGAIN: [...] Can you reproduce it with bash --norc Or with: INPUTRC=/dev/null bash --norc ? If you could reproduce it with: strace

Re: shouldn't it the comma operator has the lowerest precedence intheshell arithmetic expression?

2019-10-02 Thread Chet Ramey
On 10/2/19 10:50 AM, hkadeveloper wrote: > Yes. I understand what you are saying. I mean isn’t it a little > inconsistent about the comment, the macro name(EXP_HIGHEST) and the macro > value(expcomma)? I know what it means. ;-) It's just the one you call first to start the recursive descent. --

Re: shouldn't it the comma operator has the lowerest precedence intheshell arithmetic expression?

2019-10-02 Thread hkadeveloper
Yes. I understand what you are saying. I mean isn’t it a little inconsistent about the comment, the macro name(EXP_HIGHEST) and the macro value(expcomma)? Thanks for you reply! -- Original -- From: "Chet Ramey" ; <"Chet Ramey" ;> Date:

Re: bash sets O_NONBLOCK on pts

2019-10-02 Thread Chet Ramey
On 10/2/19 8:27 AM, Matteo Croce wrote: > Bash Version: 5.0 > Patch Level: 7 > Release Status: release > > Description: > Sometimes bash leaves the pts with O_NONBLOCK set, and all programs > reading from stdin will get an EAGAIN: Without a way to reliably reproduce this, it's just a transient

bash sets O_NONBLOCK on pts

2019-10-02 Thread Matteo Croce
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches

Re: shouldn't it the comma operator has the lowerest precedence in the shell arithmetic expression?

2019-10-02 Thread Chet Ramey
On 10/1/19 8:35 PM, hk wrote: > Configuration Information : > Bash Version: 5.0 > Patch Level: 0 > Release Status: release > > Description: > the code snippet from expr.c starting from line 141: > >> /* This should be the function corresponding to the operator with the >>highest precedence.

Re: shebang-less script execution not resetting some options

2019-10-02 Thread L A Walsh
On 2019/10/02 03:49, Ilkka Virta wrote: > > If the execl() function fails due to an error equivalent to the > [ENOEXEC] [...] the shell shall execute a command equivalent to > having a shell invoked with the pathname resulting from the > search as its first

Re: shebang-less script execution not resetting some options

2019-10-02 Thread Greg Wooledge
On Wed, Oct 02, 2019 at 03:11:18AM -0700, L A Walsh wrote: > > Bash allows a child of itself (a subshell) to read the commands. > > GNU find -exec uses /bin/sh to run it. > > zsh and csh both use /bin/sh to run it, I think. > So if a user has 'rbash' in /etc/passwd, they might get a real

Re: ARGV[@] Not Always Populated

2019-10-02 Thread Chet Ramey
On 10/1/19 6:33 PM, Adam Danischewski wrote: > If you don't access the ARGV array before you drop into a function, ARGV is > not populated. > [...] > If you uncomment the echo at the top of the script then the printing is as > expected. > I realize the Bash Documentation states: >

Re: shebang-less script execution not resetting some options

2019-10-02 Thread Ilkka Virta
On 2.10. 13:11, L A Walsh wrote: On 2019/10/01 05:41, Greg Wooledge wrote: On Tue, Oct 01, 2019 at 04:14:00AM -0700, L A Walsh wrote: On 2019/09/30 14:39, Grisha Levit wrote: A few of the recently-added shopt options aren't getting reset when running a shebang-less script, this

Re: shebang-less script execution not resetting some options

2019-10-02 Thread L A Walsh
On 2019/10/01 05:41, Greg Wooledge wrote: > On Tue, Oct 01, 2019 at 04:14:00AM -0700, L A Walsh wrote: > >> On 2019/09/30 14:39, Grisha Levit wrote: >> >>> A few of the recently-added shopt options aren't getting reset when >>> running a shebang-less script, this should fix it up: >>>