feat(stdlib): extract function

[Mte90]

Ref: #449

So I implemented the extract function in amber, required a new function contains_multiple

[Mte90]

Implemented new functions for contains and also the regex one with their tests.

[hdwalters]

Need to use sed -n (suppress automatic printing), and /.../p to print matching lines:

...
    output = $ echo "{source}" | sed "{flag}" -ne "/{search}/p" $
} else {
    output = $ echo "{source}" | sed -ne "/{search}/p" $
...

[Mte90]

it is working as it is now, if I change in that way doesn't work

[hdwalters]

Need to return true if sed output is not empty:

if output != "" {
    return true
}

[hdwalters]

See above for reasons why it's still recommended to use if output != "".

[Ph0enixKM]

I agree with @hdwalters suggestions

[Mte90]

I have some doubts about removing /../ as I think that should be the user to choose how to write the regular expression.

[hdwalters]

@Mte90 wrote:

I have some doubts about removing /../ as I think that should be the user to choose how to write the regular expression.

I still can't agree with this; I maintain that calling functions should pass regex not /regex/g.

1. The slashes are delimiters for the regular expression; they are not part of the expression itself. In all the languages I'm familiar with, regular expressions are passed as quote delimited strings; requiring users to pass slashes as well is just going to cause confusion. And the "global" modifier only makes sense in a replace, not a search context.

2. While we currently implement regular expression support using sed, this may change in the future. If we force scripts to pass slashes as well, and the hypothetical new method does not use exactly the same syntax as sed, those scripts will break.

3. If we want to allow alternate regular expression functionality (case insensitive match comes to mind; sed does this with /regex/I) we should add new standard library function parameters, and build the sed command inside the function. This would allow us to replace sed without breaking existing scripts.

[hdwalters]

@Ph0enixKM wrote:

is there any way to tell sed that we will pass a regex string without these backslashes? Or to preprocess the string by replacing all the symbols like (, |, + etc. with ones added with prefix \\?

We have to escape those operators with basic regex support in sed; extended regex support can be enabled by passing true to the standard library function.

I don't think we should do any preprocessing on the string; we can't predict what various flavours of sed will do; and preprocessing will just confuse the issue. Any differences in sed support on different operating systems would be problems developers would have to resolve in native Bash scripts; I do not think it's up to us to fix that.

[hdwalters]

However, it occurs to me that we can support any hypothetical move away from sed for regular expressions in future, by renaming the standard library functions as match_sed and replace_sed now; that way we can write new functions later, using a different mechanism.

[Mte90]

So I removed the /../ now that stuff is internal, just the ending symbol is something that is not mandatory in the regex.
I agree to that in the future we can have different regex functions but right now is too much.

[hdwalters]

See above for reasons why it's still recommended to use if output != "".

[hdwalters]

Looks good thanks!

Done