No reliable method, it seems

With DDKBUILD I do have to tackle NT scripting issues every now and then. Now, most people don’t even recognize that NT scripting is not the same as Batch scripting. But the functionality of NT scripting is very limiting as well at times, although it goes well beyond the good old Batch scripting.

The reason I had to scrap revision 58 last night was that the detection of whether execution of a binary succeeded or failed is hard to do, if at all possible. Bad luck.

There should be several methods that all depend on the exit code of the executed program. They are all variations of each other. So let’s say you want to execute a program (not a builtin of the interpreter) named program (sorry, couldn’t come up with anything better – it’s late here ;)). Now we assume that program will be happy to answer how to use it, so that:

program /?

returns an exit code of 0 and thus ERRORLEVEL is being set to 0 after the call.

program /? > NUL 2>&1

would do the same but suppress the help output as well as any errors. So far so good. One easy way to check the ERRORLEVEL value on the same line is well known from Unix shells. But don’t let this similarity fool you – NT scripting is much more limited than any of the Unix shells I’ve worked with.

program some parameters > NUL 2>&1 && echo Success
program some parameters > NUL 2>&1 || echo Failure

The only problem is that if program does not exist (e.g. because it isn’t in the PATH) the ERRORLEVEL still won’t be set to any non-zero value. So there doesn’t seem to be any primitive to allow this check, which is done in many Unix shells like this:

[ -x program ] && echo "Success"
# Bash also allows:
[ -x program ] && {echo "Success";} || {echo "Failure";}

reliably and easy to remember …

Well, it just means that the DDKBUILD users will have to live with the fact that some errors are beyond what the script can possibly catch. I’m always trying to give the best error output possible, because an error means a nuisance already, but having to dig down to the cause is highly annoying. But here’s a limit I haven’t found any solution to just yet. Let me know if you happen to know one …

// Oliver