@Mason-Wheeler said:
There's a .cmd debugger? Link plx?
echo on
(or@echo on
)
Meh, that's just tracing.
@Mason-Wheeler said:
There's a .cmd debugger? Link plx?
echo on
(or@echo on
)
Meh, that's just tracing.
@flabdablet said:
And cmd still got used well after those were released, mainly because cmd scripts are way, way easier to debug and usually considerably more concise.
There's a .cmd
debugger? Link plx?
@flabdablet said:
There are predefined environment variables that point to these things.
%APPDATA%
has the pathname of the root folder for per-user roamable application data, and%LOCALAPPDATA%
has the pathname of the root folder for per-user per-workstation local application data. Using the first where you should have used the second is just sloppy.
I would argue, rather, that the choice of names is sloppy. Of the two, %APPDATA%
is clearly "the default", and %LOCALAPPDATA%
requires extra work and something extra to know about. If people aren't supposed to put stuff in the roaming profile by default, they shouldn't have made it the default. They could just as easily have had %APPDATA%
be local application data, and %ROAMINGAPPDATA%
be for roaming app data, no?
@blakeyrat said:
The problem is none of this shit works, and when it fails (which is inevitably does), there's no fucking error messages.
The "solution" is a series of magical incantations involving deleting various folders of cached shit.
It's night-and-day with, say, MSBuild which is reliable like few other pieces of software.
Did you seriously just say that? I don't know what you've been building with MSBuild, but when any little thing goes wrong with the build configuration, you end up with nothing useful for tracking it down.
Not to mention it's all in XML, so you're already deep in "now you have two problems" territory before you even start...