Yesterday. Gotta grep those logs.

At least once every few days while coding, usually to do one of the following:

1. Select multiple things in the same file at the same time without needing to click all over the place

   Normally I use multicursor keyboard shortcuts to select what I want and for the trickier scenarios there are also commands to go through selections one at a time so you can skip certain matches to end up with only what you want.

   But sometimes there are too many false matches that you don’t want to select by hand and that’s where regex comes in handy.

   For instance, finding:

   • parent but not apparent, transparent, parentheses, apparently, transparently
   • test but not latest, fastest, testing, greatest, shortest
   • trie but not entries, retries, countries, retrieve
   • http but not https

   … which can be easily done by searching for a word that doesn’t include a letter immediately before or immediately after: e.g. \Wtest\W.

2. Search for things across all files that come back with too many results that aren’t relevant

   Basically using the same things above.

3. Finding something I already know mates a pattern. Like finding all years: \d{4}, finding all versions: \d+\.\d+\.\d+, finding random things that a linter may have missed such as two empty lines touching each other: \n\s*\n\s*\n, etc…

Today, to configure fail2ban. Before that, yesterday to select which tests to run.

Every day pretty much with Unix tools. Vim, awk, sed, etc.

Yesterday doing a search using vim for a class that shared a lot of characters at the front with many other classes: /Bas.*Some I could have done a more precise search with better regex, but this was quick, easy, and worked.

Yesterday, when I had a file with a list of JSON objects, and I wanted to move the date field at the end to the beginning, so I used regex find and replace to move it. Something like \{(.*?), ("date": ".*?") in Search, and then {$2, $1 in replace (or something close to it).

Yes, I refactor code and data using regex. I can’t be arsed to learn AWK (even though I should).

Interesting to see a lot of these responses (so far) are workflow related instead of being used in production.

We use it for triaging test failure (running tens of thousands of tests for CPU design verification).

That use is acceptable because it is purely informational. In general you should avoid regexes at all costs. They’re difficult to read, and easy to get wrong. Generally they are a very big red flag.

Unfortunately they tend to get used where they shouldn’t due to lazy developers not parsing things properly.

Earlier this week for a character range.

/edit: Now I remember. For setting up a new entry in Jenkins CI build failure analysis - identifying the build failure cause in the log.

Today.

Usually many times a day… Even today which have been mostly meetings.

Writing the script that got me fired