bugfindutils - Bugs: bug #42501, Add -E option for FreeBSD/Mac OSX...


bug #42501: Add -E option for FreeBSD/Mac OSX compatibility

Submitter:  None
Submitted:  Tue 03 Jun 2014 06:32:14 PM UTC
Category:  find Severity:  1 - Wish
Item Group:  None Status:  Need Info
Privacy:  Public Assigned to:  jay
Originator Name:  Chris Bojarski Originator Email:  -email is unavailable-
Open/Closed:  Open Release:  None
Fixed Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Wed 03 Nov 2021 05:25:17 PM UTC, comment #4: 

I would also love to see -E added to GNU find.

comment #3:

> I'm happy to implement this option as long as we can nail down which regex dialect -E should select.   Is there any chance you could provide more detail on your answer to question 1, perhaps by performing some experiments?

That should be equivalent to -regextype posix-extended

The idea is that it makes it consistent with grep -E, sed -E, etc.

Note that BSD find -regex, without -E, expects POSIX basic regexps like grep or sed, while GNU find expects some ancient form of emacs regexps. Those can't be reconciliated at the moment.

Some implementations of sed and grep (namely the ast-open one) support -G / --basic-regexp to explicitly request basic regexps.

So maybe we could convince the maintainers of GNU and BSD find to support that -G as well to enable basic regex.

-P, for perl-like regexps (for instance via pcre) would also be welcome as they've become the new de-facto standard for regexps these days.

Stephane Chazelas <stephanechazelas>
Sun 01 Sep 2019 07:55:59 AM UTC, comment #3: 

I'm happy to implement this option as long as we can nail down which regex dialect -E should select.   Is there any chance you could provide more detail on your answer to question 1, perhaps by performing some experiments?

James Youngman <jay>
Group administrator
Wed 04 Jun 2014 08:27:55 PM UTC, comment #2: 

1. The FreeBSD man page for find points to re_format as its regex interpreter. On that page, it describes its modern regular expressions (REs) as being "as defined in IEEE Std 1003.2 (``POSIX.2'') ... roughly those of egrep(1); 1003.2 calls these ``extended'' REs." Now, I know GNU find has posix-egrep and posix-extended. I'm not sure which most closely matches the FreeBSD behavior, but it seems like it's definitely one of those two (assuming I understand those choices correctly).

2. The solution we came to on the script I was working on was to pipe the results through egrep. This ended up being sufficiently performant as we do not have a deep directory structure and we had -maxdepth set anyway. Between find and grep, though, were a call to basename and sort, which could become bottlenecks if they have to process a lot of paths that would later be filtered anyway. The current options are functional, but less elegant than using the tools already built into find (just not accessible cross-platform), and potentially affecting performance in long process chains. The idea would be that eventually, old versions would fall off, and we could update to using the new flag once we were confident that the new versions had enough adoption. This is, admittedly, a very long-term view.

I can't say I have had a lot of experience dealing with cross-platform compatibility with a utility like this (I am only contributing to the aforementioned script on the side), so I'm not sure what would be the best route to take dealing with the various versions. Beyond using egrep as a stopgap, I suppose one could do version checking on the installed find, but I have a feeling this is as inelegant as it sounds.

Chris Bojarski <cbojar>
Wed 04 Jun 2014 12:45:54 PM UTC, comment #1: 

This sounds useful.   I have two questions.   The first is about the intended behaviour of -E and the second is about the portability aspect.

1. The interpretation of posix-egrep is documented accurately in the Texinfo manual for find (accurate because the documentation is generated automatically from the controlling regex dialect bitmask value).    Could you check in detail to make sure that FreeBSD's interpretation of -E really does yield the same regex dialect?   I ask this because the only thing worse for portability than not offering the same option is to offer the same option with very subtle differences in behaviour...

2. If this flag is implemented you will have (at least) three versions of find to worry about: 1. FreeBSD grep, which supports -E.   2. New versions of NGU find, likewise.   3. Older versions of GNU find, which don't.   What is your plan for cross-platform searching in this situation?

James Youngman <jay>
Group administrator
Tue 03 Jun 2014 06:32:14 PM UTC, original submission:  

I was working on a script recently that required cross-platform regular expression filtering. On Linux, the -regextype posix-egrep works like a charm, but this option is not cross-platform. On FreeBSD and Mac OSX, there is a -E option that looks equivalent to -regextype posix-egrep. I was hoping it might be possible to add a -E option that aliases to -regextype posix-egrep so that the same functionality can be used across different implementations.



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by stephanechazelas (Posted a comment)
  • -email is unavailable- added by cbojar (Posted a comment)
  • -email is unavailable- added by jay (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-09-01 jay StatusNone Need Info
    2014-06-04 jay Severity3 - Normal 1 - Wish
        Assigned toNone jay

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code