1

EDIT: This seems to be a pretty niche scenario that I'm running into, but the answer to the question itself is that powershell.exe inherits the working directory from the calling process. I.e. PUSHD does change the working directory of cmd and that is passed to PWSH.

As an aside, the issue I'm running into is that I don't have permissions and access to all of the folders in the working directory path. In particular below, I'm missing permissions for \Dev\. So if I locally map \\<ComputerName>\<ShareName>\<NoAccessVolume>\<AccessVolume> to a drive like my H:, it works fine since the mapping skips over <NoAccessVolume>. However, I can't simply have PowerShell set my location to \\<ComputerName>\<ShareName>\<NoAccessVolume>\<AccessVolume> because even though PowerShell can handle UNC paths, it will throw a permissions related error.

Without getting into why I'm using a batch file, I'm using one. As noted in another answer, batch files (.cmd, .bat) can be launched directly while .ps1 files cannot.

So here's the scenario:

  • Saved my code as base64
  • Created a .bat file to invoke powershell.exe and pass the code using the -EncodedCommand parameter
  • Everything worked, until it didn't

One of the users either doesn't have their network share mapped to a local drive, or they went out of the way to access the network share using the UNC path. cmd.exe doesn't like this and it warns the us that the Windows Directory will be used. According to a different answer here on SO, %SystemRoot% is used. It is easy enough to use PUSHD and POPD to change the directory of cmd.exe (see various answers here) - However, powershell.exe doesn't seem to care about the temporary drive letter. So referencing $PWD within the script...not a good idea.

I can't find anything on about_PowerShell_exe that talks about the working directory - but it is pretty easy to say that if cmd.exe defaults to the Windows Directory, then powershell.exe will also use C:\Windows. However using PUSHD prior to calling powershell.exe results in PowerShell opening at C:\. So I guess I'm wondering what logic powershell.exe uses to determine the resulting PowerShell Working Directory and, in my specific case, if there are any easy options available to change the working directory to match %~dp0 (i.e. where .bat file was called from).

The first answer I linked (here as well) goes into some helpful detail on passing arguments to PowerShell when calling it from a batch file, so I know that is one route I can go - but is there anything hidden in powershell.exe that I'm missing?

EDIT: Here is what I'm getting currently. I am using Windows 10.

The contents of my batch file:

@echo OFF
echo Batch File: %0
powershell.exe -NoProfile -NoExit -Command Write-Host PowerShell Working Directory w/o PUSHD: $PWD
PUSHD "%~dp0"
powershell.exe -NoProfile -NoExit -Command Write-Host PowerShell Working Directory w/ PUSHD: $PWD
POPD
PAUSE

Running from a mapped drive; $PWD will work as expected:

Batch File: "H:\_Team Members\immobile2\test.bat"
PowerShell Working Directory w/o PUSHD: H:\_Team Members\immobile2
PS H:\_Team Members\immobile2> exit
PowerShell Working Directory w/ PUSHD: H:\_Team Members\immobile2
PS H:\_Team Members\immobile2> exit
Press any key to continue . . .

Running from the Network Share; $PWD will not work as expected

'\\dep-files01\Departments$\Dev\Data\_Team Members\immobile2'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported.  Defaulting to Windows directory.
Batch File: "\\dep-files01\Departments$\Dev\Data\_Team Members\immobile2\test.bat"
PowerShell Working Directory w/o PUSHD: C:\Windows
PS C:\Windows> exit
PowerShell Working Directory w/ PUSHD:
PS C:\> exit
Press any key to continue . . .
immobile2
  • 425
  • 1
  • 9
  • 2
    It's kind of hard for us to determine what the issues are with one, or all, of the things you've tried, because you have not provided us with a single line of failing code. My initial advice for testing would be to use `PushD "%~dp0"`, then try using `Start "" /D "%CD%" "%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe" -ExecutionPolicy RemoteSigned -File "P:\athTo\YourScript.ps1" [Arg(s)]`. _But for all we know, you've tried that already, and you're just expecting us to keep on making suggestions, tell us that you've done that already, and allow us all to play your guessing game!_ – Compo Oct 11 '21 at 22:24
  • In general, PowerShell sees the same working directory as the calling process. On Windows 10, an ad-hoc mapping to a UNC path passed to `pushd` beforehand _does_ seem to be visible to a `powershell.exe` call. Are you running on an older version? – mklement0 Oct 12 '21 at 00:51
  • I added some screenshots of what I'm seeing, basically `pushd` seems ok for the command line of `cmd.exe`, but I'm not seeing that pass through to `powershell.exe`. @Compo - one reason I haven't tried what you suggested is that our company has GPO restrictions on running a script file, that's part of the reason I'm using a `.bat` in the first place. It just seems strange that PowerShell isn't using the same working directory as the calling process. `pushd` on my computer is assigning the `"W:\"` drive to the network share - but PowerShell is using `"C:\"` – immobile2 Oct 12 '21 at 16:07
  • I wouldn't expect it to make a difference, but for general robustness you should use double quotes: `pushd "%dp0"` (spaces in paths are - curiously - fine without the quoting, but `&` wouldn't be). The only other thing that comes to mind is that it's worth checking if the `$` in the path may be causing trouble. – mklement0 Oct 16 '21 at 14:36
  • I actually had double quotes, I just copy/pasted wrong. It doesn't seem to the be the `$` although that's a good thought. I didn't know what the dollar sign was doing there, but it is basically making them [_hidden_ shares](https://stackoverflow.com/a/448393/15243610). Oddly enough, I think I figured it out and just need a workaround now. It is security related, but doesn't have anything to do with the `$` or hidden shares – immobile2 Oct 18 '21 at 17:20
  • Related question that I think gets at this, although the issue seems to be few and far between: https://stackoverflow.com/q/54714657/15243610. I disagree with the OP in that question as nested folders don't work for me, but the problem seems to be the same for `Set-Location` as launching directly to that location. I.e. not only read/write access to the final destination folder/container, but read access to traverse all the way there – immobile2 Nov 04 '21 at 12:15

0 Answers0