[LDM #SXQ-866293]: LDM 6 bug?

Hey Gilbert,

> My name is Gilbert. My job is to torture you with finding new LDM bugs and
> then making you not send me any Christmas cards as a result. ;-)
> 
> OK, OK, seriously...it looks like I found another. First, the proof of
> concept. Doing a cut-and paste from my pqact on the following (tabs are
> eliminated in the cut and paste, but they are there in the pqact):
> 
> NEXRAD  ^SDUS5. .... ([0-3][0-9])([0-2][0-9])([0-5][0-9]).*/p(N0R)(...)
> FILE    /home/data/wsr88d/\5/(\1:yy)(\1:mm)\1\2\3.bref1
> 
> yields this filename (as an example):
> 
> 0703280302.bref1
> 
> Cool! That's the way it should be.
> 
> But when I do this:
> 
> NEXRAD  ^SDUS5. (KLOT|KDVN|KIWX|KLSX|KDMX|KMKX|KILX) 
> ([0-3][0-9])([0-2][0-9])([0-5][0-9]).*/p(N0V)(...)
> FILE    /home/data/wsr88d/\5/(\1:yy)(\1:mm)\1\2\3.vel1

The backreference "\1" in the above refers to the first
parenthetical substring, which is whatever matched the
extended regular expression "(KLOT|KDVN|KIWX|KLSX|KDMX|KMKX|KILX)".
Using this substring as the day-of-month in a string replacement
expression probably doesn't do what you want.  For the
above, you probably want to use the backreference "\2" (and
also increment all the other backreferences as well).

> I get...NOTHING!
> 
> No file saved anywhere. But here's the kicker: it used to work. When did
> it stopped working? Well, with all the LDM upgrades I didn't check to see
> if my storm relative velocity images were working. But, I do know this: it
> happened on January 30, 2007. OK, somewhere in there LDM 6.5 came out and
> I slapped it on my machine.
> 
> Any clues? It could very well be on my end, but...I don't see anything and
> that entry has been there for a few years and working with no problem.

OK?

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: SXQ-866293
Department: Support LDM
Priority: Normal
Status: Closed