Community

There are actually two questions I need some clarification on, but let's try the bit that doesn't work first...

I need to "pretty" up some hexadecimal numbers in ASCII form in a very long file (20,000 lines). The lines are in standard text format, this isn't some wierd hex editing question (I hope!).

So what I'm trying to do is convert the raw DDT hex numbers (like "FFFE") to compiler-friendly hex numbers ("0FFFEH"). Basically, I need to add a "H" suffix to all such numbers, and I need to add a prefix if (and only if!) the hex number starts with A/B/C/D/E/F.

All such numbers appear as ONLY 2 or 4-digit numbers, and ALWAYS at the end of the line, so the $ appears to be a great anchor point.

I've tried using the [:xdigit:] regexp (posix mode off), but it doesn't seem to work as expected - if I try to match a single hex digit, with the pattern: - and that's the entire expression I'm searching for - by way of example, it matches the "X" in every LXI instruction, as well as the "normal" hex digits (0-9, A-F)!!!

Because of this behaviour, I can't trust it to find and prepend/append the necessary characters - because it seems to match X's as well, it also matches L's in HL, etc, so it incorrectly matches non-hex numbers and digits.

And whenever I try to use count patterns (like looking for only 2 or 4-digit hex numbers so registers like a,b,c,d,e and f don't get modified), the search seems to fail. So, for example if I use the following search pattern: Textpad tells me no such patterns matched! I realise that the count specifiers means 2,3,or 4 hex digits, but since there are no 3-digit numbers, I thought I would be safe).
Here's a sample of the code I'm searching: [EDIT] I'm sorry, I didn't put an example of what I'd like to see... Here's what I need to have happen to that example code:
I hope that helps clarify what I'm trying to do and failing...
[/EDIT]

Now, when I search for : Textpad tells me there are no matches (there are 4 such patterns)
and if I try to be less restrictive, using , Textpad matches the XI in the last line of the example, but it doesn't match any of the hex patterns. In fact, it matches D,I,G and T (I've played around some more and verified this behaviour)

So, what am I doing wrong?

The next question is, can anyone help with the replacement pattern to use so that I can prepend AND append the 0 and H to the matching patterns?

I realise this is a big ask, but the behaviour is bizarre, and I'm at the end of my wits (I have abnormally small wits).

Thanks in advance!

This only takes care of part of it for you:

Search for: ([0-9]{2})\n
Replace with: \1H\n

Use the following settings:
-----------------------------------------
[X] Regular expression
Replace All
-----------------------------------------
Configure | Preferences | Editor
[X] Use POSIX regular expression syntax
-----------------------------------------

This only handles the lines where the last two characters on the line are digits. Need to refine it to find other conditions. I need to leave now, but this may get you started....

You haven't got enough brackets. The regular expression [:xdigit:] matches any one of the characters: :, x, d, i, g, i, t or :. You need to use the character class [[:xdigit:]]. Look in TextPad's help under Reference Information | Regular Expressions, under Class Expressions.

Alternatively, you could use the simpler [0-9a-f].

You can do what you want in two steps:

(1) to append the suffix H:

Find what: \<[0-9a-f]{2}[0-9a-f]{2}?$
Replace with: \0H

[X] Regular expression

Replace All

And then, (2) to append the prefix 0:

Find what: \<([a-f][0-9a-f])[0-9a-f]{2}?H$
Replace with: 0\0

[X] Regular expression

Replace All

These assume you are using Posix regular expression syntax:

Configure | Preferences | Editor

[X] Use POSIX regular expression syntax

Thanks so much guys, I was kind of on the right track once I figured the character class business, but I still couldn't figure out the prepend bit at all.

In fact Ben's second regexp doesn't actually work once the first is applied. The workaround there was to apply the prefix first, then ignore the prefix and apply the suffix. And that didn't work with the prefixed string "0FF", presumably because the count couldn't match the 3-character string. But all others seem to have been converted.

It's such a pity regexps are so complex. I've been dealing with them on and off since SCO unix days, and they just plain scare me. I guess if I applied half the effort to understanding them as I did to learning shell, batch, and language syntaxes (syntaxii?), I'd have a lot more power at my fingertips. And having come from a major wordstar background, with such limited search and replace options, doesn't help either - I know regexps are hugely flexible and powerful, but it's like getting behind the wheel of an F1 car to go to the shops...

Thanks again for your help, it's very much appreciated. Now, back to my TTY...

PCPete wrote:In fact Ben's second regexp doesn't actually work once the first is applied.

Try again. It does work.

You're right Ben, my apologies. I tried it again on a local copy and this time it does work perfectly. I'm not sure what happened, but it was probably me again. I even did some screendumps in case I'd buggered something up - yesterday, didn't work, today, it did.

Thanks again for such a patient response.

If you copied the regular expression from this web page a spurious space may well have been stuck on the end.

I've just carefully (!!) checked the regexp in the history list, and you're absolutely right - a space got tacked on the end. Today, I hand wrote the expression, that's why it worked today. That's one of the problems with high-res screens with too-small font sizes in the dialogs! (Well, that and my stupidity )