From 23ef79f4d438de6538ab9c7eb9b917c177671ece Mon Sep 17 00:00:00 2001 From: Yaroslav Tykhiy Date: Sun, 4 Mar 2007 13:33:06 +0000 Subject: [PATCH] Move the paragraphs on run_rc_command syntax and properties to above the example so that a reader can understand it better. Note current $* misuse in run_rc_command so that a reader who understands $@ and experiments with its application to run_rc_command isn't confused. Suggested by: dougb (1st explicitly and 2nd implicitly) --- .../articles/rc-scripting/article.sgml | 55 +++++++++++-------- 1 file changed, 32 insertions(+), 23 deletions(-) diff --git a/en_US.ISO8859-1/articles/rc-scripting/article.sgml b/en_US.ISO8859-1/articles/rc-scripting/article.sgml index 171dd0980b..d3e8679d0b 100644 --- a/en_US.ISO8859-1/articles/rc-scripting/article.sgml +++ b/en_US.ISO8859-1/articles/rc-scripting/article.sgml @@ -1187,8 +1187,28 @@ run_rc_command "$1" Fortunately, &man.rc.subr.8; allows for passing any number of arguments to script's methods (within the system limits). - Due to that, the changes in the script itself can be minimal. - To illustrate this opportunity, let us modify the primitive + Due to that, the changes in the script itself can be minimal. + + How can &man.rc.subr.8; gain + access to the extra command-line arguments. Should it just + grab them directly? Not by any means. Firstly, an &man.sh.1; + function has no access to the positional parameters of + its caller, but &man.rc.subr.8; is just a sack of such + functions. Secondly, the good manner of + rc.d dictates that it is for the + main script to decide which arguments are to be passed + to its methods. + + So the approach adopted by &man.rc.subr.8; is as follows: + run_rc_command passes on all its + arguments but the first one to the respective method verbatim. + The first, omitted, argument is the name of the method itself: + , , etc. It will + be shifted out by run_rc_command, + so what is $2 in the original command line will + be presented as $1 to the method, and so on. + + To illustrate this opportunity, let us modify the primitive dummy script so that its messages depend on the additional arguments supplied. Here we go: @@ -1264,23 +1284,10 @@ A ghost gives you a kiss and whispers: Once I was Etaoin Shrdlu... - The only question left is how &man.rc.subr.8; can gain - access to the extra command-line arguments. Should it just - grab them directly? Not by any means. Firstly, an &man.sh.1; - function has no access to the positional parameters of - its caller, but &man.rc.subr.8; is just a sack of such - functions. Secondly, the good manner of - rc.d dictates that it is for the - main script to decide which arguments are to be passed - to its methods. - - So the approach adopted by &man.rc.subr.8; is as follows: - run_rc_command passes on all its - arguments but the first one to the respective method verbatim. - The first, omitted, argument is the name of the method itself. - Consequently, if we want just to pass all extra arguments to + If we want just to pass all extra arguments to any method, we can merely substitute "$@" - for "$1" in the last line of our script. + for "$1" in the last line of our script, + where we invoke run_rc_command. An &man.sh.1; programmer ought to understand the @@ -1293,11 +1300,13 @@ A ghost gives you a kiss and whispers: Once I was Etaoin Shrdlu... buggy and insecure scripts. - The run_rc_command function will - consume its first argument to find the method. Hence an - apparent shift by one argument: What is $2 - in the command line will be presented as $1 - to the method, and so on. + + Currently run_rc_command may + have a bug that prevents it from keeping the original + boundaries between arguments. That is, arguments with + embedded whitespace may not be processed correctly. + The bug stems from $* misuse. +