There's value in having common expressions across platforms and environments. Witness the 'ifconfig' command Alan and company created years ago for VM TCP/IP. (Later regretting that it lacked '-a'.)
Often the common component is only a portion, but combining segments is trivial. Think outside the box. Rob's right about the origins. 'grep' has value where you can use it the same from one world to the another. As files get copied from system to system, there's a good case for 'grep'. World's with poorly defined message identifiers still need them, and sometimes eventually get them. The world where we got 'grep' also gave is 'awk' and 'sed' and 'xargs', all of which have counterparts (and better) in Pipelines, but with way different syntax. Common syntax is good, and I'd use a weaker stage just for compatibility. ... unless/until I could have He-Man pipes in other worlds. :-) -- R; <>< On Sun, Jan 23, 2022, 04:53 Rob van der Heij <[email protected]> wrote: > Diverting the thread ... > > On Fri, 21 Jan 2022 at 16:14, Dave Jones <[email protected]> wrote: > > > Hi, Peter. > > When I see a task like your's "need to check this message for either of > > the strings below", I think about using grep. Several versions of grep > > (egrep, fgrep, and ggrep) are supported by CMS Pipelines in the PIPSYSF > > package. If you would like to give it a try, grab it from here: > > http://vm.marist.edu/~pipeline/pipsysf.html > > The package also comes complete with some nice documentation. > > > > Of course, I expect to see Sir Rob pointing out that the lookup stage > > can be used as well in this thread soon. ;-) > > Good luck. > > DJ > > > > Dave, I understand and appreciate your persistence to have the good parts > of PIPSYSF in the main pipeline, but I don't think grep c.s. are the way > here. > > I think the habit of grepping messages has its roots in a world without > well-defined message identifiers where you try to match some of the phrases > and retrieve the actual values in the process. In our case, most messages > have a message identifier and let you dismiss or divert them. That's a very > simple word lookup. It also means you don't miss any new important messages > because they look like something mundane. > > Both LOOKUP and GREP have an initial cost, either to sort the references or > to compile a string matching algorithm. That's normally a waste if you only > need to parse a single message. If you use PROP, then you'd have routing > table entries for the most popular ones, and invoke some generic catch-all > routine for the ones you didn't expect (if you don't want to simply pass > them to the logical operator). > > Now I wouldn't be surprised if PROP uses a very simple approach to test a > message against the routing table (and we used to put the most frequent > ones at the top for that reason) but I likely would write a pipe-based one > instead using LOOKUP and DEAL to pass messages through a pipeline refinery. > > PS I think if we want GREP and friends in CMS Pipelines, we also want to > have something to extract the parsed phrases. Simply knowing that it > matched your search pattern is probably not enough to do something useful > with it. > > Rob >
