Follow-up Comment #2, bug #42501 (project findutils):
1. The FreeBSD man page for find points to re_format
<http://www.freebsd.org/cgi/man.cgi?query=re_format&sektion=7> 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.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?42501>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
