Legal trap statement interpreted incorrectly

[geoff]

Configuration Information [Automatically generated, do not change]:
Machine: i586
OS: linux
Compiler: gcc -I/usr/src/packages/BUILD/bash-3.0 
-L/usr/src/packages/BUILD/bash-3.0/../readline-5.0
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i586' 
-DCONF_OSTYPE='linux' -DCONF_MACHTYPE='i586-suse-linux' -DCONF_VENDOR='suse' 
-DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H  -I.  
-I. -I./include -I./lib   -O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall 
-D_GNU_SOURCE -Wall -pipe -g -fbranch-probabilities
uname output: Linux bow 2.6.8-24.5-default #1 Wed Nov 17 11:10:06 UTC 2004 i686 
i686 i386 GNU/Linux
Machine Type: i586-suse-linux

Bash Version: 3.0
Patch Level: 0
Release Status: release

Description:
In sh mode the following legal command:

        trap 13

produces the somewhat comical error message:

        trap: usage: trap [-lp] [[arg] signal_spec ...]

(comical because it quite clearly states that the command is legal).

The command:

        trap 1 2 15

does not, although I have to wonder if it is interpreted as if "1"
were the command to be executed in case of signals 2 and 15...yup,
that is in fact the case:

        sh-3.00$ trap 1 2 15
        sh-3.00$ kill -15 $$
        sh: 1: command not found

Doing the same in bash mode produces no error message, but still
misinterprets the first signal-spec as an arg.

As far as I know, this all worked in earlier versions of bash.  At
least, it didn't produce error messages.

Workaround:  use constructs like

        trap "exit 0" 13
        trap "exit 1" 1 2 15

to achieve almost the same result.

Repeat-By:
        sh
        trap 13
        trap 1 2 15
        kill -15 $$