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:
>>>
>>
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 shoul
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:
>BAS
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 shell
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 op
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. *
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
-specs=/usr/li
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 i
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: Wed,O
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.
--
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 -
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 EAGAIN
>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_NONBLOC
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 display
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 rese
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 tem
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
17 matches
Mail list logo
