Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 13 Oct 2006 03:04:23 +0400
From:      Yar Tikhiy <yar@comp.chem.msu.su>
To:        David Thompson <dat1965@yahoo.com>
Cc:        freebsd-rc@freebsd.org
Subject:   Re: Revised article on rc.d
Message-ID:  <20061012230423.GC72944@comp.chem.msu.su>
In-Reply-To: <20061010015619.3492.qmail@web55109.mail.re4.yahoo.com>
References:  <20061009122342.GB2805@comp.chem.msu.su> <20061010015619.3492.qmail@web55109.mail.re4.yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Oct 09, 2006 at 06:56:19PM -0700, David Thompson wrote:
> --- Yar Tikhiy <yar@comp.chem.msu.su> wrote:
> > After a long delay, I got down to my article on rc.d again.  Many
> > thanks to Gary W. Swearingen for his valuable remarks.  The new
> > version is available at http://people.freebsd.org/~yar/rcng/ .  I
> > think this version can be added to our articles collection after a
> > few corrections that may be suggested by the readers. ;-)
> 
> Regarding this paragraph,
> 
>   Note: An rc.d script must be written in the sh(1) language. It
>   cannot be a binary executable because rc.d can opt to feed such
>   scripts into a single instance of sh(1) instead of running each
>   of them separately. This is controlled by an rc.conf(5) variable
>   named rc_fast_and_loose. An rc.d script cannot be written in
>   awk(1) or an interpreted language from ports for the same reason;
>   in addition, it must be runnable early in the system startup
>   sequence, before /usr has been mounted.
> 
> This caveat is not really true in the strict technical sense.
> Consider if someone adds this line to their /etc/rc.d script,
> 
>   # KEYWORD: nostart
> 
> then /etc/rc will not execute this script since rcorder is
> invoked with '-s nostart'.  Thus the reasoning due to the
> $rc_fast_and_loose variable is not strictly accurate.  That
> is, a script could technically be written in any interpreted
> language that happens to use '#' as its comment character;
> as long as the above comment line was added to the script.
> The problem is, of course, such scripts have to provide their
> own scaffolding, since rc.subr is written in sh(1); and the
> script cannot be run directly by /etc/rc due to the use of the
> sh(1) dot '.' operator (thus it needs 'KEYWORD: nostart' so
> that /etc/rc will skip it).
> 
> Although not exactly clear in the above paragraph, the reason
> files in /etc/rc.d cannot be binary is because rc.d uses the
> sh(1) dot '.' operator *for all* invocations, like this,
> 
>         if [ -n "$rc_fast_and_loose" ]; then
>             set $_arg; . $_file
>         else
>             ( trap "echo Script $_file interrupted; kill -QUIT $$" 3
>               trap "echo Script $_file interrupted; exit 1" 2
>               set $_arg; . $_file )
>         fi
> 
> But for '.', files in /etc/rc.d *could* be binary, but
> even then rcorder expects to process text files, not binary
> files.  rcorder uses fparseln() to read each file, but this
> doesn't really affect reading a binary file.  Thus rcorder
> processes binary files benignly, try 'rcorder /bin/*' and
> you'll see consistent output.
> 
> Also in that paragraph, when I read this,
> 
>   ... a binary executable because rc.d can opt to feed ...
>                                   ^^^^
> IMHO, it should probably say,
> 
>   ... a binary executable because /etc/rc can opt to feed ...
>                                   ^^^^^^^
> though I understand you're referring to the rc.d system,
> some clarity is gained in that sentence by using /etc/rc.

I'd sum all the above up as follows: I went on slippery ground
when trying to give reasons for using sh(1) and only sh(1) :-)
How about the following paragraph as a replacement?

	Note: The language of choice for rc.d scripting is sh(1).
	The tight integration between all rc.d components effectively
	prevents individual scripts from being written in a different
	language.

-- 
Yar



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061012230423.GC72944>