PowerShell中通过管道用Select-String实现类Unix grep的字符串检索方法

• 两类管道传参的本质差异：
  • 执行echo ASDF | Select-String ASDF时，管道传递的本身就是纯字符串对象，Select-String可直接对字符串内容逐字匹配，因此能正常输出结果。
  • 执行Get-WinEvent -ListLog * | Select-String antrea时，管道传递的并不是控制台显示的格式化文本，而是一系列强类型EventLogConfiguration.NET对象。Select-String处理这类非字符串对象时，只会读取对象默认ToString()方法生成的基础标识值做匹配，不会自动遍历对象所有属性，也不会对控制台渲染出来的完整表格文本做扫描，自然无法匹配到存放在LogName、LogDisplayName属性里的antrea关键词。
• 这个差异来自PowerShell管道和Unix shell管道的设计区别：PowerShell管道全程传递强类型对象，而非Unix shell那种仅传递纯文本字节流，直接套用grep的管道逻辑经常会出现匹配失效。

纯文本逐行匹配（完全等价于grep行为） #

如果需要完全复刻Linux下“命令输出管道接grep”的效果，只需要先把强类型对象通过格式化输出转为逐行纯文本流，再交给Select-String扫描即可，对应命令：

Get-WinEvent -ListLog * | Out-String -Stream | Select-String antrea

• Out-String -Stream的作用是把PowerShell本来要渲染到控制台的表格内容，逐行拆分为独立的字符串输出，不再传递原始对象。Select-String收到逐行文本后，行为和Unix下的grep完全一致，会逐行扫描所有文本内容，匹配到关键词就输出整行。

对象属性直筛（性能更优的PowerShell原生方案） #

相比把对象转成文本再反向扫描的思路，直接在源对象的属性上做匹配是效率更高的做法——不需要等待控制台格式化渲染，还能保留完整的对象信息方便后续操作。
匹配日志名称或显示名称中包含antrea的事件日志，直接执行：

Get-WinEvent -ListLog * | Where-Object {
    $_.LogName -match 'antrea' -or $_.LogDisplayName -match 'antrea'
}

• 这种方式的匹配速度比转文本扫描快数倍，输出结果依然是完整的EventLogConfiguration对象，后续可以直接对匹配结果执行导出、修改配置、查询日志内容等操作，不存在文本扫描只能拿到字符串片段的局限。

Select-String本身设计用于处理文本流，并不是万能的对象筛选器。如果管道传递的是非字符串类型的复杂对象，直接接Select-String大概率会出现匹配不全的问题。只有明确管道传递的内容是纯文本时，再使用Select-String才能获得和grep一致的检索体验。

内容的提问来源于stack exchange，提问作者jayunit100