$ getconf ARG_MAX
2097152
$ seq 30000 | wc -c
168894
$ /bin/true "`seq 30000`"
sh: 3: /bin/true: Argument list too long
$ /bin/true
sh: 4: getconf: Argument list too long
$

With a limit of 2 MB, I should have never got this error. This is a
serious limitation of dash, which prevents one from opening not very
large data with Firefox, where the "data:" URI is the recommended
solution.

This is not a bug in dash but either in the Linux kernel or in glibc.

The existence of MAX_ARG_STRLEN (see execve(2)) could be considered a
bug, since POSIX does not provide a hint that a limit on the length of
an individual argument may exist. However, it seems unlikely that this
bug will be fixed given that it has existed for so long already and was
deliberately introduced.

Alternatively, the bug is an incorrect return value from
sysconf(_SC_ARG_MAX). Given the existence of MAX_ARG_STRLEN, the value
returned should never be more than MAX_ARG_STRLEN (131072 on most
architectures), since that is the longest total length of arguments that
is guaranteed to avoid [E2BIG] errors.

The [E2BIG] from "/bin/true" by itself seems strange and does not match
the bug's descriptive text.

Actually such a limitation seems to be allowed by POSIX:

  [E2BIG]
    Argument list too long. The sum of the number of bytes used by
    the new process image's argument list and environment list is
    greater than the system-imposed limit of {ARG_MAX} bytes.
    or:
    Lack of space in an output buffer.
    or:
    Argument is greater than the system-imposed maximum.

This is the third case, but then, the error message is incorrect
("Argument list too long" corresponds to the first case). A glibc
bug in this case? There's the same message with bash and zsh.

Perhaps it made sense 10 years ago, but nowadays this limit is
rather ridiculous (makes me think of Microsoft's 640 KB limit).

Since POSIX allows such a system limit in addition to the total
size, I'd say that the sysconf value is correct, but the error
message is not the correct one (see above).

This problem seems to be specific to dash.

I think that condition is intended for different functions, since it is
mentioned in XSH 2.3 Error Numbers and not in the exec page in XSH 3
System Interfaces.

Although POSIX allows implementation-specific error conditions, they may
be a bad idea because they hinder portability.

I think this was that kind of limit, yes, although it introduced
dependency on gmake smarts years ago (in Linux, it's common for UTILITY
MANY_ARGS to be acceptable but sh -c 'UTILITY MANY_ARGS' to fail with
[E2BIG]).

In interactive mode outside functions, dash sets the variable _ to the
last argument after executing a simple command, but normally does not
export it. Both bash and zsh export the variable, though, so when dash
is started from bash or zsh, each command gets the last argument of the
previous command in its environment. This may cause [E2BIG] errors.

Bash and zsh set _ before running the command, so the program gets its
own last argument and it is unlikely [E2BIG] will occur that would not
have occurred without _.