[quake3-bugzilla] [Bug 5080] [patch] code/sys/sys_unix.c:Sys_Dialog doesn't check exit codes properly

[bugzilla-daemon at icculus.org]

https://bugzilla.icculus.org/show_bug.cgi?id=5080

Simon McVittie <smcv-ioquake3 at pseudorandom.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smcv-ioquake3 at pseudorandom.
                   |                            |co.uk

--- Comment #1 from Simon McVittie <smcv-ioquake3 at pseudorandom.co.uk> 2011-07-15 04:01:49 EDT ---
Rather than second-guessing the shell's PATH search, it might be better to
expect particular exit codes, and treat everything else as an error? Sys_Zenity
etc. could return DR_OK, DR_CANCEL or a new DR_ERROR, and do appropriate
processing on the return from system() before they return.

Zenity exits 0 for OK, 1 for cancel, -1 on unexpected error (which probably
comes out as 127 or 255 from system()), 5 on timeout (not relevant to us). So
we could treat 0 as OK/yes, 1 as cancel/no and anything else as error.

xmessage exits 0 for OK, 1 for error, and (as we invoke it) also 1 for cancel
(oops). We should probably change the command line options so it exits 2 for
cancel, and treat 0 as OK/yes, 2 as cancel/no and anything else as error.

kdialog doesn't document its exit codes, but is probably the same as dialog(1),
which exits 0 on OK/yes, 1 on cancel/no, 2 or 3 on buttons we never actually
use, and -1 on internal error or exiting via pressing ESC (but ESC can be
mapped to something less ambiguous with the DIALOG_ESC environment variable).

If a command isn't found, bash will use 127 (not found) or 126 (found but
cannot be executed). dash (Debian/Ubuntu /bin/sh) doesn't document what exit
code it will use, but it appears to be 127.

-- 
Configure bugmail: https://bugzilla.icculus.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.