mjhjmtu

I discovered a strange behaviour (reproducible with zsh and bash on my system):

$ # here everything is still normal
$ bash -c 'exit 1';echo $?
1
$ bash -c 'exit 255';echo $?
255
$ zsh -c 'exit 255';echo $?
255
$ # now it get's crazy
$ bash -c 'exit 256';echo $?
0
$ zsh -c 'exit 256';echo $?
0
$ # (leaving away zsh for now, it is always reproducible with both)
$ bash -c 'exit 257';echo $?
1
$ bash -c 'exit 267';echo $?
11

So after 256 it begins to count from 1 again. But why?

The bash man page does not indicate that there is a maximum number:

 exit [n]
 Cause the shell to exit with a status of n. If n is omitted,
 the exit status is that of the last command executed. A trap on
 EXIT is executed before the shell terminates.

And this is highly confusing behaviour. If programs depend on that, it could lead to big problems.

So why does this happen? And why is not it documented?

x64, Fedora 26

The POSIX manual page for the shell command exit(1p) states:

SYNOPSIS

exit [n]

DESCRIPTION

The exit utility shall cause the shell to exit with the exit status specified by the unsigned decimal integer n. If n is specified but its value is not between 0 and 255 inclusive, the exit status is undefined.

So for shells conforming to POSIX specifications, this behavior isn't undocumented, but it is also not necessarily portable.

It is documented in the manual of the exit system function:

The value of status may be 0, EXIT_SUCCESS, EXIT_FAILURE, [CX] [Option
Start] or any other value, though only the least significant 8 bits
(that is, status & 0377) shall be available to a waiting parent
process. [Option End]

Linux seems to stick to the standard very closely, and it doesn't let more than just the last 8 bits through.