Why a program doesn't work when run from a batch file, but works when clicked

With drive letters, a neat functionality in DOS/Windows command prompts (don't ask me about Powershell) is that each letter can have its own "current directory".

So if you have ffmpeg.exe in C:\Program Files\FFMpeg\bin, and you have some source files in D:\SourceVideos, and you want to process them in ffmpeg and output them to E:\Output you can do:

C: (to navigate to the C: drive)

cd "C:\Program Files\FFMpeg\bin"

E: (to navigate to the E:\ drive)

cd D:\SourceVideos (you remain in E:\, but the "current directory" for D: has been changed).

cd Output (to enter E:\Output)

You can now do C:ffmpeg.exe -i D:scene1.mp4 output-scene1.mp4

and Windows accesses the files in the "current" directory on each drive letter.

How much are these customers paying for support to have Raymond Chen on first level support to debug their batch files?

> Explorer sets the current directory of the program to the directory containing the thing that you double-clicked

I found the linked article to informative and confirming my suspicion: "The thing that you clicked" doesn't have to be the executable - it could also be a document with the executable registered as launch handler, in which case the current directory will be the directory of the document.

Would be interesting to know how links and items in shell namespaces are handled.

Well, there is no concept of "the current directory" in the UI of explorer.exe the way there is in CMD.EXE or Bash. You can have multiple directories open and none of them are privileged over the others.

I think of cultures of command line programs: the node ecosystem very much has the idea that a program "lives" in a a certain directory and you're always going to work with that program in that directory. This is convenient in a lot of ways but... say you are writing a data analysis program and you want to put it on your $PATH and then cd to the place where your data lives and do your work there?

A related issue is when you set up automation, and it turns out the automation script runs as a different user with different authorizations from the user who tested the script. It's just one of those little annoyances that appears when you try to go from "works on my machine" to "works".

Is there a tool in Windows that will dump all of a process context to debug these kind of things: CWD, env vars, current user, elevation, etc.

If you're feeling especially crazy, you can detect when a program was started from a console or not. That lets you make a Windows program that can display messages in the console that started the program. (But the console still is accepting inputs as if no program is running)

Appreciating that this is not AI generated

If I were to guess, it's because the program has an extension associating with an interpreter application, and that association is handled by the Windows Shell framework's app/document launching API (like ShellExecuteEx, if I dimly recall), which is used by Explorer for running programs, but not by batch files.

Am I close?

Is this an article from 1997?

[flagged]

[flagged]