为什么从 C# 调用与直接调用时 %~dp0 批处理文件路径的行为不同？

了解批处理文件路径引用中的差异 (%~dp0)

批处理文件中 %~dp0 的行为可能会有所不同，具体取决于批处理文件的执行方式，特别是在比较直接执行与从 C# 程序执行时。这种差异源于 cmd.exe 处理 %~0 变量及其修饰符的方式。

问题：

考虑一个包含以下行的批处理文件：

<code class="language-batch">echo %~dp0
cd Arvind
echo %~dp0</code>

直接运行时，将目录更改为“Arvind”不会影响%~dp0的输出。 但是，如果从 C# 程序调用同一个批处理文件，第二个 echo %~dp0 将 反映新目录（“Arvind”）。

根本原因：

核心问题在于cmd.exe对%~0的解读。 %~0 变量与 ~d（驱动器号）和 ~p（路径）等修饰符一起，从当前运行的批处理文件的内部表示中访问信息。

关键的区别在于引用如何影响这个内部引用。 如果 %~0 未加引号，则内部引用正确指向批处理文件的完整路径。 但是，如果对批处理文件的调用加了引号（这在 C# 交互中很常见），cmd.exe 会去除引号，可能会导致相对路径解释而不是绝对路径。 然后，此相对路径解释会根据当前工作目录而变化。

解决方案：

对于 C# 执行：

• 避免引用： 最简单的解决方案是在从 C# 调用批处理文件时避免使用引号。 使用 cmd /c batchfile.cmd 等命令代替 "cmd /c "batchfile.cmd"。
• 使用完整路径： 如果引号不可避免，请始终在 C# 调用中提供批处理文件的完整路径。 这可确保 cmd.exe 具有正确的绝对路径，无论工作目录如何。

对于批处理文件执行：

• 强大的路径检索：批处理文件本身最可靠的方法是使用子例程来获取当前脚本的路径。此方法绕过了引用和目录更改引起的不一致：

<code class="language-batch">@echo off
setlocal enableextensions disabledelayedexpansion

call :getCurrentBatchPath myBatchPath
echo %myBatchPath%
cd Arvind
echo %myBatchPath%
exit /b

:getCurrentBatchPath
set "%~1=%~f0"
goto :eof</code>

此子例程使用 %~f0 （始终提供完整路径）将路径存储在指定变量中（本示例中为 myBatchPath）。 即使更改目录后，该变量仍保持一致。

以上是为什么从 C# 调用与直接调用时 %~dp0 批处理文件路径的行为不同？的详细内容。更多信息请关注PHP中文网其他相关文章！