Re: Incorrect example for `[[` command.

2019-09-22 Thread Chet Ramey 
On 9/21/19 5:34 AM, 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.

It's ambiguous, but it can be interpreted as valid. I wonder why they used
"undefined" instead of the usual "unspecified."


-- 
``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: Wrong command option in the manual examples

2019-09-22 Thread Chet Ramey 
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/

Re: Output of jobs wrong

2019-09-22 Thread Chet Ramey 
On 9/21/19 2:48 PM, Martin Schulte wrote:
> 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...

Sorry, I can't reproduce it.

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: Some questions about the use of readline()

2019-09-22 Thread Chet Ramey 
On 9/21/19 11:23 AM, Aust zhu wrote:
> 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.

You don't post any code, but I assume you're using a signal handler for
SIGALRM.

> 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?

SIGALRM is one of the signals readline handles, so it will resume whatever
it was doing (presumably reading a character) if the calling application's
signal handler returns.

You can use rl_signal_event_hook or some other mechnanism to longjmp back
to readline's caller, once your signal handler notes that your application
received the SIGALRM. That's how bash implements read builtin timeouts in
the presence of `read -e'.

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: Wrong command option in the manual examples

2019-09-22 Thread hk 
GNU-implemented `find' does have a `-depth' option and  a `-maxdepth'
option.
Directories[findutils]


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/
>

Regular Expression matching operation =~

2019-09-22 Thread Allodoxaphobia 
In moving a bash ver. 4.3.48 (Ubuntu) program to a bash ver. 5.0.11 
(FreeBSD) environment I encountered either a bug, a quirk, or 
an undocumented feature.

I was using a null regexp as a "match for anything" case when an
optional command line parameter (a test pattern) was omitted.

I boiled down what I was experiencing to 

$ bash -version
GNU bash, version 4.3.48(1)-release (x86_64-pc-linux-gnu)
$ [[ "String" =~ "ring" ]] ; echo $?
0
$ [[ "String" =~ "" ]] ; echo $?
0
$

$ bash -version
GNU bash, version 5.0.11(0)-release (amd64-portbld-freebsd12.0)
$ [[ "String" =~ "ring" ]] ; echo $?
0
$ [[ "String" =~ "" ]] ; echo $?
2
$

A null regexp works Just Fine in both the Ubuntu and FreeBSD
environments. E.g.:

$ grep "" /etc/shells

Jonesy
-- 
  Marvin L Jones| Marvin  | W3DHJ.net  | linux
   38.238N 104.547W |  @ jonz.net | Jonesy |  FreeBSD
* Killfiling google & banter.com: jonz.net/ng.htm

Re: Regular Expression matching operation =~

2019-09-22 Thread Grisha Levit 
On Sun, Sep 22, 2019 at 9:02 PM Allodoxaphobia  wrote:
>
> In moving a bash ver. 4.3.48 (Ubuntu) program to a bash ver. 5.0.11
> (FreeBSD) environment I encountered either a bug, a quirk, or
> an undocumented feature.
>
> I was using a null regexp as a "match for anything" case

This behavior depends on the OS's underlying regex implementation.
For example BSD says (man 3 regex, under IMPLEMENTATION CHOICES):

An empty parenthesized subexpression, `()', is legal and matches an empty
(sub)string.  An empty string is not a legal RE.