[

...] foreach sec in

[

...] { foreach dir in --dir=dir1:dir2:.. { search for --rcfile where %s is parse rcfile into blocks according to --regex-section/etc. remember common/

into list } // we now have an unsorted list of common/

sort list of common/

according to their priority (see --regex-param) // execution forearch common/

in list { prepend config section prepend common section expand references accordingf to --regex-reference execute result as user/group (see --regex-param) with interpreter (see --regex-param) } } cd () { eval `rc --eval --rcfunc=$HOME/.cdfunc --rcfile-owner=$USER --rcfile-umask=022 --dir .:..:../..:../../.. --rcfile .cd all leave` builtin cd ${1+"$@"} eval `rc --eval --rcfunc=$HOME/.cdfunc --rcfile-owner=$USER --rcfile-umask=022 --dir .:..:../..:../../.. --rcfile .cd all enter` } # $HOME/.cdfunc AddPath () { ... } RemPath () { ... } # .cd %enter FOO=1 export FOO AddPath `pwd`/bin %leave unset FOO RemPath `pwd`/bin TODO: - error semantic: imediate faulure or skip failured - security => --rcfile-umask =pod =head1 NAME =over 4 B - OSSP Run Command Facility =back 4 =head1 SYNOPSIS =over 4 =item B @l_prefix@/etc/rc [B<-f>|B<--rcfile> I] [B<-d>|B<--rcdir> I[C<:>I[...]] [B<-C>|B<--rcconf> I[C<:>I[...]]] [B<-F>|B<--rcfunc> I[C<:>I[...]]] [B<-t>|B<--tmpdir> I] [B<-r>|B<--raw>] [B<-v>|B<--verbose>] [B<-D>|B<--debug>] [I] [I] [I] =item B @l_prefix@/etc/rc [I] [B<-x>|B<--exec>] [B<-p>|B<--print>] [B<-e>|B<--eval>] I I [I ...] =item B @l_prefix@/etc/rc [I] [B<-q>|B<--query>] I @l_prefix@/etc/rc [I] [B<-c>|B<--config>] [I] =item B @l_prefix@/etc/rc [I] [B<-i>|B<--info>] @l_prefix@/etc/rc [B<-h>|B<--help>] [B<-V>|B<--version>] =back 4 =head1 DESCRIPTION =over 4 B is a generic run-command processor. It applies the script code associated with a given section label to one or more given commands. The command(s) must each have entries in the form rc. including script code grouped into sections. OSSP rc references these command entries by reading the configuration file (see FILES) and searching the directory where the command entries reside. Each section of script code extends a type of functionality described by its section label. This label is the same one given before the desired command(s). Although only one section is possible for each call to OSSP rc, many `commands' can follow the section label. This allows for an abbreviated input format when calling the same script section of many commands. An example of this is given in `EXAMPLES.' =back 4 =head1 OPTIONS =over 4 !FIXME! Remark, difference between PARAMETER OPTIONS and COMMAND OPTIONS Inclusive options which may be used with another =item B<-c>, B<--config> F specify the location of the configuration file, overriding the environment variable C<$OSSP_RC_CONFIG> and the built-in hard-coded value. =item B<-n>, B<--func> F[C<:>F[...]] specify the location of an optional functions file, containing Bourne shell script code =item B<-f>, B<--file> F use the configuration and section data of a particular file =item B<-d>, B<--dirs> I[C<:>I[...] override OSSP_RC_ROOT, and use these paths instead =item B<-t>, B<--tmpdir> I specify the location of the temporary directory =item B<-v>, B<--verbose> verbosely report processing, including all warnings =item B<-s>, B<--silent> hold silence, and output no text messages whatsoever =item B<-d>, B<--debug> don't remove temporary files, and output debug messages to stderr =item B<-r>, B<--raw> output text using no terminal control sequences Mutually exclusive options, i.e. only a single one can be given =item B<-h>, B<--help> print this help, then exit =item B<-V>, B<--version> print version and copyright, then exit =item B<-p>, B<--print> output the text as it would be interpreted by the shell, but do not run the commands =item B<-e>, B<--eval> output the text for a command suitable for shell evaluation =item B<-x>, B<--exec> execute in subshell(s), follow with

=item B<-q>, B<--query> print the value(s) of rc configuration variables =item B<-l>, B<--labels> learn what section labels a run command offers =item B<-i>, B<--info> print a comprehensive summary of the rc environment All of these options have reasonable default values, which OSSP rc assumes when no option is otherwise given. For details of some listed option see `NOTES'. =back 4 =head1 NOTES =over 4 !FIXME! Remark, difference between PARAMETER OPTIONS and COMMAND OPTIONS =over 4 As expected, when B has output it will write ASCII text to F for normal output, and F for abnormal output (such as warnings and errors.) The options for controlling the output content are B<--config>, B<--help>, B<--version>, B<--verbose>, and B<--silent>. The option B<-r> or B<--raw> turns on raw output mode. In this case, no formatting is done to output text. This mode contrasts formatted output mode, in which the output is annotated with terminal control sequences for better readability. This option has no single default value. If the raw mode option is not specified, B will determine whether F is connected to a terminal. If so, B will run in formatted output mode. If F is not connected to a terminal (such as with most daemons,) B will run in raw output mode even though it was not specified as an option. =item B<-t>, B<--tmpdir> I Specifying this option will force B to use the given temporary directory I for all its temporary output. If this option is not given, B will try to use C<$TMPDIR>, C<$TEMPDIR>, C<~/tmp> and C (in that order.) =item B<-e>, B<--eval> and B<-p>, B<--print> The run command will not be executed. Rather, B will print a command suitable for later evaluation in the current shell. Given alone, this option will cause B to not execute the run command. Used together with B<--exec>, B will execute the run command and print a similar command for later execution as well. The B<--eval> option cannot be used together with B<--print>, because of conflicting output and the way that B constructs the evaluation text. Specifically, most Bourne shells and derivatives report errors with commands spanning multiple lines. Consider using the B<--eval> option for batch evaluation with the Bourne shell C command. Use the B<--print> option for better human readability. See `EXAMPLES' for an example. =item B<-x>, B<--exec> Exec is the most common option of all, in which B executes a run command made up of a given program and section. Options controlling the flow of execution include B<--print>, B<--eval>, and B<--exec>. When no option is given, B will default to B<--exec> and execute the run command directly. =item B<-q>, B<--query> Query the value of one or more configuration variables. These variables are set in the C<%config> section of the F<\.rc> file corresponding to a program. The B<--query> option may report a different value, however. It is possible for variable declarations in the F file to override those in the program's own rc file. Used with the B<--query> option, B will expect exactly one command line argument to follow. This must be a I string containing arbitrary text and optionally one or more B variable specifications ("C<${>IC<}>" in its simplest form.) =back 4 =head1 ENVIRONMENT =over 4 OSSP_RC_ROOT - Where the OSSP rc hierarchy is located OSSP_RC_OPTIONS - Options, same as the command line ones The environment determines where rc will look before beginning to process run commands. It also influences the behaviour, just as the command line options do. There is no difference between typing an option in the command line, and adding the same option to the OSSP_RC_OPTIONS variable. OSSP_RC_IMPLS - Other rc implementations The OSSP_RC_IMPLS variable plays a role only when the user has more than one logical set of run command sections. If rc reads anything but EOL in this variable, it will assume that more than one rc implementation exists. The variable should contain a chain of paths where other rc implementations are. This allows the user to build several OSSP rc hierarchies and then switch from each... Blah FIXME I don't know if we should be paying attention to the ENVIRONMENT guys. Maybe this is not a good solution for our dynamic OpenPKG environment problem after all. =back 4 =head1 FILES =over 4 /$OSSP_RC_ROOT/rc.conf - Configuration file =back 4 =head1 EXAMPLES Some short one line examples include the following. Note that a run command consists of a single program name and one or more sections. The wildcard `all' can be given in place of a program name to denote all programs with entries in the rc registry F<$OSSP_RC_ROOT/rc.d>. /usr/local/bin/rc --info /etc/rc --query lmtp2nntp /mybin/rc sshd start /etc/rc lmtp2nntp start /sfw/etc/rc --config /etc/rc.conf --debug smtpd stop /sfw/etc/rc --silent ntpd start sync stop start /usr/local/bin/rc httpd restart To evaluate a run command for all programs with an identical section name, a short expression can be written into a F<.profile> file. When the shell initializes itself, the run commands will execute according to the C command. This is often seen when importing the environment of packages of an B hierarchy. $ eval `@l_prefix@/etc/rc --eval all env` =head1 DIAGNOSTICS The exit status is 0 if rc was able to initiate the given section code of the given run command(s). If rc encountered an error during its processing, the exit status is indexed to the first command parameter which failed as ordered by the command line. This means that if rc returns 3, the third run command given on the command line failed. FIXME! Choose one interpretation: 1 This does not mean that only the third run command failed, however. It is possible that the fourth and sixth failed as well, for example. 2 Upon failure of any run command, OSSP rc halts and processes no more. Because of such a failure, a long batch of run commands may not be processed. This may be important with long run command batches or dependencies between run commands, so plan well when constructing the order of run commands on the command line. In case rc fails when only one run command is given, the exit status will be 1 as expected. If rc failed because of a broken run command hierarchy, the exit status will be -1. This can happen if a script file is moved or renamed, for example. If the run command hierarchy is broken, no further action is taken and no run commands are processed. =head1 SEE ALSO B integrates concepts taken from other run-command architectures. For more information, inspect the /etc/rc facilities provided by FreeBSD, NetBSD and Solaris. =head1 AUTHORS Ralf S. Engelschall Michael Schloh von Bennewitz =head1 HISTORY B was born to replace the prototype run-command facility used in the OpenPKG project (http://www.openpkg.org/). The prototype was a slow and less robust Bourne-Shell script. B is intended to replace it with a faster, more robust and flexible facility. =cut