Achim Sondermann sent me this bug report via email:

bug: /t accepts unlike MSDOS a value for c that wasn't set with /c, choice
retruns then errorlevel 1. But it would also return errorlevel 1 for the first
key set with /c. It should either return an error message (MSDOS does this) or
errorlevel 0 (since the "error-errorlevel" 1 is used for something different, an
error message would be better though).

Hmm... I thought I checked for this condition.  I'll double-check and fix it.

Yup, I checked for it ... then set the def_key to choices[0] if the user
default
in /T was not in the choice list.

Instead, I'll drop an error, and exit with 0.

-jh

Fixed in CHOICE 3.8

-jh

Achim (achim_sondermann@web.de) emailed me with this note:


I know, I suggested errorlevel 0 but it really has to be errorlevel 255.

"If CHOICE detects an error condition, it returns an ERRORLEVEL value of 255.
If the user presses CTRL+BREAK or CTRL+C, CHOICE returns an ERRORLEVEL value
of 0." quote from MS-DOS help: http://www.vfrazee.com/ms-dos/6.22/help/choice.htm

This seems to be broken in the latest release of CHOICE.  I'll re-open the bug.

Here's the test condition:



>choice /c:NH /T:Y,3
[NH]?




This has been broken since the version 3.8b release, which would drop an error
message:


>choice /c:NH /T:Y,3
CHOICE version 3.8, Copyright (C) 1994--2003 Jim Hall, jhall@freedos.org
Waits for the user to press a key, from a list of choices
Usage: CHOICE [ /B ] [ /C[:]choices ] [ /N ] [ /S ] [ /T[:]c,nn ] [ text ]
  /B            -  Sound an alert (beep) at prompt
  /C[:]choices  -  Specifies allowable keys.  Default is: yn
  /N            -  Do not display the choices at end of prompt
  /S            -  Be case-sensitive
  /T[:]c,nn     -  Automatically choose key c after nn seconds
  text          -  The text to display as a prompt

Reassigning bugs to Tom Ehlert, the new CHOICE maintainer.  -jh

This bug is fixed in CHOICE 4.3 of 6/2003, it even shows a
verbose error message if you try "choice /c:nh /t:y,3" now :-).