Are there any fundamental incompatibilities when using a CMD script in a console using PowerShell?

Question

I have an extensive set of CMD scripts for an automation suite.

In a console using CMD.exe, everything works fine. After installing the Windows Creator's update, where PowerShell becomes the new default Windows shell via Explorer's menu options, my scripts break at-random. I can't provide any meaningful code for repro for two main reasons:

1. No obvious error is occurring; my automated scripts just hang, eventually
2. The halt isn't even occurring in the same place each time

What I can tell you is that the suite heavily relies on exit codes, use of findstr.exe, and type.

I know things like Windows macros, e.g., %Var% are not compatible, but I was assuming that since the only call I did was to a .bat file, .bat behavior would be the only thing I would need to worry about.

If that's not the case, should my initial .bat be triggering the direct execution of a CMD.exe instance with my parameters? If so, what's the best way to do that, PowerShell-friendly?

Answer 1

eryksun's comments on the question are all worth heeding.

This section of the answer provides a generic answer to the generic question in the question's title. See the next section for considerations specific to the OP's scenario.

Generally speaking, there are only a few things to watch out for when invoking a batch file from PowerShell:

• Always include the specific filename extension (.bat or .cmd) in the filename, e.g., script_name.bat

  • This ensures that no other forms of the same command (named script_name, in the example) with higher precedence are accidentally executed, which could be:
    • In case of a command name without a path component:
      • An alias, function, cmdlet, or an external executable / PowerShell script (*.ps1) that happens to be located in a directory listed earlier in the $env:PATH (%PATH%) variable; if multiple executables by the same name are in the same (earliest) directory, the next point applies too.
    • In case of a command name with a path component:
      • A PowerShell script (*.ps1) or executable with the same filename root whose extension comes before .bat or .cmd in the %PATHEXT% environment variable.

• If the batch file is located in the current directory, you must prefix its filename with ./

  • By design, as a security measure, PowerShell - unlike cmd.exe - does NOT invoke executables located in the current directory by filename only, so invoking script_name.bat to invoke a batch file of that name in the current directory does not work.^[1]

  • Instead, you must use a path to target such an executable so as to explicitly signal the intent to execute something located in the current directory, and the simplest approach is to use prefix ./ (.\, if running on Windows only); e.g., ./script_name.bat.

• When passing parameters to the batch file:

  • Either: be aware of PowerShell's parsing rules, which are applied before the arguments are passed to the batch file - see this answer of mine.
  • Or: use --% (the PSv3+ stop-parsing symbol) to pass the remaining arguments as if they'd been passed from a batch file (no interpretation by PowerShell other than expansion of %<var>%-style environment-variable references).

^{[1] eryksun points out that on Vista+ you can make cmd behave like PowerShell by defining environment variable NoDefaultCurrentDirectoryInExePath (its specific value doesn't matter).
While ill-advised, you can still force both environments to always find executables in the current directory by explicitly adding . to the %PATH% / $env:PATH variable; if you prepend ., you get the default cmd behavior.}

---

As for your specific scenario:

After installing the Windows Creator's update, where PowerShell becomes the new default Windows shell via Explorer's menu options

This applies to the following scenarios:

• Pressing Win-X (system-wide keyboard shortcut) now offers PowerShell rather than cmd in the shortcut menu that pops up.

• Using File Explore's File menu now shows Open Windows PowerShell in place of Open command prompt (cmd).

However, nothing has changed with respect to how batch files are invoked when they are opened / double-clicked from File Explorer: The subkeys of HKEY_CLASSES_ROOT\batchfile and HKEY_CLASSES_ROOT\cmdfile in the registry still define the shell\open verb as "%1" %*, which should invoke a batch file implicitly with cmd /c, as before.

However, per your comments, your batch file is never run directly from File Explorer, because it require parameter values, and it is invoked in two fundamental ways:

• Explicitly via a cmd console, after entering cmd in the Run dialog that is presented after pressing Win-R (system-wide keyboard shortcut).

  • In this case, everything should work as before: you're invoking your batch file from cmd.

• Explicitly via PowerShell, using File Explorer's File menu.

  • Per your comments, the PowerShell console may either be opened:

    • directly in the directory in which the target batch file resides.
    • in an ancestral directory, such as the root of a thumb drive on which the batch file resides.

  • In both cases, PowerShell's potential interpretation of arguments does come into play.

  • Additionally, in the 2nd case (ancestral directory), the invocation will only work the same if the batch file either does not depend on the current directory or explicitly sets the current directory (such as setting it to its own location with cd /d "%~dp0").

Answer 2

This is a non-answer solution if encountering the question's specific behavior. I've verified all my halting scripts stopped halting after implementing a shim-like workaround.

As erykson said, there doesn't appear to be a reason why using a shim would be required. The goal is then to explicitly launch the script in CMD when using PowerShell, which aligns with Jeff Zeitlin's original suggestion in the question's comments.

So, let's say you're in my shoes with your own script_name.bat.

script_name.bat was your old script that initializes and kicks off everything. We can make sure that whatever was in script_name.bat is correctly run via CMD instead of PowerShell by doing the following:

1. Rename script_name.bat to script_name_shim.bat
2. Create a new script_name.bat in the same directory

3. Set its contents to:

   @echo off
   CMD.exe /C "%~dp0script_name_shim.bat" %*
   exit /b %errorlevel%
   

That will launch your script with CMD.exe regardless of the fact that you started in PowerShell, and it will also use all your command-line arguments too.

Answer 3

This looks like a chicken egg problem, wihtout knowing the code it's difficult to tell where the problem is.
There are a ton of ways to start batches with cmd.exe even in win10cu.

Aliases are only a problem when working interactively with the PowerShell console and expecting behavior as it used to be in cmd.exe.
The aliases depend also on the loaded/imported modules and profiles.

• This small PowerShell script will get all items from Help.exe and perform a Get-Command with the item.
• internal commands without counterparts in PoSh are filtered out by the ErrorAction SilentlyContinue.
• Applications (*.exe files) are assumed identical and removed by the where clause.

---

help.exe |
  Select-String '^[A-Z][^ ]+'|
    ForEach-Object {
      Get-Command $_.Matches.Value -ErrorAction SilentlyContinue
    }| Where-Object CommandType -ne 'Application'|Select *|
       Format-Table -auto CommandType,Name,DisplayName,ResolvedCommand,Module

Sample output on my system, all these items will likely work differently in PowerShell:

CommandType Name   DisplayName            ResolvedCommand Module
----------- ----   -----------            --------------- ------
      Alias call   call -> Invoke-Method  Invoke-Method   pscx
      Alias cd     cd -> Set-LocationEx   Set-LocationEx  Pscx.CD
      Alias chdir  chdir -> Set-Location  Set-Location
      Alias cls    cls -> Clear-Host      Clear-Host
      Alias copy   copy -> Copy-Item      Copy-Item
      Alias del    del -> Remove-Item     Remove-Item
      Alias dir    dir -> Get-ChildItem   Get-ChildItem
      Alias echo   echo -> Write-Output   Write-Output
      Alias erase  erase -> Remove-Item   Remove-Item
      Alias fc     fc -> Format-Custom    Format-Custom
   Function help                                          pscx
      Alias md     md -> mkdir            mkdir
   Function mkdir
   Function more
      Alias move   move -> Move-Item      Move-Item
   Function Pause
      Alias popd   popd -> Pop-Location   Pop-Location
   Function prompt
      Alias pushd  pushd -> Push-Location Push-Location
      Alias rd     rd -> Remove-Item      Remove-Item
      Alias ren    ren -> Rename-Item     Rename-Item
      Alias rmdir  rmdir -> Remove-Item   Remove-Item
      Alias set    set -> Set-Variable    Set-Variable
      Alias sc     sc -> Set-Content      Set-Content
      Alias sort   sort -> Sort-Object    Sort-Object
      Alias start  start -> Start-Process Start-Process
      Alias type   type -> Get-Content    Get-Content