igully's errlevel.bat and sel.com are working too (from post Re: how can i read the byte from the HEX location with batch commands?)

1if errorlevel 1

or

1if %errorlevel% neq 0

In real life, is the latter supposed to be more sure way to detect failures? Just in case the program decides to return negative number? Is there a rule when should the number be negative?

AI thinks I should use the first variant instead of second, but I'm not sure if that's right. I figured automated building of software at work has some holes, the holes being missing checks for such failures in certain places, so it may fail at later point or silently in a way that nothing looks wrong, but then you install the program and figure parts of it are missing.

The tools involved are nuget, MSBuild, signtool and Inno Setup Compiler.

Considering one BAT file runs a bunch of MSBuild commands to build programs, I suppose errorlevel check after every one of them is the only way to bailout if any command fails?

Edit: OK, I read that site, so considering possibility of number of exceptions to common conventions, there is no general. Although presumably, statistically, it may be better to be doing if %errorlevel% neq 0 to catch failures.

I assume you are talking about modern (well, modern as of 1995) NT cmd with Command Extensions. The latter syntax wouldn't have been available with DOS COMMAND.COM. if errorlevel matching the specified value or higher is counterintuitive to people even today, so that might explain the latter one.

Traditionally the exit code is interpreted as an unsigned byte value so -1 would be 255 and so forth, so you would not need to worry about negative numbers. EXIT_FAILURE in <stdlib.h> is often defined as -1, so checking for positive exit codes to indicate failure should be very well-tested already.

On Unix sh, there is an option (-e) to cause the script to exit immediately if anything inside returns an unsuccessful exit code. I am not sure if cmd has something like that.

I edited the post, but yeah, obviously dealing with modern NT CMD.

So basically, CMD brought possibility of negative numbers, so theoretically, you may encounter a tool that uses them and without knowing tools you're dealing with deeply, I suppose there is no general answer.

Though one wonders how much tools may intentionally use negative numbers.

I seem to remember examples of simple C programs that simply return 1 from main if something went wrong.

I don't believe negative numbers will be possible even with cmd. That exit codes are unsigned is a pretty strong convention. I believe VMS may have had the opposite convention where 0 was failure and 1 was success--that is why C gives you EXIT_SUCCESS and EXIT_FAILURE constants--and EXIT_FAILURE is -1 for dos/windows/unix yet if errorlevel 1 is tried and true anyway. I think it really comes down to people not remembering that 'if errorlevel 1' catches everything nonzero, and isn't checking for 1, and that wanting to distinguish exit codes requires that you test them in descending order. That is probably where they if eq and if neq came from, not that if errorlevel 1 doesn't work. People have long been frustrated with the hacks used in batch programming, like using ping 127.0.0.1 to introduce a delay.

Negative numbers seem to work fine in CMD. You can try with two batch files:

Main:

1call negativeError.bat
2if %errorlevel% equ -6 exit /b 1
3exit /b 0

Content of negativeError.bat:

1exit /b -6

If you replace if %errorlevel% equ-6 with if errorlevel 1, result of calling main should be 0, otherwise, it will be 1. Since it checks if negativeError.bat returns -6, it then exits with 1, otherwise exits with 0.

Jenkins at the very least considers the BAT file that finished with non-0 value a failure. I'll probably just stick with "non-zero" checks rather than "1 or greater" checks.

OK, you are right that cmd interprets exit codes as signed even though msdn ExitProcess() says they are unsigned.
Accordingly, exit /b 2147483648 through exit /b 4294967295, in the rare instance that anything uses those, will also produce a "negative" exit code.
EXIT_SUCCESS and EXIT_FAILURE are indeed 0 and 1 so anything following those, per ANSI C, correctly use a "positive" exit code.
I have seen exit(-1) and such used on Unix platforms sometimes. There, the exit code gets truncated to an 8-bit unsigned number and so -1 turns into positive 255.

&& and || do work correctly even with negative exit codes. cmd /c exit -1 || echo failure, for instance.

edit: incidentally, MS-DOS 6.22 treats -1 as 255 as well... so NT cmd switching to signed apparently hasn't been an issue all these years