Repository navigation
fix(harness): start child processes without NoDefaultCurrentDirectoryInExePath - #28
Conversation
…InExePath
With NoDefaultCurrentDirectoryInExePath set in the caller's environment, a
per-user shell setting, cmd.exe does not look in its working folder, so a
Win32 install command given as a bare batch file ("install.cmd") failed
with "'install.cmd' is not recognized" from Invoke-IntuneWin32AppTest. The
agent's cmd.exe runs without the caller's profile and finds the file.
The launcher now removes the variable from the direct child's environment,
next to the PSModulePath handling that already edits it. The scheduled-task
modes run under another account's environment and are unchanged.
fadwen
left a comment
There was a problem hiding this comment.
Notes on the lines whose reason the diff does not show.
| # With NoDefaultCurrentDirectoryInExePath set in the caller's own environment, cmd.exe does | ||
| # not look in its working folder, and a bare 'install.cmd' fails with "not recognized". The | ||
| # agent's cmd.exe runs without the caller's profile, so the child runs without the setting | ||
| $null = $startInfo.Environment.Remove('NoDefaultCurrentDirectoryInExePath') |
There was a problem hiding this comment.
Removed unconditionally rather than only when set: Remove on a missing key returns false and nothing else, and the task modes below are left alone on purpose. A scheduled task runs with the SYSTEM or the other account's environment, where a caller's per-user setting is not present, which is also the environment the agent's own cmd.exe has.
| # the working folder; the agent's cmd.exe has no such setting, so the child must not either | ||
| Set-Content -Path (Join-Path $TestDrive 'install.cmd') -Value '@echo ran' -Encoding ascii | ||
| $saved = $env:NoDefaultCurrentDirectoryInExePath | ||
| $env:NoDefaultCurrentDirectoryInExePath = '1' |
There was a problem hiding this comment.
Set in the test's own process rather than mocked, because the thing under test is what the child inherits from the parent. Without the fix this exact run fails with "'install.cmd' is not recognized" (exit 1), which is how the problem showed up on a developer machine with the variable in the user environment.
Summary
A Win32 install or uninstall command given as a bare batch file (
install.cmd) failed fromInvoke-IntuneWin32AppTestwith "'install.cmd' is not recognized as an internal or external command" on a machine whereNoDefaultCurrentDirectoryInExePathis set in the caller's environment. That variable is a per-user shell setting that stopscmd.exesearching its working folder. The agent'scmd.exeruns as SYSTEM without the caller's profile and finds the file, so the local run disagreed with the device for a reason that had nothing to do with the app.Changes
Private/Invoke-IslProcess.ps1: the direct child process starts withoutNoDefaultCurrentDirectoryInExePath, next to the existingPSModulePathhandling of the same start info. The scheduled-task modes run under another account's environment and are unchanged.Tests/Unit/Private/Invoke-IslProcess.Tests.ps1: a test sets the variable in the test session and checks thatcmd.exe /C "install.cmd"still runs the batch file in its working folder through the launcher.CHANGELOG.md: Fixed entry under Unreleased.Verification
Tests/Unit/Private/Invoke-IslProcess.Tests.ps1: 21 passed on PowerShell 7.6.6 and on Windows PowerShell 5.1 (Pester 6.2.0).Notes