Date: Sun, 15 Oct 2006 01:58:05 +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: <20061014215804.GB15046@comp.chem.msu.su> In-Reply-To: <20061013012604.83513.qmail@web55110.mail.re4.yahoo.com> References: <20061012230423.GC72944@comp.chem.msu.su> <20061013012604.83513.qmail@web55110.mail.re4.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Oct 12, 2006 at 06:26:03PM -0700, David Thompson wrote: > --- Yar Tikhiy <yar@comp.chem.msu.su> wrote: > > 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. > > Since not all rc.d scripts *have* to be executed by /etc/rc, > a blurb that acknowledges that might satisfy things. With this > in mind, I actually prefer the original note, worded something > like this, > > Note: An rc.d script must be written in the sh(1) language, > although this is only true for scripts that are designed to > be invoked by /etc/rc. The reason is /etc/rc uses the sh(1) > '.' command to execute an rc.d script, thus the syntax of the > rc.d script must be sh(1). > > If you want to mention other details, like binary executables, or how > 'rcorder -s nostart' allows 'KEYWORD: nostart' comments in an rc.d > perl script, then this is good fodder for a follow-on paragraph, > > A special comment in your rc.d script can prevent /etc/rc > from trying to execute it. Add this comment line to your > rc.d script, the '#' must be column 1, > > # KEYWORD: nostart > > and your perl/python/ruby/sh rc.d script will be safely > skipped by /etc/rc. But since almost all rc.d scripts are > executed at system bootup, and therefore executed by /etc/rc, > using a language other than sh(1) is almost never an option. Telling truth, only truth, and nothing but truth, eh? ;-) All right, we shouldn't hide the truth from readers even if we dislike it -- I stand on this point, too, when somebody else attemts to violate it. :-) However, I really doubt that a non-sh(1) rc.d script will ever be accepted for the base system or ports. So in the last version I chose to explain the details but still discourage readers from using anything but sh(1). -- Yar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061014215804.GB15046>