cvs commit: doc/en_US.ISO8859-1/articles/rc-scripting article.sgml

Yar Tikhiy yar at comp.chem.msu.su
Sun Mar 4 13:04:13 UTC 2007


On Sat, Mar 03, 2007 at 10:35:27PM -0800, Doug Barton wrote:
> Yar Tikhiy wrote:
> >yar         2007-03-03 10:11:34 UTC
> >
> >  FreeBSD doc repository
> >
> >  Modified files:
> >    en_US.ISO8859-1/articles/rc-scripting article.sgml 
> >  Log:
> >  Explain how an rc.d script can use extra command-line arguments.
> >  
> >  Revision  Changes    Path
> >  1.9       +138 -0    
> >  doc/en_US.ISO8859-1/articles/rc-scripting/article.sgml
> >
> >http://www.FreeBSD.org/cgi/cvsweb.cgi/doc/en_US.ISO8859-1/articles/rc-scripting/article.sgml.diff?&r1=1.8&r2=1.9&f=h
> 
> Yar,
> 
> This good stuff, thanks! I have one quibble with the last paragraph. 
> The shift in rc.subr isn't "apparent" as you phrase it, it's literal:

Yeah, I tried to hide a thing from the reader which he should already
have known: the shift command. :-)

> run_rc_command()
> {
>     ...
>     # Don't repeat the first argument when passing additional command-
>     # line arguments to the command subroutines.
>     #
>     shift 1
>     rc_extra_args="$*"

Oh my...  Now I see why existing rc.d scripts use this bogus command:

	run_rc_command "$*"

It's because rc.subr will mess up the arguments anyway.  Perhaps
we should investigate if "$@" can be used consistently to preserve
original boundaries between arguments to an rc.d script...  Now we
have little chance there as the final command is eval, which is the
ultimate killer of the original boundaries.  I'm uncertain if the
eval is really necessary to invoke rc.d methods.

>     ...
> 
> I would also put this information in the second paragraph, since as a 
> first time reader of your piece I had the question very early on. I 
> would say:
> 
> limits). The first command line parameter (start|stop|etc.) will be 
> shifted out by rc.subr, so what was $2 on the original command line 
> will become $1, and so on. Therefore the changes in the script itself ...

Thank you for this suggestion, it sounds very reasonable!

-- 
Yar


More information about the freebsd-rc mailing list