SIGINT and process substitution leakage

2019-09-21 Thread Grisha Levit
Running the below a few times results in a stray child bash process (and a borked terminal, as the child will still read from the same tty): kill -INT -$$ & while :; do : <(:); done This seems to have started with bash-20150724 [1] and is present in the current devel branch. [1]

Re: Incorrect example for `[[` command.

2019-09-21 Thread Chet Ramey
On 9/20/19 8:12 PM, hk wrote: > What is wrong is the description `zero or one instances of 'a''. But if we > correct the right hand side word to beĀ  `[[:space:]]*(a)?b' that it does > match what the description says.(the parenthese around `a' could be omitted). Yeah, that's the typo. > I was

Re: [Patch] (tiny problem) bad short_doc for % command

2019-09-21 Thread Chet Ramey
On 9/21/19 1:37 PM, Robert Elz wrote: > Date:Sat, 21 Sep 2019 17:18:47 +0200 > From:Andreas Schwab > Message-ID: <875zllu17s@igel.home> > > | A job spec already starts with %. > > That's not what was meant. It's the right answer, though. > > In, for

Re: Incorrect example for `[[` command.

2019-09-21 Thread Ilkka Virta
On 21.9. 21:55, Dmitry Goncharov wrote: On Sat, Sep 21, 2019 at 12:34:39PM +0300, Ilkka Virta wrote: [[:space:]]*?(a)b isn't a well-defined POSIX ERE: 9.4.6 EREs Matching Multiple Characters The behavior of multiple adjacent duplication symbols ( '+', '*', '?', and intervals)

Re: Incorrect example for `[[` command.

2019-09-21 Thread Dmitry Goncharov via Bug reports for the GNU Bourne Again SHell
On Sat, Sep 21, 2019 at 12:34:39PM +0300, Ilkka Virta wrote: > [[:space:]]*?(a)b isn't a well-defined POSIX ERE: > >9.4.6 EREs Matching Multiple Characters > >The behavior of multiple adjacent duplication symbols ( '+', '*', '?', >and intervals) produces undefined results. > >

Output of jobs wrong

2019-09-21 Thread Martin Schulte
Hello, I'm not feeling well writing this mail because so far I've not been able to reproduce the behaviour I describe in the following... I was trying to understand the "[Patch] (tiny problem) bad short_doc for % command" thread when I entered more or less the following sequence of commands: $

Re: [Patch] (tiny problem) bad short_doc for % command

2019-09-21 Thread Robert Elz
Date:Sat, 21 Sep 2019 17:18:47 +0200 From:Andreas Schwab Message-ID: <875zllu17s@igel.home> | A job spec already starts with %. That's not what was meant. In, for example: jinx$ help -s wait wait: wait [-fn] [id ...] the command name appears

Some questions about the use of readline()

2019-09-21 Thread Aust zhu
Hello! I am having some problems with readline(). When calling the readline() function it is blocked. I want to set a timeout for the readline function to return. I tried setting rl_done=1, and fprintf(rl_instream,"\r\n"); fflush(rl_instream); can't make the readline() function return.

Re: [Patch] (tiny problem) bad short_doc for % command

2019-09-21 Thread Andreas Schwab
On Sep 21 2019, "Christopher Chittleborough" wrote: > The command "help -s %" outputs > %: job_spec [&] > when it should output > %: % job_spec [&] > because the $SHORT_DOC for "%" in builtins/reserved.def is wrong. A job spec already starts with %. Andreas. -- Andreas

[Patch] (tiny problem) bad short_doc for % command

2019-09-21 Thread Christopher Chittleborough
The command "help -s %" outputs %: job_spec [&] when it should output %: % job_spec [&] because the $SHORT_DOC for "%" in builtins/reserved.def is wrong. The attached patch fixes this. BTW, this is not the smallest bug ever reported: see

Re: Incorrect example for `[[` command.

2019-09-21 Thread hk
Thanks. Have learnt a lot from your replies. On Sat, Sep 21, 2019 at 5:34 PM Ilkka Virta wrote: > On 21.9. 03:12, hk wrote: > > Thanks for the reply. I was wrong in my report. It does match values like > > aab and aab in its original form. > > In some systems, yes. (It does that on my

Re: Incorrect example for `[[` command.

2019-09-21 Thread Ilkka Virta
On 21.9. 03:12, hk wrote: Thanks for the reply. I was wrong in my report. It does match values like aab and aab in its original form. In some systems, yes. (It does that on my Debian, but doesn't work at all on my Mac.) It is syntatically correct as a regular expression.