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/