all 34 comments

sorted by: hot top controversial new old
[–] 21 points 2 years ago

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

  • source
  • [–] 13 points 2 years ago

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

  • source
  • Yesterday. Gotta grep those logs.

  • source
  • [–] 9 points 2 years ago
    [–] 8 points 2 years ago* (last edited 2 years ago)

    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 makes 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...

  • source
  • [–] 7 points 2 years ago (1 child)

    Yesterday, for capturing URLs.

  • source
  • hideshow 2 child comments
  • [–] [S] 3 points 2 years ago (1 child)

    https?//[a-zA-Z0-9_-]*

    I am kinda learning RE right now 😅

  • source
  • parent
  • hideshow 2 child comments
  • [–] 4 points 2 years ago (1 child)
  • [–] 6 points 2 years ago

    This sentence is the uncanny valley for structure.

  • source
  • [+] 6 points 2 years ago* (last edited 1 year ago)
    [+] 6 points 2 years ago* (last edited 6 days ago) (1 child)
  • [–] 6 points 2 years ago

    On average I've probably had to work with them or write one from scratch only a handful of times per year over my career. Not often enough to be an expert or anything but I'm not so afraid of them as I used to be.

  • source
  • [–] 5 points 2 years ago (1 child)

    I don't always use regular expressions, but when I do, I use it to parse XML,

  • source
  • hideshow 2 child comments
  • [–] 5 points 2 years ago

    Asking this question is like asking when was the last time you had to search through text.

  • source
  • [–] 4 points 2 years ago

    Actually writing code that uses them: last month. Commandline: last week.

  • source
  • [–] 4 points 2 years ago (2 children)

    Writing the script that got me fired

  • source
  • hideshow 4 child comments
  • [–] 4 points 2 years ago (1 child)

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

  • source
  • hideshow 2 child comments
  • [–] 2 points 2 years ago

    Probably, because in production there are really few things that are best done with regex. Most use I had for regex in production is filling in data from user-provided files with specifically crafted names, and even there there was some guesswork because of errors in naming, and the same thing may have been achieved without regex by splitting and/or iterating

  • source
  • parent
  • [–] 4 points 2 years ago (1 child)

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

  • source
  • hideshow 2 child comments
  • [–] 4 points 2 years ago

    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.

  • source
  • [–] 2 points 2 years ago

    I used it to check a user input format.

  • source
  • [–] 2 points 2 years ago*

    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.

  • source
  • [–] 2 points 2 years ago (1 child)

    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.

  • source
  • hideshow 2 child comments
  • [–] 1 point 2 years ago* (1 child)

    regexes are a well established solution for parsing strings. what exactly is the "proper" alternative you propose?

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 2 years ago

    There are some tools/libraries that act as a front-layer over regex.

    They basically follow the same logic as ORMs for databases:

    1. Get rid of the bottom layer to make some hidden footguns harder to trigger
    2. Make the used layer closer to the way the surrounding language is used.

    But there's no common standard, and it's always language specific.

    Personally I think using linters is the best option since it will highlight the footguns and recommend simpler regexes. (e.g. Swapping [0-9] for \d)

  • source
  • parent