winboard exit values

[Miguel A. Ballicora]

When winboard/exit returns a value as a command line, but it is not completely useful to be used in scripts. I am saying this because they are not documented (or I could not find them). Mainly, I would like to have a script that reloads winboard when there was a disconnection but not when I manually closed it. I peeked at the source code but it is not easy to follow all the possibilities. Anyway, it would be nice if those are documented and also different between file --> exit and a disconnection, whatever they will be.

Miguel

[H.G.Muller]

A quick browse through the source showed that closing by the user (through menus, system buttons or keyboard EOF), or after the last game in match mode, always should result in exit code 0. (After calling ExitEvent(0).) The other posisble exit codes are 1 and 2, from calling DisplayFatalError(..., ..., exitCode); I am not sure what difference they are supposed to indicate, and if this is indeed consistently done.

There is one exception, though, which is exactly the one you are complaining about: the fatal error "Connection Closed by ICS" is called with exitCode = 0. For some reason this was considered a normal exit, perhaps because it is the way you exit when you type "logout" in the console.

I am always reluctant to change things that seem to be done on purpose. It would be easy enough to use a unique code (e.g. 3) here in stead (in backend.c). To minimize the impact I should perhaps make that dependent on zippy mode being active? Engines are not supposed to log out, I guess. An alternative would be to add a command-line option -disconectionErrorCode N that by default would be 0, but which the user can set to other values, which would then be returned on disconnect.

I am not going to invest time to make an inventory of what exit codes are used and when. But of course others are welcome to do that, and even design a system of codes that would be more elaborate / useful or consistent. When such a system is proposed, I can add it to the documentation, or chnge the codes in the source accordingly.

[Miguel A. Ballicora]

A quick browse through the source showed that closing by the user (through menus, system buttons or keyboard EOF), or after the last game in match mode, always should result in exit code 0. (After calling ExitEvent(0).) The other posisble exit codes are 1 and 2, from calling DisplayFatalError(..., ..., exitCode); I am not sure what difference they are supposed to indicate, and if this is indeed consistently done.

There is one exception, though, which is exactly the one you are complaining about: the fatal error "Connection Closed by ICS" is called with exitCode = 0. For some reason this was considered a normal exit, perhaps because it is the way you exit when you type "logout" in the console.

I am always reluctant to change things that seem to be done on purpose. It would be easy enough to use a unique code (e.g. 3) here in stead (in backend.c). To minimize the impact I should perhaps make that dependent on zippy mode being active? Engines are not supposed to log out, I guess. An alternative would be to add a command-line option -disconectionErrorCode N that by default would be 0, but which the user can set to other values, which would then be returned on disconnect.

I think this would be easiest. Anyway, whatever you do, i should be fine since so far this is no documented and nobody should have trusted these numbers. I do not believe you will break any script written on this planet. But the option -disconnectionErrorCode should be very good.

I am not going to invest time to make an inventory of what exit codes are used and when. But of course others are welcome to do that, and even design a system of codes that would be more elaborate / useful or consistent. When such a system is proposed, I can add it to the documentation, or chnge the codes in the source accordingly.

I certainly did not mean to imply you should document it. In fact, I tried to dig into the source code with the purpose, but I feared I was going to be missing something. Some of this codes could be missed because they are hidden in functions and macros. I did not see any that was beyoond 0, 1, and 2. But it is difficult to list all the instances in which it would be 1 or 2, for example, if it is not done carefully.

Miguel

[H.G.Muller]

I guess the difference between 1 and 2 was intended to distinguish a startup error due to invalid parameters and an error later during excution. It would make sense to know in a script if it makes sense to try a restart with the same parameters.