If an EXE is visible in your current folder but PowerShell says the command is not recognised, the problem may be command lookup rather than a missing installation. PowerShell does not automatically search the current directory for executable commands. For a trusted tool in that directory, use an explicit relative path such as .\ReportTool.exe, or an absolute path.
Do not solve this by adding every download directory, or the current-directory shortcut, to PATH. First confirm where the terminal is, which file you intend to run, and whether you trust that file. Finding an executable and establishing that it is safe are separate tasks.
Confirm the terminal is in the folder you expect
A File Explorer window and an already-open terminal do not necessarily point to the same place. In PowerShell, inspect the current location:
Get-LocationThen look for the exact executable using a literal path:
Get-Item -LiteralPath '.\ReportTool.exe' | Select-Object Name, FullName, LengthReplace the example filename with the trusted tool you actually have. These two commands inspect location and file metadata; they do not execute the program. If the second command reports that the file does not exist, stop and check the folder, spelling and extension. Do not assume an Explorer display name includes the true extension.
If your folder or filename contains square brackets, the site’s LiteralPath troubleshooting tutorial explains why wildcard-aware path parameters can produce surprising results.
Use a relative path only after checking trust
For a verified local executable, the command shape is:
.\ReportTool.exeThis is an execution command, not a diagnostic probe. Run it only when you intend to launch that specific application and understand its normal behaviour. The illustrative name here is a placeholder, not a built-in Windows utility. A program’s name or location does not establish its publisher, safety or arguments.
Microsoft’s command-precedence documentation states that specifying a path selects the command at that location. It specifically documents the relative .\ form for executables in the current directory. This removes ambiguity about where to look; it does not bypass security policy or grant additional permissions.
Handle a full path containing spaces
Quoting a path by itself produces a string expression rather than invoking that string as a command. PowerShell’s call operator, &, can invoke a quoted executable path. The following is another execution example; replace the placeholder only with an approved tool:
& 'C:\Approved Tools\ReportTool.exe'Keep the executable path and each argument separate if you later add documented options. Do not paste an entire unreviewed command line into a string and use expression-evaluation tricks to force it to run. For repeatable administration, an explicitly configured full path is clearer than relying on whichever directory a person happened to open.
Separate lookup failures from blocked execution
A command-not-found message asks a different question from an access-denied message or a security warning. If the executable is found but execution is blocked, preserve the exact error and consult your organisation’s application-control or endpoint-security process. Do not disable antivirus, unblock files indiscriminately or start an elevated shell merely to make the warning disappear.
PowerShell script files are also subject to lookup rules, but script execution policies introduce separate considerations. This tutorial does not recommend changing execution policy and does not diagnose a blocked script as a missing EXE.
If typing a bare command launches something unexpected, inspect name resolution without launching it:
Get-Command -Name ReportTool.exe -AllA bare-name lookup does not prove that the file in your current folder is absent. It reports commands discoverable under the lookup rules. Use the literal file inspection above for the current-folder question, then compare any discovered command paths before deciding what to run.
Quick checklist and FAQ
- Confirm the current location rather than assuming it matches File Explorer.
- Inspect the exact executable path without launching it.
- Verify the tool’s origin through your approved software process.
- Use an explicit relative or absolute path only when ready to execute.
- Treat security blocks as security decisions, not PATH mistakes.
Should I add the current folder to PATH? Not for this fix. Explicit paths avoid a persistent configuration change and reduce the chance of accidentally selecting another executable with the same name.
Does the explicit path make a tool safe? No. It selects a location; it does not validate the file’s contents or authorise its use. No rollback is required for the inspection commands because they do not modify settings, but the application you choose to run can have its own side effects.
This tutorial is for educational purposes. Test carefully before production use. The site owner is not responsible for misuse, damage, data loss or production issues.
