expr(1): Add -E flag to interpret regular expressions as EREs

[kevans]

Summary

By popular demand, add an -E flag to expr(1) to interpret
regular expressions as EREs. This allows for some cleaner expressions
given the branching feature using convention established by sed(1)/grep(1).

It should be mentioned that use of -E is not POSIX compliant, and probably not portable
to other implementations. Most notably, GNU expr(1) does not implement an -E flag. The
man page has been updated to reflect this information.

As an aside, this seems to be generally an OK change to make. posix.1-2008 explicitly
permits implementations to extend utilities.

Test Plan

Run kyua test suite, check that the following holds true:

$ expr -E 'test.png' : '.*\.(xpm|svg|png)$'
png

[kevans]

I should probably also mention that POSIX does not have any arguments against using EREs in expr(1), just the obvious argument against using EREs in expr(1). See: IEEE 1003.1-2008 [1]'s RATIONALE section on the expr(1) page.

[1] http://pubs.opengroup.org/onlinepubs/9699919799/

[cem]

Is there actually popular demand for this? Anyway, the change looks good.

bin/expr/expr.y

44

No need for = 0 for globals — they are zero initialized by definition. (See nonposix right below.)

[kevans]

In D11317#234755, @cem wrote:

Is there actually popular demand for this? Anyway, the change looks good.

Alright, 'popular' might have been a little bit of a stretch. There was at least a demand for it, though.

[jilles]

The code change by itself looks good (including all the reasoning about which extensions POSIX permits) but I would prefer not to encourage more use of expr(1) :(

[kevans]

• Consistently order -E, then -e in instances it appears
• Globals don't need to be explicitly initialized to 0

[kevans]

In D11317#247796, @jilles wrote:

The code change by itself looks good (including all the reasoning about which extensions POSIX permits) but I would prefer not to encourage more use of expr(1) :(

I understand where you're coming from, but it does still have its applications in some environments. I don't think it necessarily hurts to have one more possibility for solving expr(1)'s class of problems, particularly if it ends up in a more limited environment where the equivalent shell features may not be available. I do realize that's a shaky argument since we're dealing with the base system context and not these other contexts, but I think this feature offers low enough overhead that it's worth considering.

[bcr]

OK from manpages. Bump the document date (.Dd) when you're committing the file.

[emaste]

I think this is fine.

[otis]

Functionally OK.

[pstef]

Consider adding a cross reference to re_format.