Incorrect example for `[[` command.
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security uname output: Linux hk 4.15.0-62-generic #69-Ubuntu SMP Wed Sep 4 20:55:53 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.0 Patch Level: 0 Release Status: release Description: On section 3.2.4.2 of Bash Reference Manual, the example on* [[...]]* (page 13 in the PDF) is incorrect. Specifically, the example say *[[ $line =~ [[:space:]]*?(a)b ]]* will match values like *'aab'* and* 'aab*'. But it won't. The operator is* =~*, but the operand on the right side is a pattern while it should be a regular expression. Repeat-By: [Describe the sequence of events that causes the problem to occur.] Fix: [Description of how to fix the problem. If you don't know a fix for the problem, don't include this section.]
Re: Incorrect example for `[[` command.
Thanks for the reply. I was wrong in my report. It does match values like aab and aab in its original form. 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). I was also wrong saying it was a pattern instead of a regular expression. It is syntatically correct as a regular expression. A word can be syntactically correct as a pattern and a regular expression at the same time though the semantic might be different in most cases. On Fri, Sep 20, 2019 at 11:48 PM Chet Ramey wrote: > On 9/20/19 1:40 AM, hk wrote: > > > Bash Version: 5.0 > > Patch Level: 0 > > Release Status: release > > > > Description: > > On section 3.2.4.2 of Bash Reference Manual, the example on* > > [[...]]* (page 13 in the PDF) is incorrect. Specifically, the example > say *[[ > > $line =~ [[:space:]]*?(a)b ]]* will match values like *'aab'* and* > > 'aab*'. But it won't. The operator is* =~*, but the operand on the > > right side is a pattern while it should be a regular expression. > > Thanks for the report, this is a good catch. It's been this way since 2011. > > It's supposed to be a regular expression, and there's a typo. You're right > that it doesn't match the same things as if it were interpreted as a shell > pattern. > > The pattern would match the description if it were `[[:space:]]*(a)?b'. > > The pattern, once corrected, does match the strings in the example below, > since, as the description says, it matches "a sequence of characters in the > value." > > The regexp is unanchored, though you can anchor it yourself. That's > arguably less useful than the anchored case (like, say, grep), but that's > what you get from regcomp/regexec, and you have $BASH_REMATCH to see what > you matched. > > 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/ >
Wrong command option in the manual examples
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security uname output: Linux hk 4.15.0-62-generic #69-Ubuntu SMP Wed Sep 4 20:55:53 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.0 Patch Level: 0 Release Status: release Description: On the section 3.2.6(GNU Parallel, page 16 in the pdf) of Bash Reference Manual. The manual uses `find' command to illustrate possible use cases of `parallel' as examples. but the option `-depth' does not accept any argument, I think it means `-maxdepth` option instead. Repeat-By: [Describe the sequence of events that causes the problem to occur.] Fix: replace `-depth' with `-maxdepth'
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: Wrong command option in the manual examples
GNU-implemented `find' does have a `-depth' option and a `-maxdepth' option. Directories[findutils] <https://www.gnu.org/software/findutils/manual/html_node/find_html/Directories.html#Directories> On Mon, Sep 23, 2019 at 2:15 AM Chet Ramey wrote: > On 9/20/19 10:24 PM, hk wrote: > > > Bash Version: 5.0 > > Patch Level: 0 > > Release Status: release > > > > Description: > > On the section 3.2.6(GNU Parallel, page 16 in the pdf) of Bash > > Reference Manual. The manual uses `find' command to illustrate > > possible use cases of `parallel' as examples. but the option `-depth' > > does not accept any argument, I think it means `-maxdepth` option > > instead. > > -depth n > True if the depth of the file relative to the starting point of > the traversal is n. > > It's not in POSIX, and maybe GNU find doesn't implement it. > > -- > ``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/ >
shouldn't it the comma operator has the lowerest precedence in the shell arithmetic expression?
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. */ > #define EXP_HIGHEST expcomma Am I understanding it wrong or is it a typo?
Re: shouldn't it the comma operator has the lowerest precedence in the shell arithmetic expression?
sorry for the typo in the title, it should be *lowest*. On Wed, Oct 2, 2019 at 8:35 AM 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. */ >> #define EXP_HIGHEST expcomma > > > Am I understanding it wrong or is it a typo? >
