@tokumaru I'm sorry, I politely disagree. Please look at what the OP was doing in their first post, then tell me they're going to write a "complex" .bat/cmd file. Come on, man. They're not ready for that.
I feel your one-liner simplifies something without thinking of the bigger picture, such as assembly or link-time errors, or even third-party programs that manipulate data. Double-clicking a .bat/cmd file will teach the user nothing about the troubleshooting process -- they see a little black window that pops up and then disappears. You and I both know that doesn't mean something worked. You can try to handle errors -- assuming *every single tool being used* does the right thing with
exit codes/errorlevel and implementing a conditional
pause so they can see the last thing that errored, and that's a Windows batch/cmd thing that even skilled people still continue to get wrong (
if you think I'm kidding, followed by
similar madness) -- and that the user has the familiarity with writing such scripts to begin with. Don't mention PowerShell either, because that just complicates the matter even further.
I stand firm on my statement: the developer must get used to the CLI. Trying to avoid it is just asking for trouble, and the result will be literally hours of wasted time asking people here on this forum for what amounts to writing-Windows-batch-file support. Once the developer is familiar with the
manually-induced basics, they can make their life easier with a batch file by doing so gradually -- but my above paragraph will prove true the instant they get an error or encounter an anomalous situation.
Visual Studio and the like can sometimes relieve some of this, but that's not the same platform or the same tools. (cpow/nesicide author is probably grinning right now ;-) )