| From: | Ken Raeburn <raeburn@MIT.EDU> |
| Subject: | kinit exit status |
| Date: | Mon, 4 Feb 2008 17:27:31 -0500 |
| To: | krb5-bugs@MIT.EDU |
A suggestion from a discussion with Karl Ramm and Mark Eichin:
If kinit is interrupted with ^C, clear the SIGINT handler and re-kill
the process, so the exit status looks like it was killed with
SIGINT. Thus, a script can distinguish kinit failing because of a
bad password from kinit being killed with ^C and do different things
(e.g., retry only for the first). Re-raising a signal may not be
desirable behavior from the library code, but the application code
could do it, assuming the library API actually produces a distinct
error code in that case.
Or, just give a different exit status for ^C vs bad password. (But
do we want kdc-unreachable errors to be in a different category too?)
Ken
If kinit is interrupted with ^C, clear the SIGINT handler and re-kill
the process, so the exit status looks like it was killed with
SIGINT. Thus, a script can distinguish kinit failing because of a
bad password from kinit being killed with ^C and do different things
(e.g., retry only for the first). Re-raising a signal may not be
desirable behavior from the library code, but the application code
could do it, assuming the library API actually produces a distinct
error code in that case.
Or, just give a different exit status for ^C vs bad password. (But
do we want kdc-unreachable errors to be in a different category too?)
Ken