当涉及管道时，为什么在搜索字符串中具有可变扩展名的`findstr`返回意外结果？

Question

在试图为为什么FindStr返回未找到问题提供全面的答案时，我遇到了涉及管道的代码的奇怪行为。这是一些基于原始问题的代码（将在批处理文件中执行）：

rem // Set variable `vData` to literally contain `...;%main%\Programs\Go\Bin`:
set "vData=...;%%main%%\Programs\Go\Bin"
set "main=C:\Main"

echo/%vData%| findstr /I /C:"%%main%%\\Programs\\Go\\Bin"

这并没有返回匹配，因此没有什么呼应和ErrorLevel被置1 1。

尽管当我逐步进行解析过程时，我得出相反的结论，但是我确实期望有一个匹配项和一个匹配ErrorLevel项0，因为：

1. 首先，将对整个行进行解析，然后进行即时（%）扩展，因此%vData%将其扩展并%%替换为%，从而将执行以下命令行：

   echo/...;%main%\Programs\Go\Bin| findstr /I /C:"%main%\\Programs\\Go\\Bin"
   

2. 管道的每一端|都在自己的新cmd实例中执行cmd /S /D c，这两个实例均在cmd上下文中运行（这会影响%-expansion的处理），从而产生以下部分：

   • 管道的左侧：

     echo/...;C:\Main\Programs\Go\Bin
     

   • 管道的右侧：

     findstr /I /C:"C:\Main\\Programs\\Go\\Bin"
     

     （即搜索字符串findstr最后采用的是C:\Main\Programs\Go\Bin作为\即使在文字搜索模式用作转义字符，/C或/L）

如您所见，最终的搜索字符串实际上发生在回显的字符串内，因此我希望有一个匹配项，但是命令行不会返回一个。那么这里发生了什么，我想念什么？

---

当我main在执行管道命令行之前清除变量时，得到了预期的结果，这使我得出结论，main尽管我做了上面的假设，但变量并未扩展（请注意，在cmd上下文中，%main%当变量为空时将保留该变量）。我对吗？

---

它变得更加令人困惑：当我将管道的右侧放在括号之间时，无论是否main定义了变量，都会返回一个匹配项：

echo/%vData%| (findstr /I /C:"%%main%%\\Programs\\Go\\Bin")

谁能解释一下？可以将其与findstr外部命令相对echo吗？（我的意思是，如果定义，break | echo/%vData%则按main预期扩展值...）

Answer 1

我将你的例子简化为：

\n\n

@echo off\n\nset "main=abc"\nbreak | findstr /c:"111" %%main%%\nbreak | echo findstr /c:"222" %%main%%\n

\n\n

输出是：

\n\n

\n

FINDSTR: %main% kann nicht ge\xc3\xb6ffnet werden。
\n findstr /c:"222" abc

\n

\n\n

这证明在管道中使用 exe 文件会导致与使用内部批处理命令不同的行为。
\n仅对于内部命令，才会创建新的 cmd.exe 实例。
\n这也是 findstr 不扩展百分号的原因。

\n\n

这条令人困惑的行会扩展，因为括号会强制创建一个新的 cmd.exe 实例。

\n\n

break | (findstr /c:"111" %%main%%)\n

\n\n

我将修改5.3 管道 - Windows 命令解释器 (CMD.EXE) 如何解析脚本？\n

\n