在 powershell 脚本中使用包含多个参数的单个可延展对象作为命令

2024-6-19 • tag-icon

我有一堆参数想要多次传递给命令。为了减少编写相同参数的次数，从而减少必须维护这些参数的位置数量，我认为将它们全部放在一个字符串中并传递该字符串是个好主意。但是，命令将整个字符串视为单个参数，这自然会导致问题。

这是我想要实现的脚本示例。（顺便说一下，这是用于构建 GDAL 的）。

$baseOptions = "MSVC_VER=1910 GDAL_HOME='$outputDir\' SWIG='$swig'"

#Building x86
if($x86 -eq $true)
{
    $options = $baseOptions + " BINDIR='$outputDir\x86\bin' LIBDIR='$outputDir\x86\lib' INCDIR='$outputDir\x86\include'"
    if($useLibcurl -eq $true)
    {
        $options += " CURL_DIR='$libcurlDir/x86' CURL_INC='-I$libcurlDir/include' CURL_LIB='$libcurlDir/x86/lib/libcurl.lib wsock32.lib wldap32.lib winmm.lib'"
    }

    #Building x86 release
    if($release -eq $true)
    {
        nmake /f makefile.vc $options
        nmake /f makefile.vc install $options
        nmake /f makefile.vc devinstall $options
    }
    #Repeated for debug...
    #Some more use of $options to create C# wrappers...
}
#Repeated for x64...

仅为了构建 GDAL 的本机部分以在 x86 中发布，我需要运行nmake三次。我可能不需要每次运行都使用相同的参数nmake，但不清楚哪次运行需要什么参数，并且跟踪这些参数只是需要额外维护的事情。好吧，重复此操作进行调试，然后为 x64 发布和调试，然后重复几次以创建 C# 包装器。

如果我无法修改这样的参数集合，那么我还必须复制代码，以确定是否要构建依赖于 libcurl 的 GDAL。如果我还必须添加对其他依赖库的支持，那么复杂性将变得非常大。

我尝试将整个命令变成一个字符串以便$options通过以下方式扩展，但无济于事：

. "nmake /f makefile.vc $options"
& "nmake /f makefile.vc $options"

整个字符串当然被视为一个命令，而不是带有参数的命令......

我在写这个问题时实际上已经找到了答案，但我还是决定询问，以帮助那些可能像我一样疯狂寻找解决方案的人。我仍然欢迎以不同方式解决同一问题的答案！也许那些不依赖于在单个字符串中收集参数的答案？

答案1

我在命令中找到了解决方案Invoke-Expession。

Invoke-Expression "nmake /f makefile.vc $options"

这样，字符串首先扩展$options，然后Invoke-Expression将整个字符串读取为带有参数的命令。

我仍然欢迎以不同方式解决同一问题的其他答案！

答案1

相关内容