SIGINT and process substitution leakage
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] https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel=7afeb718cb55ab9f224936a2b58cde07559eb59f
Re: Incorrect example for `[[` command.
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 also wrong saying it was a pattern instead of a regular expression. > It is syntatically correct as a regular expression. That's true. According to the POSIX ERE definition, the `?' is a special ERE character in an invalid position (it's only special after a specifier that matches a single character, not after a separate specifier that matches multiple characters), so it matches itself. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [Patch] (tiny problem) bad short_doc for % command
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 example: > > jinx$ help -s wait > wait: wait [-fn] [id ...] > > the command name appears both before and after the ':', as if to > say "The usage for the wait command is "wait" optional 'f' and 'n' flags, > and some number of optional "id" args. The job spec, introduced by the `%', *is* the command. It's explained in the man page. Even a `%' by itself, without any job name or number, is a job spec. So `%' is not a command name per se -- the command that gets invoked is either `fg' or `bg'. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Incorrect example for `[[` command.
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) produces undefined results. https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/basedefs/V1_chap09.html This is unfortunate. *? and +? are widely used not greedy regexes. In Perl-compatible regexes. Bash uses POSIX extended regular expressions. And on a GNU system, while *? and +? don't give errors when used in an ERE, they still don't make the repetition non-greedy. They just act the same as a single * (as far as I can tell anyway). bash$ re='<.+?>' bash$ [[ "ace" =~ $re ]] && echo $BASH_REMATCH c bash$ [[ "a<>e" =~ $re ]] && echo $BASH_REMATCH <> -- Ilkka Virta / itvi...@iki.fi
Re: Incorrect example for `[[` command.
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. > > https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/basedefs/V1_chap09.html This is unfortunate. *? and +? are widely used not greedy regexes. regards, Dmitry
Output of jobs wrong
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: $ help -s % %: job_spec [&] $ sleep 10 ^C [Interrupted with CTRL-C - maybe "exactly" after 10 seconds] $ sleep 100 & $ sleep 200 & $ sleep 30 & $ % ^C [Interrupted with CTRL-C] $ sleep 300 & $ jobs [1] Running sleep 10 & [2]- Running sleep 10 & [3]+ Running sleep 300 & So job 1 and job 2 listed the wrong argument. I checked this from a second terminal with 'ps -lf' - and there were three sleep with arguments 100, 200 and 300... Systeminfo: $ uname -a Linux martnix4 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u5 (2019-08-11) x86_64 GNU/Linux $ echo $BASH_VERSION 4.4.12(1)-release Sorry, I would like to be more helpful - but maybe someone else has noticed a similiar problem or has an idea with the sources in mind. Best regards, Martin
Re: [Patch] (tiny problem) bad short_doc for % command
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 both before and after the ':', as if to say "The usage for the wait command is "wait" optional 'f' and 'n' flags, and some number of optional "id" args. On the other hand: jinx$ help -s % %: job_spec [&] whetre the '%' command name is missing. This is actually something of a weird case, as a command which consists entirely of a job_spec is treated the same as the '% job_spec' command (ie: one can use either "%1" or "% %1") so the help probably needs to be enhanced even more. kre
Some questions about the use of readline()
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. What should I do to make the readline() function return? I am using libreadline-8.0 Thank you!
Re: [Patch] (tiny problem) bad short_doc for % command
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 Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
[Patch] (tiny problem) bad short_doc for % command
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 https://sourceware.org/bugzilla/show_bug.cgi?id=21399 Cheers -- Chrisdiff -Naur bash-5.0/builtins/reserved.def bash-5.0-nonit/builtins/reserved.def --- bash-5.0/builtins/reserved.def 2016-05-13 04:05:17.0 +1000 +++ bash-5.0-nonit/builtins/reserved.def 2019-09-21 16:25:05.465896269 +1000 @@ -175,7 +175,7 @@ $BUILTIN % $DOCNAME fg_percent -$SHORT_DOC job_spec [&] +$SHORT_DOC % job_spec [&] Resume job in foreground. Equivalent to the JOB_SPEC argument to the `fg' command. Resume a
Re: Incorrect example for `[[` command.
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 Debian, but doesn't work at > all on my Mac.) > > > It is syntatically correct as a regular expression. > > [[: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. > > > https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/basedefs/V1_chap09.html > > > -- > Ilkka Virta / itvi...@iki.fi >
Re: Incorrect example for `[[` command.
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. [[: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. https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/basedefs/V1_chap09.html -- Ilkka Virta / itvi...@iki.fi
