RegEx Pattern works on regex101.com but does not work with select-string -pattern

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest released version
• Search the existing issues.
• Refer to the FAQ.
• Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

$vssadmin = vssadmin list writers ($vssadmin | Select-String -Pattern “(?msi)^Writer name: (?‘writer’.*)\r?\n Writer Id: (?‘id’[^:])\r?\n Writer Instance Id: (?‘instance’[^:])\r?\n State: (?‘state’[^:])\r?\n Last error: (?‘err’[^:])\r?\n$” -AllMatches ).Foreach{$_}

Expected behavior

Named groups of matches. writer, is, instance, state and err.

Actual behavior

Empty string

Error details

No error

Environment data

Name                           Value
----                           -----
PSVersion                      7.3.4
PSEdition                      Core
GitCommitId                    7.3.4
OS                             Microsoft Windows 10.0.22621
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Visuals

(https://regex101.com/r/Itarw8/1)

[mklement0]

On a general note, @B-Art:

• With respect to regexes, PowerShell is just the facilitator: the .NET regex engine does all the work.

• Unless you have reason to believe that there is a problem with how PowerShell facilitates this access (which would require showing a PowerShell statement that behaves differently from the equivalent direct .NET API call), a potential bug with respect to regex processing should be reported at https://github.com/dotnet/runtime/issues (I don’t think there is one here).

  • A notable difference between PowerShell-mediated regex functionality vs. direct .NET API use is that PowerShell uses case-insensitive regexes by default.

• With respect to using regex101.com - a great tool, to be sure - for PowerShell, there are pitfalls:

  • It assumes different defaults (even if you choose the NET (C#) flavor): notably, the m (Multiline) option is on by default, and i (CaseInsensitive) is off by default; the g (global) option, which has no direct .NET equivalent is on by default, but it doesn’t apply to match or switch -Regex, for instance.
  • It assumes (verbatim) C# string-literal syntax, requiring escaping of " chars. as ""
  • See https://github.com/firasdib/Regex101/issues/1838 for a request to support a PowerShell-specific flavor that would eliminate these problems.
  • However, two pitfalls will remain:

    • The site only supports a single, multiline input string to test against.

      • This notably contrasts with PowerShell often reporting lines as a stream of multiple, individual (newline-free) strings, as when you use Get-Content (without -Raw) and when you process output from external programs, such as vssadmin.exe in your case.
      • As @iRon7 has pointed out, piping to Out-String is the simplest solution for external programs; for Get-Content, it is -Raw.
      • Also note that Select-String, when given a file (file-info object, such as output by Get-ChildItem) as input also searches line by line; searching across lines requires an idiom such as Get-Content -Raw ... | Select-String ...

    • Pasting multi-line strings as subject strings (field “TEST STRING”) invariably converts CRLF (Windows-format) to LF (Unix-format) newlines.

<div> GitHub</div><div>Issues · dotnet/runtime</div><div>.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps. - Issues · dotnet/runtime</div>

[B-Art]

@mklement0 Thank you for your excellent explanation. I am aware that lots of functionality in PowerShell leans on .Net. For instance -Replace is completely different to .Replace(,) I know. -Replace can use Regex while .Replace(,) cannot.

I use PowerShell almost every day and I will keep on using it.

Again, thanks for your reply.