ash init script with implicit "set -e"?

[Alexander Kriegisch]

I hope not to be off-topic or ask a question the anwer of which should
be obvious.

I noticed that my embedded system (WLAN/DSL router) stops booting if any
uncaught error occurs in my 'ash' init scripts. Is this the expected
behaviour for scripts running in a process not connected to a console
(no serial cable here, I can connect only later via telnet on pts)? It
seems to be as if I run "sh -e" or "set -e" within an interactive shell.
I am no expert on "init standards" if there is such a thing. In ash's
manual page I only found this paragraph:

> -e errexit
> If not interactive, exit immediately if any untested command fails.
> The exit status of a command is considered to be explicitly tested
> if the command is used to control an if, elif, while, or until;
> or if the command is the left hand operand of an ``&&'' or
> ``||'' operator.

This says what "-e" does in a non-interactive shell, but nothing about
if it is the default for a non-interactive shell. In my /etc/inittab I
just see rc.S being called, but there is no explicit "-e" there, nor is
there any in rc.S itself.

Now that I know that "-e" seems to be implicitly set, I can either do
something like
  <otherwise untested command> || true
or
  set +x; <untested command(s)>; set -x
but nonetheless I am curious and would like to know if this behaviour is
to be expected. Would it be a problem to set +x globally in an init
script or is it kind of mandatory for it to fail (sounds crazy, but I am
asking anyway)?

Enlighten me, please.
-- 
Alexander Kriegisch