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:  Code Review
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
   

Jump to the original submission

Tue 04 Jun 2024 06:30:36 AM UTC, comment #9: 

I realise I didn't really answer the question of which release -E came in in those.

For FreeBSD and NetBSD, that would be their respective 5.0 version even if they're many years apart.

For MacOS/X I don't know exactly, but https://github.com/NetBSD/src/blob/trunk/share/misc/bsd-family-tree suggests that could be 10.3 which is meant to have synced with FreeBSD 5.1

DragonFly BSD from the start (2003), I've not checked any other FreeBSD derivative (https://en.wikipedia.org/wiki/Comparison_of_BSD_operating_systems#FreeBSD).

OpenBSD's find doesn't have -E, I've not checked any of its derivatives (like MirBSD).


Stephane Chazelas <stephanechazelas>
Mon 03 Jun 2024 06:04:40 AM UTC, comment #8: 

Oh sorry missed one: and then NetBSD added -E in:

commit c43efbc1770febb15e4e1cac194fc14195dc3bba
Author: daniel <daniel@NetBSD.org>
Date:   Thu Jul 19 07:49:30 2007 +0000

    Add the '-E' option to interpret regexes as extended regexes. While we
    are here, fix ordering in usage information by putting '-X' in the proper
    place.

    Addition of '-E' was discussed on tech-userlevel.

Stephane Chazelas <stephanechazelas>
Mon 03 Jun 2024 06:03:36 AM UTC, comment #7: 

Chronologically:

-regex added first to NetBSD (inspired from GNU's) in:

commit 5ddc160e898d16e1f981c5f3f7c8aa41db732ac4
Author: cgd <cgd@NetBSD.org>
Date:   Tue Jul 20 01:28:41 1999 +0000

    add -regex and -iregex primaries which, like GNU find's primaries of the
    same name, match files' entire paths against regular expressions.
    -regex is case sensitive, -iregex is case-insensitive.  Note that these
    primaries are not entirely compatible with the GNU find primaries,
    because their BREs appear to support alternation with \| whereas our BREs
    do not.  Also note there are no primaries which provide extended regular
    expressions matching, though if they are desired they would be trivial
    to implement.


FreeBSD added all of -E -regex -i{name,path,regex} at the same time in:

commit 7c1d4b3ae901ee2c7a3537b10db787464fb26df0
Author: Akinori MUSHA <knu@FreeBSD.org>
Date:   Fri Feb 23 16:20:55 2001 +0000

    Implement the following options and primaries:

         -E      Interpret regular expressions followed by -regex and -iregex op-
                 tions as extended (modern) regular expressions rather than basic
                 regular expressions (BRE's).  The re_format(7) manual page fully
                 describes both formats.

         -iname pattern
                 Like -name, but the match is case insensitive.

         -ipath pattern
                 Like -path, but the match is case insensitive.

         -regex pattern
                 True if the whole path of the file matches pattern using regular
                 expression.  To match a file named ``./foo/xyzzy'', you can use
                 the regular expression ``.*/[xyz]*'' or ``.*/foo/.*'', but not
                 ``xyzzy'' or ``/foo/''.

         -iregex pattern
                 Like -regex, but the match is case insensitive.

    These are meant to be compatible with other find(1) implementations
    such as GNU's or NetBSD's except regexp library differences.

    Reviewed by:    sobomax, dcs, and some other people on -current



Stephane Chazelas <stephanechazelas>
Sun 02 Jun 2024 09:52:03 AM UTC, comment #6: 

Chris, could you please determine which releases of FreeBSD and Mac OS X introduced this option?   I would like to mention this in the sections of the documentation which deal with compatibility.

James Youngman <jay>
Group administrator
Sun 02 Jun 2024 09:48:04 AM UTC, comment #5: 

This option is implemented by the attached patch.  I haven't pushed this patch yet.


(file #56126)

James Youngman <jay>
Group administrator
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.

Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files

 

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 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-06-02 jay Attached File- Added 0001-Add-E-option-selecting-POSIX-Extended-regex-syntax.patch, #56126
        StatusNone Code Review
    2024-05-26 jay StatusNeed Info None
    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-3e34.
    Corresponding source code