異なるのCMD異なる振る舞い

Question

アップデート2：今

私が知っているとき、そのX32は私がpowershell_ise_x32を使用してスクリプトにデバッグと$Word.Documentsがnullであること、が分かった問題です。 Powershell-API for Wordは、x32 PowerShellでは64ビットで動作が異なります。

---

更新：

エラーがPowerShellのX32を使用した場合、発生し、PowerShellの64ビット版ではありませんが発生します。それは本当にそれでした。 Powershell x32は、私がTotal Commander 32bitから起動したために実行されました。

問題は今、32ビットと64ビットPowerShellの動作が異なるのはなぜですか？

---

最初の質問：

私は私のWordDocumentsを変換し、1にそれらをマージする、PowerShellスクリプトを書きました。
私はバッチスクリプトを書いて、このpowershellスクリプトを開始しました。

私は「PowerShellのISE」罰金を作品スクリプト内で直接スクリプトを実行します。

コンテキストメニューからの管理者を実行すると、のエラーが報告されます。この場合、C：\ WINDOWS \ SysWOW64 \ cmd.exeが実行されます。

私は管理者として私のシステムで見つかった別のcmd.exeを実行すると -罰金を作品すべてを： "C：\ WINDOWS \ WinSxS \ん。Amd64 microsoft-Windowsのcommandprompt_31bf3856ad364e35_10.0.15063.0_none_9c209ff6532b42d7 \ cmd.exeの "

異なるcmd.exeで動作が異なるのはなぜですか？これらの異なるcmd.exeは何ですか？

---

バッチスクリプト：

cd /d "%~dp0" 

powershell.exe -noprofile -executionpolicy bypass -file "%~dp0%DocxToPdf.ps1" 
pause 

PowerShellのスクリプト

$FilePath = $PSScriptRoot 
$Pdfsam = "D:\Programme\PDFsam\bin\run-console.bat" 




$Files = Get-ChildItem "$FilePath\*.docx" 
$Word = New-Object -ComObject Word.Application 
if(-not $?){ 
    throw "Failed to open Word" 
} 

# Convert all docx files to pdf 
Foreach ($File in $Files) { 
    Write-Host "Word Object: " $Word 
    Write-Host "File Object: " $Word $File 
    Write-Host "FullName prop:" $File.FullName 

    # open a Word document, filename from the directory 
    $Doc = $Word.Documents.Open($File.FullName) 

    # Swap out DOCX with PDF in the Filename 
    $Name=($Doc.FullName).Replace("docx","pdf") 

    # Save this File as a PDF in Word 2010/2013 
    $Doc.SaveAs([ref] $Name, [ref] 17) 
    $Doc.Close() 
} 

# check errors 
if(-not $?){ 
    Write-Host("Stop because an error occurred") 
    pause 
    exit 0 
} 

# wait until the conversion is done 
Start-Sleep -s 15 


# Now concat all pdfs to one single pdf 
$Files = Get-ChildItem "$FilePath\*.pdf" | Sort-Object 

Write-Host $Files.Count 

if ($Files.Count -gt 0) { 

    $command = "" 
    Foreach ($File in $Files) { 
     $command += " -f " 
     $command += "`"" + $File.FullName + "`"" 
    } 

    $command += " -o `"$FilePath\Letter of application.pdf`" -overwrite concat" 
    $command = $Pdfsam + $command 
    echo $command 

    $path = Split-Path -Path $Pdfsam -Parent 
    cd $path 

    cmd /c $command 

}else{ 
    Write-Host "No PDFs found for concatenation" 
} 




Write-Host -NoNewLine "Press any key to continue..."; 
$null = $Host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown"); 

Answer 1

私は$PSScriptRootが信頼できないと判断しました。

$FilePath = $PSScriptRoot; 
$CurLocation = Get-Location; 
$ScriptLocation = Split-Path $MyInvocation.MyCommand.Path 

Write-Host "FilePath = [$FilePath]"; 
Write-Host "CurLocation = [$CurLocation]"; 
Write-Host "ScriptLocation = [$ScriptLocation]"; 

結果：

O:\Data>powershell ..\Script\t.ps1 
FilePath = [] 
CurLocation = [O:\Data] 
ScriptLocation = [O:\Script] 

様々なcmd.exe実装の違いについては、私は本当にそれに答えることはできません。機能的には同じだと思っていたはずですが、32/64ビットの違いがあるかもしれません。

Answer 2

PowerShell x32を使用するとエラーが発生し、PowerShell 64bitでは発生しません。

私はpowershell_ise_x32を使用してスクリプトにデバッグし、その$Word.Documentsがnullであることを発見しました。

私のシステムではWord 64bitがインストールされているからです。