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

This entry was posted in DDKWizard/DDKBUILD, EN, Programming, Software. Bookmark the permalink.

7 Responses to No reliable method, it seems

  1. fowl says:

    ‘where’ sets the errorlevel

    Vista+ only tho.

  2. Oliver says:

    Hi, and thanks for the hint. The idea seems to be similar to find or locate in Unix. but what I’d need would be either something like env (such as in /usr/bin/env perl) or which.

    // Oliver

  3. Oliver says:

    Okay, here’s the problem. After setting the environment, I get:

    %WLBASE%\bin\x86\amd64\build.exe
    %WLBASE%\bin\x86\build.exe
    %WLBASE%\tools\pfd\bin\bin\x86_AMD64\PREfast.exe
    %WLBASE%\tools\pfd\bin\bin\amd64\PREfast.exe

    NB: %WLBASE% is of course expanded in the output from where.

    // Oliver

  4. fowl says:

    Um… I just tried out your examples.

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

    and got this

    C:\Users\James\Desktop>test.cmd

    C:\Users\James\Desktop>program some parameters 1>NUL 2>&1 && echo Success

    C:\Users\James\Desktop>program some parameters 1>NUL 2>&1 || echo Failure
    Failure

    In fact C:\Users\James\Desktop>program some parameters > NUL 2>&1 && ( echo Success ) ||
    ( echo fail )
    fail

    C:\Users\James\Desktop>notepad > NUL 2>&1 && ( echo Success ) || ( echo fail )
    Success

    I suppose it’s possible they fixed it in 7 without telling anyone…

  5. Oliver says:

    Hmm, that’s interesting indeed. Is that x86 or x64?

  6. fowl says:

    x86

  7. Oliver says:

    OK, my machine is x64 (Vista), so this is one difference already. It’s good to hear it worked for you and I know it definitely worked a while ago to do this. But apparently it doesn’t anymore under all circumstances. I’ll further look at this a bit later.

    // Oliver

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.