On 2023-03-02 14:23, Clem Cole wrote: Clem, why are you linking through streaklinks.com? N.

On 3/2/23 4:01 PM, Stuff Received wrote: Here's a direct link to the page that I landed on when following Clem's link: Link - Implementing Regular Expressions - https://swtch.com/~rsc/regexp/ I didn't pay attention to Clem's link beyond the fact that I got to the desired page without needing to tilt at my various filtering plugins. Though the message I'm replying to has caused a few brain cells to find themselves in confusion ~> curiosity. -- Grant. . . . unix || die

On 3/2/23 7:10 PM, Dave Horsfall wrote: I absolutely agree. The confusion was why someone would purposefully choose to use a redirector. -- Grant. . . . unix || die

On 3/2/23 2:53 PM, Dan Cross wrote: I completely agree with you. That's also why I'm wanting to start utilizing the latter, more specific RE. But I don't know where the line of over complicating things is to avoid crossing it. Yes and no. Does the comment above clarify at all? Yes. What constitutes a single string? ;-) I sort of rhetorically ask. The log lines start with MMM dd hh:mm:ss Where: - MMM is the month abbreviation - dd is the day of the month - hh is the hour of the day - mm is the minute of the hour - ss is the second of the minute So, yes, there are eleven characters that fall into the class consisting of a space or a colon or a number. Is that a single string? It depends what you're looking at, the sequences of non white space in the log? No. The patter that I'm matching ya. Agreed. I'm starting with the examples that came with; "^\w{3} [ :[:digit:]]{11}", the logcheck package that I'm working with and evaluating what I want to do. I actually like the idea of dividing out the following: - months that have 31 days: Jan, Mar, May, Jul, Aug, Oct, and Dec - months that have 30 days: Apr, Jun, Sep, Nov - month that have 28/29 days: Feb Aside: Why do you have the double square brackets in "[12][[0-9]]"? ACK "[[:digit:]]+" was a construct that I'm parroting. It and [.:[:xdigit:]]+ are good for some things. But they definitely aren't the best for all things. Hence trying to find the line of being more accurate without going too far. Given the context that these extended regular expressions are going to be used in, logcheck -- filtering out known okay log entries to email what doesn't get filtered -- I'm okay with having a few things slip through like leap day / leap seconds / leap frogs. I hear, understand, and acknowledge your concern. At present, these filters are being used in a package; logcheck, which I believe is specific to Debian and ilk. As such, GNU grep is very much a thing. I'm also not a fan of the use of `\w` and would prefer to (...|...) things. I only vaguely understand those three paragraphs as they are deeper computer science than I've gone before. I think I get the gist of them but could not explain them if my life depended upon it. ACK It sounds like I can make any reasonable extended regular expression a human can read and I'll probably be good. Thank you for the detailed response Dan. :-) -- Grant. . . . unix || die

On 3/2/23 8:04 PM, Dan Cross wrote: ACK You got it. Fair enough. That's also sort of what I thought might be the case. *nod* Yep, I'm well aware of the that. That's one of the reasons that I'm interested in coming up with a more precise regular expression ... without being overly complex. Yep. Here's an example of the full RE: ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ postfix/msa/smtpd\[[[:digit:]]+\]: timeout after STARTTLS from [._[:alnum:]-]+\[[.:[:xdigit:]]+\]$ As you can see the "[ :[:digit:]]{11}" is actually only a sub-part of a larger RE and there is bounding & delimiting around the subpart. This is to match a standard message from postfix via standard SYSLOG. Yep. Though said domain knowledge isn't anything special in and of itself. Yep. logcheck makes extensive use of many files like this to do it's work. ACKK Thank you for the logic CRC. Um ... that's concerning. Fair enough. My use case is on Linux where GNU egrep is a thing. I think that `\w` is a good primer, but not where I want things to end up long term. I /think/ that I could build a complex nested tree of switch statements to test each character to see if things match what they should or not. Though I would need at least one variable / memory to hold absolutely minimal state to know where I am in the switch tree. I think a number to identify the switch statement in question would be sufficient. So I'm guessing two bytes of variable and uncounted bytes of program code. Thank you again Dan. :-) -- Grant. . . . unix || die

On 3/3/23 6:47 AM, Dan Cross wrote: Good. For a moment I thought that you might be thinking it was stand alone. :-) ACK I've heard "domain (specific) knowledge" used to refer to both extremely specific training in a field and -- as you have -- data that is having something done to it. They darned well had better not. ACK I think I understand the gist of what you're saying, but I need to re-read it and think about it a little bit. Apology returned to sender as unnecessary. You are providing the requested thought provoking discussion, which is exactly what I asked for. I feel like I'm going to walk away from this thread wiser based on the thread's content plus all additional reading material on top of the thread itself. Thank you (again) Dan. :-) -- Grant. . . . unix || die

On Fri, Mar 3, 2023 at 5:59 AM Ralph Corderoy <ralph(a)inputplus.co.uk> wrote: I'm afraid I must sound a note of caution about Friedl's book. Russ Cox alludes to some of the problems in the "History and References" section of his page (https://swtch.com/~rsc/regexp/regexp1.html) that was linked earlier, and he links to this post: http://regex.info/blog/2006-09-15/248 The impression is that Friedl shows wonderfully how to _use_ regular expressions, but does not understand the theory behind their implementation. It is certainly true that today what many people refer to as "regular expressions" are not in fact regular (and require a pushdown automata to implement, putting them somewhere between REs and the context-free languages in terms of expressiveness). Personally, I'd stick with Russ's stuff, especially as `egrep` is the target here. - Dan C.

On 3/3/23 6:42 AM, Ralph Corderoy wrote: You are mostly correct. The motivation for this thread is very much so wanting to learn "how best to use today's regular expression implementations". However there is also the part of me that wants to have a little bit of understanding behind why the former is the case. It seems like I need to find another copy of Friedl's book. -- My current copy is boxed up for a move nearly 1k miles away. :-/ It sounds like I'm coming from a similar position of "what is the best* way to process this corpus" more than "what is the underlying theory behind what I'm wanting to do". :-) I'm learning that I'm more of a technician that wants to know how to use the existing tools to the best of his / their ability. While having some interest in theory behind things. Yep. That's the position that I would be in if someone were paying me to write the REs that I'm writing. This all sounds interesting to me, and like something I might add to my collection of books. But it also sounds like something that will be an up hill read and vast learning opportunity. Yep. Even inventorying and keeping track of the books can be time consuming. -- Thankfully I took some time to do exactly that and have access to that information on the super computer in my pocket. -- Grant. . . . unix || die

On Sat, Mar 04, 2023 at 10:15:33AM +0000, Ralph Corderoy wrote: My own recommendation for this is to get a dedicated ebook reader. It will feel a bit clumsy to have both a cretinphone and another thing with you, but at least the thing is doing the job. At least, mine keeps cropping across pages. Also, the e-ink/epaper display of ebook reader is not supposed to screw your eyes and/or circadian rhythms (not that I know anything specific, but I find it very strange that people shine blue light into their eyes for extended periods of time and do not even quietly protest - well, perhaps it is akin to what goes between human and a dog, they become alike to each other, now, when a human has cretinphone...). Or, if it just one pdf to read, then you should be fine reading it on bigger screen. HTH -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola@bigfoot.com **

On Sat, 4 Mar 2023, Ralph Corderoy wrote: Sorry for responding to an old thread got behind on my list-mail reading, but I wanted to share my $.02. Someone else mentioned an e-book reader app, and I second that, mostly...Moon+ Reader on Android is the e-book reader I've been using for a while and it does a good job with standard e-book formats as well as PDF files, IF the PDF is a PDF of formatted text. It even has a mode where it will do a pretty decent job of on-the-fly converting/reformatting the text of the PDF to something that can actually be read on a small (phone) screen. However, if the PDF is just a bunch of 1 image per page wrapped in a PDF container, you're out of luck and back to zoom/pan around the page. For most of my digtal book reading these days, I use a Boox e-ink reader. It runs Android, so, I can use the same e-book reader I used on my phone. It can even sync where you're at in the book/document via dropbox and you can move between multiple devices if needed. If I want to mark-up the PDF, the built-in stuff on the Boox handles that nicely. If I'm on my phone, I use an app called Xodo. -- Michael Parson Pflugerville, TX

On Tue, 20 Jun 2023, Tomasz Rola wrote: <snip> (For the record, the "device" I'm discussing is my Boox Nova Air 7.8" E Ink tablet, Amazon product B09FQ14Z6N.) What are you wanting/needing an SD card for? Extra storage? File-transfer? For what I use this device for, the built-in storage (32GB) has been more than enough to hold the books & notes I need it to. For file transfer, the USB Type-C port on it goes both ways, you can connect it to a computer and move files that way, or you can get a Type-C SD card reader. Plus there's wifi for network transfers. I store my e-books in Calibre on my Linux desktop, which has a web-server that the software on the device knows how to talk to, or I can connect the device and my Linux box together over USB and Calibre recognizes it as an e-reader device and can push/pull books via its interface. This device does not advertise any water-proofing at all. Out of the box, this device has very aggressive power-saving modes. If the screen is left off for more than something like 10 minutes, it would do a full shutdown, which means the next time you hit the power button, it does a full boot. To be fair, it boots much faster than my phone, about 15 seconds from hitting the power button to asking me to unlock the screen. Default settings also turn off the wifi & bluetooth when the screen is off. In this mode, yeah, it will last a few weeks. I disabled the shutdown bits, I want to have that "instant on" experience. Well, as instant as things get with E-Ink. From what I've noticed, the biggest battery drain seems to be if I use the backlight or not. I mostly don't, but it's there when other light isn't available. With my usage patterns and device settings, I probably charge it up to full once or twice a week, but that's plugging it in when it gets to about 50% battery. If I left the wifi off, I could probably extend it even more. To be completely honest, I've not worried too much about how long things keep a charge, as long as it can stay charged long enough for me to use it for what I want to do with it. I have lots of USB chargers spread around my house, which means that I can tend to have something charging and still be nearby. The exception to this is my watch. I have a Fossil Hybrid smart-watch. It's an analog watch with an e-ink background that can show me alerts/info from my phone. It only needs to be charged about once every 10 days or so. I don't want a watch that I'd have to recharge daily. I don't do a lot of web browsing on the device, but when I do, it's using firefox, not the vendor-provided browser. I'm all-in on the FF ecosystem, have an FF account, all my systems have their browsers logged into my FF account, I can send tabs between devices/desktops/laptops easily, etc. I'm sure the same can be done with Chrome. Firefox on Android also has a "Desktop site" slider that will re-render the page like a desktop browser would instead of a mobile one. This is nice on bigger screen Android devices. That being said. The latest update to the firmware on this device has added per-app E-ink refresh settings. So, for reading books in the book-reader app, I have it set on one of the higher-quality, but slower refresh modes. I read my books like books, page at a time, generally little to no scrolling. This is harder to do when browsing the web, so, I have Firefox set to the lower-quality but faster refresh mode. Yeah, there is a little ghosting after the scrolling stops, but it's more like the faint bleed-through you get when reading a newspaper. I mostly only deal with epub, mobi, and PDF. The blurb on Amazon says that it handles "PDF(reflowable), PPT, EPUB, TXT, DJVU, HTML, RTF, FB2, DOC, MOBI, CHM..." Yup, this device has BT as well, since being an Android device, you can listen to MP3s, or stream from Pandora/Spotify/etc. I've never set that up on here, I have other devices that can already do that. The only BT I've hooked up is a keyboard, and that was mostly for a bit of fun. I installed an ssh-client on there and spent a few hours logged into my Linux box reading email. I still kinda want a laptop with an e-ink display. The other thing I use this device for is for hand-written notes and sketches. Writing on the screen with the stylus feels a lot like writing with a pencil on paper. I'm not an artist by any stretch, but sometimes writing things out and using boxes, circles, helps sort things out in my head, or sometimes I'll sketch things out while working on a design I eventually want to 3d print. All stuff I'd historically done in a paper notebook, but now I have similarly-sized electronic notepad where I can erase mistakes, have layers to my drawings (like photoshop/gimp/etc), zoom in/out, etc. The notepad app is also linked to my DropBox account, so when I'm done with whatever doodles/notes/sketches, I can then load them up on one of my other systems as PDFs. I've even toyed with the idea of writing letters out in long-hand in the notepad and then emailing the resulting PDFs to people, since the practice of hand-written letters has gone by the wayside, I thought this would be an entertaining way to bring that back. :) If what you're looking for is an E-reader that can also do the note-taking (Or a note-taking device that also functions as an e-reader), and not really much else, I've heard good things about the Remarkable tablets. One of the things they advertise is it being a distraction-free device, no alerts from the socials medias, emails, etc, since the device flat doesn't do those things. I've never used one, but I've seen people at my $DAYJOB say they really like theirs. I'm not saying this is the perfect device, or that it will fill the needs of anyone else. It doesn't solve every need I have either, which is why I have multiple devices (phone, this e-reader tablet, personal laptop, work laptop, personal desktop, scattered Raspberry Pis, etc). -- Michael Parson Pflugerville, TX

On Fri, 3 Mar 2023, Ralph Corderoy wrote: I can't help but provide an extract from my antispam log summariser (AWK): # Yes, I have a warped sense of humour here. /^[JFMAMJJASOND][aeapauuuecoc][nbrrynlgptvc] [ 0123][0-9] / \ { date = sprintf("%4d/%.2d/%.2d", year, months[substr($0, 1, 3)], substr($0, 5, 2)) Etc. The idea is not to validate so much as to grab a line of interest to me and extract the bits that I want. In this case I trust the source (the Sendmail log), but of course that is not always the case... When doing things like this, you need to ask yourself at least the following questions: 1) What exactly am I trying to do? This is fairly important :-) 2) Can I trust the data? Bobby Tables, Reflections on Trusting Trust... 3) Etc. And let's not get started on the difference betwixt "trusted" and "trustworthy" (that distinction keeps security bods awake at night). -- Dave

Hi, ... Some clients pay me to read code and find fault. It's a hard habit to break. ‘coc’ smells wrong. :-) A bit of vi's :map later... Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dcc The regexp works, of course, but in this case removing the redundancy would also fix the ‘fault’. -- Cheers, Ralph.

On 3/3/23 9:12 AM, Dave Horsfall wrote: Thank you for sharing that Dave. Fair enough. Using bracket expressions for the three letters is definitely another idea that I hadn't considered. But I believe I like what I think is -- what I'm going to describe as -- the more precise alternation listing out each month. (Jan|Feb|Mar... Such an alternation is not going to match Jer like the three bracket expressions will. I also believe that the alternation will be easier to maintain in the future. Especially by someone other than me that has less experience with REs. I trust that syslog will produce consistent line beginnings more than I trust the data that is provided to syslog. But I'd still like to be able to detect "Jer" or "Dot" if syslog ever tosses it's cookies. Filter out known to be okay log entries. Given that I'm effectively negating things and filtering out log entries that I want to not see (because they are okay) I'm comfortable with trusting the data from syslog. Brown M&Ms come to mind. ACK -- Grant. . . . unix || die

Hi Grant, You could measure the number of CPU instructions and experiment. $ echo xyzaaa aaaxyz >f $ ticks() { LC_ALL=C perf stat -e instructions egrep "$@"; } $ $ ticks '(aaa|bbb) \1' <f xyzaaa aaaxyz Performance counter stats for 'egrep (aaa|bbb) \1': 2790889 instructions:u 0.009146904 seconds time elapsed 0.009178000 seconds user 0.000000000 seconds sys $ Bear in mind that egreps differ, even within GNU egrep, say, over time. $ LC_ALL=C perf stat -e instructions egrep '(aaa|bbb) \1' f xyzaaa aaaxyz ... 2795836 instructions:u ... $ LC_ALL=C perf stat -e instructions perl -ne '/(aaa|bbb) \1/ and print' f xyzaaa aaaxyz ... 2563488 instructions:u ... $ LC_ALL=C perf stat -e instructions sed -nr '/(aaa|bbb) \1/p' f xyzaaa aaaxyz ... 610213 instructions:u ... $ -- Cheers, Ralph.

On Mon, Mar 6, 2023 at 5:02 AM Ed Bradford &lt;egbegb2(a)gmail.com&gt; wrote: This reminds me of something that I wanted to bring up. Perhaps one _could_ define a sufficiently rich regular expression that one could match a number of date formats. However, I submit that one _should not_. REs may be sufficiently powerful, but in all likelihood what you'll end up with is an unreadable mess; it's like people who abuse `sed` or whatever to execute complex, general purpose programs: yeah, it's a clever hack, but that doesn't mean you should do it. Pick the right tool for the job. REs are a powerful tool, but they're not the right tool for _every_ job, and I'd argue that once you hit a threshold of complexity that'll be mostly self-evident, it's time to move on to something else. As for large vs small REs.... When we start talking about differences of orders of magnitude in size, we start talking about real performance implications; in general an NDFA simulation of a regular expression will have on the order of the length of the RE in states, so when the length of the RE is half a million symbols, that's half-a-million states, which practically speaking is a pretty big number, even though it's bounded is still a pretty big number, and even on modern CPUs. I wouldn't want to poke that bear. - Dan C.

On Mon, Mar 06, 2023 at 04:01:51PM -0500, Dan Cross wrote: Dan, I agree with you. I ran a software company for almost 20 years and the main thing I contributed was "lets be dumb". Lets write code that is easy to read, easy to bug fix. Smart engineers love to be clever, they would be the folks that wrote those long RE that worked magic. But that magic was something they understood and nobody else did. Less is more. Less is easy to support.

Hi Ed, Readable to you, which is fine because you're the prime future reader. But it's less readable than the regexp to those that know and read them because of the indirection introduced by the variables. You've created your own little language of CAPITALS rather than the lingua franca of regexps. :-) Each time the original language was readable because practitioners had to read and write it. When its replacement came along, the old skill was no longer learnt and the language became ‘unreadable’. ‘{1}’ is redundant. I think we're missing something as the ‘'['’ is starting a character class which is odd for wrapping the month and the ‘{0,1)’ doesn't have matching brackets and is outside the string. BTW, ‘{0,1}’ is more readable to those who know regexps as ‘?’. It sounds like you're wanting a word boundary; something provided by regexps. In Python, it's ‘\b’. (<re.Match object; span=(16, 19), match='foo'>,) Are you aware of the /x modifier to a regexp which ignores internal whitespace, including linefeeds? This allows a large regexp to be split over lines. There's a comment syntax too. See https://docs.python.org/3/library/re.html#re.X GNU grep isn't too shabby at looking through binary files. I can't use /x with grep so in a bash script, I'd do it manually. \< and \> match the start and end of a word, a bit like Python's \b. re=' .?\< (19[0-9][0-9]|20[01][0-9]|202[0-3]) ( ([-:._]) (0[1-9]|1[0-2]) \3 (0[1-9]|[12][0-9]|3[01]) )? \>.? ' re=${re//$'\n'/} re=${re// /} printf '%s\n' 2001-04-01,1999_12_31 1944.03.01,1914! 2000-01.01 >big-binary-file LC_ALL=C grep -Eboa "$re" big-binary-file | sed -n l which gives 0:2001-04-01,$ 11:1999_12_31$ 22:1944.03.01,$ 33:1914!$ 39:2000-$ showing: - the byte offset within the file of each match, - along with the any before and after byte if it's not a \n and not already matched, just to show the word-boundary at work, - with any non-printables escaped into octal by sed. I'm sending this to just the list. Perhaps your account on the list is configured to not send you an email if it sees your address in the header's fields. -- Cheers, Ralph.

Thank you for the very useful comments. However, I disagree with you about the RE language. While I agree all RE experts don't need that, when I was hiring and gave some software to a new hire (whether an experienced programmer or a recent college grad) simply handing over huge RE's to my new hire was a daunting task to that person. I wrote that stuff that way to help remind me and anyone who might use the python program. I don't claim success. It does help me. When you say '{1}' is redundant, I think I did that to avoid any possibility of conflicts with the next string that is concatentated to the *Y_* (e.g. '*' or '+' or '{4,7}'). I am embarrassed I did not communicate that in the code. I had to think about it for a couple of hours before I recalled the "why". I will fix that. (it would be difficult to discuss this RE if I had to write "(19\d\d|20[01]\d|202" + "[0-" + lastYearRE + "]" + ") rather than just *Y_*). My initial thoughts on naming were I wanted the definition to be defined in exactly one place in the software. Python and the BTL folks told me to never use a constant in code. Always name it. Hence, I gave it a name. Each name might be used in multiple places. They might be imported. You are correct, the expression is unbalanced. I tried to remove the text2bytes(lastYearRE*)* call so the expression in this email was all text. I failed to remove the trailing *)* when I removed the call to text2bytes(). My hasty transcriptions might have produced similar errors in my email. Recall, my focus was on any file of any size. I'm on Windows 10 and an m1 MacBook. Python works on both. I don't have a Linux machine or enough desktop space to host one. I'm also mildly fed-up with virtual machines. Friedl taught me one thing. Most RE implementations are different. I'm trying to write a program that I could give to anyone and could reliably find a date (an RE) in any file. YYYY, MM, DD, HR, MI, SE, TH are words my user could use in the command line or in an options dialog. LAT and LON might also be possibilities. CST, EST, MST, PST, ... also. A 500 gigabyte archive or directory/folder of pictures and movies would be a great test target. I very much appreciate your comments. If this discussion is boring to others, I would be happy to take it to emails. I like your program. My experience with RE, grep, python, and sed suggests that anything but gnu grep and sed might not work due to the different implementations. I've been out of the Unix software business for 30 years after starting work at BTL in the 1970s and working on Version 6. I didn't know "printf" was now built into bash! That was a surprise. It's an incremental improvement, but doesn't compare with f-strings in python. *The interactive interpreter for python should have* *a "bash" mode?!* Does grep use a memory mapped file for its search, thereby avoiding all buffering boundaries? That too, would be new information to me. The additional complexity of dealing with buffering is more than annoying. Do you have any thoughts on how to verify a program that uses RE's. I've given no thought until now. My first thought for dates would be to write a separate module that simply searched through the file looking for 4 numbers in a row without using RE's, recording the offsets and 16 characters after and 1 character before in a python list of (offset,str) of tuples, ddddList, and using *dddd**List* as a proxy for the entire file. I could then aim my RE's at *ddddList*. *[A list of tuples in python* *is wonderful! !]* It seems to me '*' and '+' and {x,y} are the performance hogs in RE's. My RE's avoid them. One pass, I think, should suffice. What do you think? I haven't "archived" my 350 GB of pictures and movies, but one pass over all files therein ought to suffice, right? Two different programs that use different algorithms should be pretty good proof of correctness wouldn't you think? My RE's have no stars or pluses. If there is a mismatch before a match, give up and move on. On my Windows 10 machine, I have cygwin. Microsoft says my CPU doesn't have a TPM and the specific Intel Core I7 on my system is not supported so Windows 11 is not happening. Microsoft is DOS personified. (An unkind editorial remark about the low quality of software coming from Microsoft.) Anyway, I thank you again for your patience with me and your observations. I value your views and the other views I've seen here on coff(a)tuhs.org. I welcome all input to my education and will share all I have done so far with anyone who wants to collaborate, test, or is just curious. GOAL: run python program from an at-cost thumb drive that: reaps all media files from a user specified directory/folder tree and Adds files to the thumb drive. *Adds files* means Original file system is untouched Adds only unique files (hash codes are unique) Creates on the thumb drive a relative directory wherein the original file was found Prepends a "YYYY-MM-DD-" string to the filename if one can be found (EXIF is great shortcut). Copies srcroot/relative_path/oldfilename to thumbdrive/relative_path/YYYY-MM-DD-oldfilename or thumbdrive/relative_path/0000-oldfilename. Can also incrementally add new files by just scanning anywhere in any other computer file system or any other computer. Must work on Mac, Windows, and Linux What I have is a working prototype. It works on Mac and Windows. It doesn't do the date thing very well, and there are other shortcomings. I have delivered exactly one Christmas present to my favorite person in the world - a 400 GB SSD drive with all our pictures and media we have ever taken. The next things are to *add *more media and *re-unique-ify* (check) what is already present on the SSD drive and *improve the proper choice of "YYYY-MM-DD-" prefix* to filenames. I am retired and this is fun. I'm too old to want to get rich. Ed Bradford Pflugerville, TX egbegb2(a)gmail.com On Tue, Mar 7, 2023 at 5:40 AM Ralph Corderoy &lt;ralph(a)inputplus.co.uk&gt; wrote: -- Advice is judged by results, not by intentions. Cicero

Hi Dan, It could be the quickest way to express the intent. I think those two can overlap. :-) Why, if the grammar is type three in Chomsky's hierarchy, i.e. a regular grammar? I think sticking with code aimed at regular grammars, or more likely regexps, will do better than, say, a parser generator for a type-two context-free grammar. As well as the lex(1) family, there's Ragel as another example. http://www.colm.net/open-source/ragel/ Well, we're back to the RE v. regexp again. /^[0-9]+\.jpeg$/ is matched by some engines by first checking the last five bytes are ‘.jpeg’. $ debugperl -Dr -e \ ... Matching REx "^[0-9]+\.jpeg$" against "123546789012354678901235467890123546789012.jpg" Intuit: trying to determine minimum start position... doing 'check' fbm scan, [1..46] gave -1 Did not find floating substr ".jpeg"$... Match rejected by optimizer Freeing REx: "^[0-9]+\.jpeg$" $ Boyer-Moore string searching can be used. Common-subregexp-elimination can spot repetitive fragment of regexp and factor them into a single set of states along with pairing the route into them with the appropriate route out. The more regexp engines are optimised, the more benefit to the programmer from sticking to a regexp rather than, say, ad hoc parsing. The theory of REs is interesting and important, but regexps deviate from it ever more. -- Cheers, Ralph.

Hi Dan, It sounds to me like an "optimizer" is needed. There is alreay a compiler that uses FA's. Is someone else going to create a program to look for dates without using regular expressions? Today, I write small-sized RE's. If I write a giant RE, there is nothing preventing the owner of RE world to change how they are used. For instance. Compile your RE and a subroutine/function is produced that performs the RE search. RE is a *language*, not necessarily an implementation. At least that is my understanding. Ed On Mon, Mar 6, 2023 at 3:02 PM Dan Cross &lt;crossd(a)gmail.com&gt; wrote: -- Advice is judged by results, not by intentions. Cicero