adb not working in powershell but adb.exe works

when typing "adb devices" in Powershell, it return a prompt to ask "How do you want to open this file". However, if I use "adb.exe devices", it works and give me the list of devices.

As I have a lot of scripts written as adb instead of adb.exe, is there a way to fix this?

In cmd, typing adb devices would also work. But the scripts were all PS based. So fixing this in powershell will really helps. Thanks.

As you've confirmed, the problem was an extraneous, empty file literally named adb (without a filename extension) that resided in your C:\WINDOWS\system32 directory.

Since the PATH environment variable (typically) lists C:\WINDOWS\system32 before the directory in which the desired target executable (adb.exe) is located, C:\Program Files (x86)\Intel\Platform\..., PowerShell attempted to execute C:\WINDOWS\system32\adb, which - as an extension-less file - triggered the GUI dialog you saw.

Removing the extraneous C:\WINDOWS\system32\adb file solved your problem.

Get-Command -All adb helped discovered the problem: it listed all forms of a command named adb known to PowerShell, in order of precedence, with information about their type and location; that is, the effective command - the one that is actually invoked - was listed first.

Read on for background information.

• As all shells do, if a command uses a mere (file) name (as opposed to a file path), PowerShell looks for executables in the directories listed in the PATH environment variable (accessible as $env:PATH in PowerShell), in order.

  • That is, if you submit a command line with command name adb, PowerShell - after looking for an internal command by that name first (an alias, function, or cmdlet) - looks for an executable file whose base name is adb, in the directories listed in $env:PATH, and invokes the first one it finds.

  • On Windows, an executable file is one whose filename extension is listed in the PATHEXT environment variable ($env:PATHEXT); again, the extensions listed there are considered in order. By contrast, on Unix-like platforms it is solely the file mode (the permission bits) that determine whether a file is executable.

• However, unlike other shells, PowerShell doesn't just look for executable files in $env:PATH, it considers any file that exactly matches the command name given executable, and in effect passes such a file to the Invoke-Item cmdlet, which triggers the default GUI shell action on the file, equivalent to double-clicking a document in File Explorer on Windows.

  • This problematic behavior is discussed in this GitHub issue, which proposes that only true executables be considered commands.