Small improvement of rc script makes big difference (bug report 35898)

Gerard Beekmans gerard at
Mon Jul 31 13:07:49 PDT 2000

> value from a prog called by the script, while I'm talking about non-zero
> return value from the script itself. Errors caused by progs called by the
> script are already covered by the usual "if [ $? != 0 ]". The problem is
> that scripts themselves are not covered by the rc script. See the
> difference?

Ok how does a script fail then? A script is just a text file that has a
bunch of commands that are executed in order. If a script fails it means
bash fails. A script won't fail if the commands won't fail. In my eyes a
script only fails when a command in that script fails, and those
failures are already detected. What more can be detected.

> No. It simply echoes the normal usage when loadproc is called without

that echo line will of course be modified if these new changes become

> EXACTLY! There are already a number of foreseen errors in sub-scripts that
> have been trapped: think about the *) case. In this case, the return value
> is 0, the the rc script doesn't trigger. The rc script modification is, and
> was always intended for, unforeseen errors that shouldn't happen.

Ok perhaps I haven't been clear enough and tried to explain things too
much and only confused the matter that way.

What I propose and I'll take sysklogd as an example.

If sysklogd echo's a failure (invalid usage or whatever will be added),
the rc echo lines will *not* be shown, since sysklogd's echo lines
already tell you why the error occured and now to fix it.

If I coded sysklogd and functions properly, sysklogd will not exit with
an error 1. If, however, it does, rc will trap it and print an error
(sicne when sysklogd traps an error the retval is reset to 0) saying
"unknown error in script $i blah blah try to fix with blah blah"

I guess I find it hard to explain this one, it's more in my head than I
can express. 

Gerard Beekmans

-*- If Linux doesn't have the solution, you have the wrong problem -*-
Mail archive:
IRC access: server: port: 6667 channel: #LFS
Unsubscribe: email lfs-discuss-request at and put
"unsubscribe" (without the quotation marks) in the body of the message
(no subject is required)

More information about the lfs-dev mailing list