Windows 中的 Git Bash 需要 .exe 扩展名,但不是全部程序都需要。

Windows 中的 Git Bash 需要 .exe 扩展名,但不是全部程序都需要。

我将$PATH变量指向 的位置MSBuild.exe。如果我输入MSBuild.exe,它会运行正常,但如果我省略.exe,它就找不到它。但是,我可以输入ssh-addnotepad,并且它在没有扩展名的情况下运行正常。针对这些名称运行也是如此which

首先,为什么?其次,我该如何改变它,以便在运行时
可以停止?(我宁愿不在中定义别名。).exeMSBuild.bashrc

最佳猜测:Git Bash(或 MINGW64 或其他)在它知道的位置创建指向记事本和命令提示符等常见可执行文件的无扩展名链接(符号或硬链接)$PATH。我注意到which notepad在中返回路径,/usr/binwhich notepad.exe返回 Windows 路径,但这只是猜测。相反的证据是ls -al /usr/bin/ssh-add*只返回.exe路径。

笔记$PATHEXT包括.EXE

$ echo $PATHEXT
.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.PY;.PYW

答案1

这是预期的行为,因为 Windows 环境在 WSL 中没有意义。CMD 和 PowerShell 不会隐式调用 WSL 中的任何内容(/usr/bin/等等)。反之亦然,CMD 和 PowerShell 都不理解 Linux shebang。

例如,如果在 bash 中调用时python默认调用 Windowspython.exe二进制文件而不是 Linux 二进制文件,那将会带来很大的不便。

这是 WSL 错误报告的主题,但被微软拒绝了
避免输入 Windows 可执行文件的文件扩展名

但是,以下代码是由一位用户提供的,可以满足您的要求。~/.bashrc如果您愿意承担上述混淆 Windows 和 Linux 可执行文件的风险,请将其放在您的:

eval "$(echo "orig_command_not_found_handle()"; declare -f command_not_found_handle | tail -n +2)"
command_not_found_handle()
{
   cmd=$1
   shift
   args=( "$@" )

   IFS=:
   for dir in $PATH; do
      for executable in $dir/$cmd.exe $dir/$cmd.com $dir/$cmd.bat; do
         if [ -x $executable ]; then
            "$executable" "${args[@]}"
            return
         fi
      done
   done

   orig_command_not_found_handle "$cmd" "${args[@]}"
} 

答案2

考虑为您经常使用的少数程序添加别名,如下~/.bashrc所示:

alias MSBuild=MSBuild.exe
alias kubectl=kubectl.exe

相关内容