Why a program doesn't work when run from a batch file, but works when clicked
devblogs.microsoft.com73 points by ibobev 4 days ago
73 points by ibobev 4 days ago
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.
I don't think that's good, I think that's horrible, got to hate invisible state.
Every time you rely on the current working directory, that's invisible state then. Even without multiple single-letter directories each maintaining their own state.
> Every time you rely on the current working directory, that's invisible state then.
And you think adding to it will improve things?
An interesting quirk of how this works: https://devblogs.microsoft.com/oldnewthing/20100506-00/?p=14...
So you can be at A, run a successful absolute path cd, then do something bad like a bulk remove in the current directory, and you nuke A?
What a footgun.
`cd` does not travel to an "absolute path". It changes the working directory for the specified drive. Your prompt will still show you the old path (at A:), because you've not changed the folder for the current working drive, which yes, is kind of an insane concept.
If you want to actually change the working directory and drive at the same time (which is the "absolute path" idea you have), you do `cd /d D:\whatever\`.
Yeah I understood how it actually works, I'm just saying it's a potential huge footgun for someone writing a script coming from unix derivates.
At least if I had to write one, I saw cd is available and seemingly working as expected, and wrote a cd to an arbitrary target I would not expect it to behave that way at all - my expectation would be that either the next command always runs in the cd'd path, or at least that cd errors on a path in a different drive.
I get the foot gun concern. But it's true going the other direction too.
Whether or not the gun fires comes down to what you're most accustomed to
> 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.
How much are these customers paying for support to have Raymond Chen on first level support to debug their batch files?
> How much are these customers paying for support to have Raymond Chen on first level support to debug their batch files?
Or rather, maybe, how bad are the initial support levels that couldn't figure out basic functionality like this and it was escalated to Chen?
Or maybe he was on a project working directly with the client already, so this was just part of whatever he was working on.
The post doesn’t mention a year. Early Microsoft Windows was very badly documented and the docs were difficult to search, so it wouldn't surprise me that it took senior level support to know that fact.
And there weren't tools like process monitor that showed way more about the state of what was running
i envy the folks who can actually make sense of msdn docs. they were tedious and overwhelming decades before ai made that the premiere style this year.
some parts are better than others, but god is it a quest to find anything in there.
> Or rather, maybe, how bad are the initial support levels that couldn't figure out basic functionality like this and it was escalated to Chen?
On something like Unix, I suspect this would be easy to figure out since programs typically dump diagnostic information to the terminal. On Windows, this would likely be thing learned through prior experience (especially since it would depend upon the program being launched).
He said that the program displayed an error message on the command line. That's diagnostic information dumped to the terminal.
Senior people like Raymond Chen (or at least the good ones) often get to where they are by doing some amount of work that's "below them" or outside their scope in order to keep their understanding of the full stack up to date.
It wouldn't surprise me if he's periodically snooping the lowest level support queues from time to time to understand what kinds of issues customers face, where the pain points are, etc, etc.
I was an engineer on the Visual Studio team. Many of the issues I worked on were things I found interesting. I wouldn't be surprised if Chen was browsing through open tickets, found this one, and grabbed it.
I'm pretty sure I heard Chen say on a podcast that he has a significant backlog of posts that he puts up when he feels like it.
There's probably a dozen posts at least for getting applications to find their dependencies because of one behavior or another. COM servers, .Net. Trying to get running apps to use an updated PATH or other environment variable.
I don't think this has anything to do with what you responded to?
I think the point is that he's not really active anymore, he's just relaying tales from his past.
I'd be very, very surprised if MS had Raymond motherfuckin' Chen looking at support queues in 2026.
He's telling stories from the past either way. The blog backlog isn't very important.
In an interview he said the backlog has varied from 3 to 18 months. Pretty negligible in terms of his career advancement. This isn't something he wrote ages ago.
Right... but my point was that even distinguished engineers at MS (lvl 70+) go "ticket diving" from time to time. It was somewhat contentious because juniors complained that all the "fun" tickets were taken by seniors.
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?
I am using my own combination file browser/terminal. I landed somewhat arbitrarily at the each tab has its own CWD (PathBuf field), ie how terminals do it. Not the only right answer, but has not been a blocker, and simplifies some things knowing there is [for that tab] a single CWD which can be used to manage bookmarks, assess if the we're in* a git repo, rust project etc.
This approach may present limitations later; will change A/R. But simple = good for now!
> 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.
Wouldn't you just have multiple explorer.exe windows open, each with a different folder open? Wouldn't that be similar to having multiple cmd.exe or Bash processes open, each with a different current directory?
The current directory in the UI is the directory open in whatever window you're clicking on.
That's a purer form of current directory than cmd, which has one per drive.
Yep, the first version of DOS wanted to be "like CP/M but on 8086 with a 640k address space" so it had drive letters and the second version wanted to be "like Unix but single user and with a funny memory model" so it had nested directories!
This just shows the command line was badly designed to begin with.
If CLI programs received already-opened file handles instead of pathname strings, most programs would have no need to have the concept of a "current directory" at all. It could be something purely internal to the command-line shell.
It would also be more fitting for a capability-based OS instead of one where every program has an ambient permission to access anything in the whole file system.
So am I, as a terminal user, supposed to track file handles now?
CLI programs might be used by an actual human, not necessarily called by a script.
UNIX/Linux already has a compromise here with stdin/stdout/stderr, the convention that those are fds 0, 1, and 2, and stream redirection in shells. You can already redirect raw fds in bash on linux, that's exactly what "something > something.stdout.txt 2> something.stderr.txt" does.
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".
Appreciating that this is not AI generated
[flagged]
Is this an article from 1997?