The translation is temporarily closed for contributions due to maintenance, please come back later.

Translation

(itstool) path: informalexample/programlisting
English
#!/bin/sh<co xml:id="rcng-dummy-shebang"/>

. /etc/rc.subr<co xml:id="rcng-dummy-include"/>

name="dummy"<co xml:id="rcng-dummy-name"/>
start_cmd="${name}_start"<co xml:id="rcng-dummy-startcmd"/>
stop_cmd=":"<co xml:id="rcng-dummy-stopcmd"/>

dummy_start()<co xml:id="rcng-dummy-startfn"/>
{
echo "Nothing started."
}

load_rc_config $name<co xml:id="rcng-dummy-loadconfig"/>
run_rc_command "$1"<co xml:id="rcng-dummy-runcommand"/>
432/4320 · 432
Context English Spanish State
The real problem with the monolithic approach was that it provided no control over the individual components started from <filename>/etc/rc</filename>. For instance, <filename>/etc/rc</filename> could not restart a single daemon. The system admin had to find the daemon process by hand, kill it, wait until it actually exited, then browse through <filename>/etc/rc</filename> for the flags, and finally type the full command line to start the daemon again. The task would become even more difficult and prone to errors if the service to restart consisted of more than one daemon or demanded additional actions. In a few words, the single script failed to fulfil what scripts are for: to make the system admin's life easier. El verdadero problema con el enfoque monolítico era que no proporcionaba control sobre los componentes individuales a partir de <filename>/etc/rc</filename>. Por ejemplo, <filename>/etc/rc</filename> no se pudo reiniciar un solo demonio. El administrador del sistema tuvo que encontrar el proceso del demonio a mano, matarlo, esperar hasta que realmente saliera y luego examinar <filename>/etc/rc</filename> para las banderas, y finalmente escriba la línea de comando completa para iniciar el demonio nuevamente. La tarea se volvería aún más difícil y propensa a errores si el servicio a reiniciar consistiera en más de un demonio o exigiera acciones adicionales. En pocas palabras, el único script no cumplió con el propósito de los scripts: facilitar la vida del administrador del sistema.
Later there was an attempt to split out some parts of <filename>/etc/rc</filename> for the sake of starting the most important subsystems separately. The notorious example was <filename>/etc/netstart</filename> to bring up networking. It did allow for accessing the network from single-user mode, but it did not integrate well into the automatic startup process because parts of its code needed to interleave with actions essentially unrelated to networking. That was why <filename>/etc/netstart</filename> mutated into <filename>/etc/rc.network</filename>. The latter was no longer an ordinary script; it comprised of large, tangled <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> functions called from <filename>/etc/rc</filename> at different stages of system startup. However, as the startup tasks grew diverse and sophisticated, the <quote>quasi-modular</quote> approach became even more of a drag than the monolithic <filename>/etc/rc</filename> had been. Más tarde hubo un intento de dividir algunas partes de <filename>/etc/rc</filename>con el fin de iniciar los subsistemas más importantes por separado. El ejemplo notorio fue <filename>/etc/netstart</filename>para sacar a relucir el networking. Permitió acceder a la red desde el modo de usuario único, pero no se integró bien en el proceso de inicio automático porque algunas partes de su código debían intercalarse con acciones esencialmente no relacionadas con la red. Por eso<filename>/etc/netstart</filename> mutado en <filename>/etc/rc.network</filename>. Este último ya no era un guión ordinario; se compone de grandes, enredados <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> funciones llamadas desde <filename>/etc/rc</filename> en diferentes etapas del inicio del sistema. Sin embargo, a medida que las tareas de inicio se volvieron diversas y sofisticadas, el <quote>quasi-modular</quote> enfoque se convirtió en un lastre incluso más que el monolítico <filename>/etc/rc</filename> había sido.
Without a clean and well-designed framework, the startup scripts had to bend over backwards to satisfy the needs of rapidly developing BSD-based operating systems. It became obvious at last that more steps are necessary on the way to a fine-grained and extensible <filename>rc</filename> system. Thus BSD <filename>rc.d</filename> was born. Its acknowledged fathers were Luke Mewburn and the NetBSD community. Later it was imported into FreeBSD. Its name refers to the location of system scripts for individual services, which is in <filename>/etc/rc.d</filename>. Soon we will learn about more components of the <filename>rc.d</filename> system and see how the individual scripts are invoked. Sin un marco limpio y bien diseñado, los scripts de inicio tuvieron que hacer todo lo posible para satisfacer las necesidades de los sistemas operativos basados en BSD en rápido desarrollo. Por fin se hizo evidente que se necesitan más pasos en el camino hacia una estructura fina y extensible. <filename>rc</filename> sistema. Así BSD<filename>rc.d</filename> nació. Sus padres reconocidos fueron Luke Mewburn y la comunidad NetBSD. Posteriormente se importó a FreeBSD. Su nombre se refiere a la ubicación de los scripts del sistema para servicios individuales, que se encuentra en <filename>/etc/rc.d</filename>. Pronto conoceremos más componentes de la <filename>rc.d</filename> sistema y ver cómo se invocan los scripts individuales.
The basic ideas behind BSD <filename>rc.d</filename> are <emphasis>fine modularity</emphasis> and <emphasis>code reuse</emphasis>. <emphasis>Fine modularity</emphasis> means that each basic <quote>service</quote> such as a system daemon or primitive startup task gets its own <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> script able to start the service, stop it, reload it, check its status. A particular action is chosen by the command-line argument to the script. The <filename>/etc/rc</filename> script still drives system startup, but now it merely invokes the smaller scripts one by one with the <option>start</option> argument. It is easy to perform shutdown tasks as well by running the same set of scripts with the <option>stop</option> argument, which is done by <filename>/etc/rc.shutdown</filename>. Note how closely this follows the Unix way of having a set of small specialized tools, each fulfilling its task as well as possible. <emphasis>Code reuse</emphasis> means that common operations are implemented as <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> functions and collected in <filename>/etc/rc.subr</filename>. Now a typical script can be just a few lines' worth of <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> code. Finally, an important part of the <filename>rc.d</filename> framework is <citerefentry><refentrytitle>rcorder</refentrytitle><manvolnum>8</manvolnum></citerefentry>, which helps <filename>/etc/rc</filename> to run the small scripts orderly with respect to dependencies between them. It can help <filename>/etc/rc.shutdown</filename>, too, because the proper order for the shutdown sequence is opposite to that of startup. Las ideas básicas detrás de BSD <filename>rc.d</filename> son <emphasis>fina modularidad</emphasis> Y <emphasis>reutilización de código</emphasis>. <emphasis>Fina modularidad</emphasis> Significa que cada básico <quote>servicio</quote> como un demonio del sistema o una tarea de inicio primitiva, obtiene su propia <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> script capaz de iniciar el servicio, detenerlo, recargarlo, verificar su estado. Una acción particular se elige mediante el argumento de la línea de comandos del script. los <filename>/etc/rc</filename> El script todavía impulsa el inicio del sistema, pero ahora simplemente invoca los scripts más pequeños uno por uno con el <option>start</option> argumento. También es fácil realizar tareas de apagado ejecutando el mismo conjunto de scripts con el <option>stop</option> argumento, que es hecho por <filename>/etc/rc.shutdown</filename>. Tenga en cuenta lo cerca que sigue la forma Unix de tener un conjunto de pequeñas herramientas especializadas, cada una cumpliendo su tarea lo mejor posible. <emphasis>Reutilización de código</emphasis> significa que las operaciones comunes se implementan como <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> funciones y recogidas en <filename>/etc/rc.subr</filename>. Ahora, un script típico puede tener solo unas pocas líneas de <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> código. Finalmente, una parte importante de la <filename>rc.d</filename> marco es <citerefentry><refentrytitle>rcorder</refentrytitle><manvolnum>8</manvolnum></citerefentry>, que ayuda <filename>/etc/rc</filename>para ejecutar los pequeños scripts de forma ordenada con respecto a las dependencias entre ellos. Puede ayudar <filename>/etc/rc.shutdown</filename>, también, porque el orden correcto para la secuencia de apagado es opuesto al de inicio.
The BSD <filename>rc.d</filename> design is described in <link linkend="lukem">the original article by Luke Mewburn</link>, and the <filename>rc.d</filename> components are documented in great detail in <link linkend="manpages">the respective manual pages</link>. However, it might not appear obvious to an <filename>rc.d</filename> newbie how to tie the numerous bits and pieces together in order to create a well-styled script for a particular task. Therefore this article will try a different approach to describe <filename>rc.d</filename>. It will show which features should be used in a number of typical cases, and why. Note that this is not a how-to document because our aim is not at giving ready-made recipes, but at showing a few easy entrances into the <filename>rc.d</filename> realm. Neither is this article a replacement for the relevant manual pages. Do not hesitate to refer to them for more formal and complete documentation while reading this article. El BSD <filename>rc.d</filename> el diseño se describe en <link linkend="lukem">el artículo original de Luke Mewburn</link>, y el <filename>rc.d</filename> Los componentes están documentados con gran detalle en <link linkend="manpages">las respectivas páginas del manual</link>.Sin embargo, puede que no parezca obvio para un <filename>rc.d</filename> novato cómo unir las numerosas partes y piezas para crear un guión con estilo para una tarea en particular. Por lo tanto, este artículo intentará un enfoque diferente para describir <filename>rc.d</filename>.Mostrará qué funciones deben usarse en varios casos típicos y por qué. Tenga en cuenta que este no es un documento de instrucciones porque nuestro objetivo no es dar recetas listas para usar, sino mostrar algunas entradas fáciles al <filename>rc.d</filename> reino. Este artículo tampoco sustituye a las páginas del manual correspondientes. No dude en consultarlos para obtener documentación más formal y completa mientras lee este artículo.
There are prerequisites to understanding this article. First of all, you should be familiar with the <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> scripting language in order to master <filename>rc.d</filename>. In addition, you should know how the system performs userland startup and shutdown tasks, which is described in <citerefentry><refentrytitle>rc</refentrytitle><manvolnum>8</manvolnum></citerefentry>. Hay requisitos previos para comprender este artículo. En primer lugar, debe estar familiarizado con el <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> lenguaje de secuencias de comandos para dominar <filename>rc.d</filename>. Además, debe saber cómo realiza el sistema las tareas de inicio y apagado del área de usuario, que se describe en <citerefentry><refentrytitle>rc</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
This article focuses on the FreeBSD branch of <filename>rc.d</filename>. Nevertheless, it may be useful to NetBSD developers, too, because the two branches of BSD <filename>rc.d</filename> not only share the same design but also stay similar in their aspects visible to script authors. Este artículo se centra en la rama FreeBSD de <filename>rc.d</filename>. Sin embargo, también puede ser útil para los desarrolladores de NetBSD, porque las dos ramas de BSD <filename>rc.d</filename> no solo comparten el mismo diseño, sino que también son similares en sus aspectos visibles para los autores de guiones.
Outlining the task Delineando la tarea
A little consideration before starting <envar>$EDITOR</envar> will not hurt. In order to write a well-tempered <filename>rc.d</filename> script for a system service, we should be able to answer the following questions first: Un poco de consideración antes de empezar <envar>$EDITOR</envar> no Dolera. Para escribir un buen temperamento <filename>rc.d</filename> script para un servicio del sistema, deberíamos poder responder las siguientes preguntas primero:
Is the service mandatory or optional? ¿El servicio es obligatorio u opcional?
Will the script serve a single program, e.g., a daemon, or perform more complex actions? ¿El script servirá a un solo programa, por ejemplo, un demonio, o realizará acciones más complejas?
Which other services will our service depend on, and vice versa? ¿De qué otros servicios dependerá nuestro servicio y viceversa?
From the examples that follow we will see why it is important to know the answers to these questions. De los ejemplos que siguen veremos por qué es importante conocer las respuestas a estas preguntas.
A dummy script Un guión ficticio
The following script just emits a message each time the system boots up: El siguiente script simplemente emite un mensaje cada vez que se inicia el sistema:
#!/bin/sh<co xml:id="rcng-dummy-shebang"/>

. /etc/rc.subr<co xml:id="rcng-dummy-include"/>

name="dummy"<co xml:id="rcng-dummy-name"/>
start_cmd="${name}_start"<co xml:id="rcng-dummy-startcmd"/>
stop_cmd=":"<co xml:id="rcng-dummy-stopcmd"/>

dummy_start()<co xml:id="rcng-dummy-startfn"/>
{
echo "Nothing started."
}

load_rc_config $name<co xml:id="rcng-dummy-loadconfig"/>
run_rc_command "$1"<co xml:id="rcng-dummy-runcommand"/> 		#!/bin/sh<co xml:id="rcng-dummy-shebang"/>

. /etc/rc.subr<co xml:id="rcng-dummy-include"/>

name="dummy"<co xml:id="rcng-dummy-name"/>
start_cmd="${name}_start"<co xml:id="rcng-dummy-startcmd"/>
stop_cmd=":"<co xml:id="rcng-dummy-stopcmd"/>

dummy_start()<co xml:id="rcng-dummy-startfn"/>
{
echo "Nothing started."
}

load_rc_config $name<co xml:id="rcng-dummy-loadconfig"/>
run_rc_command "$1"<co xml:id="rcng-dummy-runcommand"/>
Things to note are: Las cosas a tener en cuenta son:
An interpreted script should begin with the magic <quote>shebang</quote> line. That line specifies the interpreter program for the script. Due to the shebang line, the script can be invoked exactly like a binary program provided that it has the execute bit set. (See <citerefentry><refentrytitle>chmod</refentrytitle><manvolnum>1</manvolnum></citerefentry>.) For example, a system admin can run our script manually, from the command line: Un guión interpretado debe comenzar con la magia <quote>shebang</quote> línea. Esa línea especifica el programa intérprete del guión. Debido a la línea shebang, el script puede invocarse exactamente como un programa binario siempre que tenga el bit de ejecución establecido. (Ver <citerefentry><refentrytitle>chmod</refentrytitle><manvolnum>1</manvolnum></citerefentry>.) Por ejemplo, un administrador del sistema puede ejecutar nuestro script manualmente, desde la línea de comando:
<prompt>#</prompt> <userinput>/etc/rc.d/dummy start</userinput> <prompt>#</prompt> <userinput>/etc/rc.d/dummy start</userinput>
In order to be properly managed by the <filename>rc.d</filename> framework, its scripts need to be written in the <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> language. If you have a service or port that uses a binary control utility or a startup routine written in another language, install that element in <filename>/usr/sbin</filename> (for the system) or <filename>/usr/local/sbin</filename> (for ports) and call it from a <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> script in the appropriate <filename>rc.d</filename> directory. Para ser adecuadamente gestionado por el <filename>rc.d</filename> framework, sus scripts deben estar escritos en el <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> idioma. Si tiene un servicio o puerto que utiliza una utilidad de control binario o una rutina de inicio escrita en otro idioma, instale ese elemento en <filename>/usr/sbin</filename> (para el sistema) o <filename>/usr/local/sbin</filename>(para puertos) y llámalo desde un <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> guión en el apropiado<filename>rc.d</filename> directorio.
If you would like to learn the details of why <filename>rc.d</filename> scripts must be written in the <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> language, see how <filename>/etc/rc</filename> invokes them by means of <function>run_rc_script</function>, then study the implementation of <function>run_rc_script</function> in <filename>/etc/rc.subr</filename>. Si desea conocer los detalles de por qué <filename>rc.d</filename> Los guiones deben estar escritos en el <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry>idioma, mira como <filename>/etc/rc</filename> Los invoca mediante <function>run_rc_script</function>, luego estudiar la implementación de <function>run_rc_script</function> en <filename>/etc/rc.subr</filename>.
In <filename>/etc/rc.subr</filename>, a number of <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> functions are defined for an <filename>rc.d</filename> script to use. The functions are documented in <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry>. While it is theoretically possible to write an <filename>rc.d</filename> script without ever using <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry>, its functions prove extremely handy and make the job an order of magnitude easier. So it is no surprise that everybody resorts to <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry> in <filename>rc.d</filename> scripts. We are not going to be an exception. En <filename>/etc/rc.subr</filename>,un numero de <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> las funciones se definen para un <filename>rc.d</filename>script para usar. Las funciones están documentadas en <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry>. Si bien es teóricamente posible escribir un <filename>rc.d</filename> script sin usar <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry>,sus funciones resultan extremadamente útiles y facilitan el trabajo en un orden de magnitud. Así que no es de extrañar que todo el mundo recurra a <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry> in <filename>rc.d</filename> scripts. No vamos a ser una excepción.
An <filename>rc.d</filename> script must <quote>source</quote> <filename>/etc/rc.subr</filename> (include it using <quote><command>.</command></quote>) <emphasis>before</emphasis> it calls <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry> functions so that <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> has an opportunity to learn the functions. The preferred style is to source <filename>/etc/rc.subr</filename> first of all. un <filename>rc.d</filename> script debe <quote>source</quote> <filename>/etc/rc.subr</filename> (incluirlo usando<quote><command>.</command></quote>) <emphasis>antes</emphasis> de llamarlo <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry> funciona para que <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> tiene la oportunidad de aprender las funciones. El estilo preferido es fuente <filename>/etc/rc.subr</filename> ante todo.
Some useful functions related to networking are provided by another include file, <filename>/etc/network.subr</filename>. Algunas funciones útiles relacionadas con las redes son proporcionadas por otro archivo de inclusión, <filename>/etc/network.subr</filename>.
<anchor xml:id="name-var"/>The mandatory variable <envar>name</envar> specifies the name of our script. It is required by <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry>. That is, each <filename>rc.d</filename> script <emphasis>must</emphasis> set <envar>name</envar> before it calls <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry> functions. <anchor xml:id="name-var"/>La variable obligatoria <envar>name</envar> especifica el nombre de nuestro script. Es requerido por <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry>. Es decir, cada <filename>rc.d</filename> script <emphasis>must</emphasis> set <envar>name</envar> antes de que llame <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry> funciones.
Now it is the right time to choose a unique name for our script once and for all. We will use it in a number of places while developing the script. For a start, let us give the same name to the script file, too. Ahora es el momento adecuado para elegir un nombre único para nuestro script de una vez por todas. Lo usaremos en varios lugares mientras desarrollamos el guión. Para empezar, démosle también el mismo nombre al archivo de script.
The current style of <filename>rc.d</filename> scripting is to enclose values assigned to variables in double quotes. Keep in mind that it is just a style issue that may not always be applicable. You can safely omit quotes from around simple words without <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> metacharacters in them, while in certain cases you will need single quotes to prevent any interpretation of the value by <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry>. A programmer should be able to tell the language syntax from style conventions and use both of them wisely. El estilo actual de <filename>rc.d</filename> la secuencia de comandos consiste en encerrar los valores asignados a las variables entre comillas dobles. Tenga en cuenta que es solo una cuestión de estilo que no siempre es aplicable. Puede omitir con seguridad las citas de las palabras simples sin<citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> metacaracteres en ellos, mientras que en ciertos casos necesitará comillas simples para evitar cualquier interpretación del valor por <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry>. Un programador debería poder distinguir la sintaxis del lenguaje de las convenciones de estilo y utilizar ambas con prudencia.
The main idea behind <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry> is that an <filename>rc.d</filename> script provides handlers, or methods, for <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry> to invoke. In particular, <option>start</option>, <option>stop</option>, and other arguments to an <filename>rc.d</filename> script are handled this way. A method is a <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> expression stored in a variable named <envar><replaceable>argument</replaceable>_cmd</envar>, where <replaceable>argument</replaceable> corresponds to what can be specified on the script's command line. We will see later how <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry> provides default methods for the standard arguments. La idea principal detrás<citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry> es eso un <filename>rc.d</filename>La secuencia de comandos proporciona controladores o métodos para <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry> invocar. En particular, <option>start</option>, <option>stop</option>, y otros argumentos a un <filename>rc.d</filename>El script se maneja de esta manera. Un método es un <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> expresión almacenada en una variable llamada <envar><replaceable>argument</replaceable>_cmd</envar>, dónde <replaceable>argument</replaceable>corresponde a lo que se puede especificar en la línea de comandos del script. Veremos luego como <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry> proporciona métodos predeterminados para los argumentos estándar.
To make the code in <filename>rc.d</filename> more uniform, it is common to use <envar>${name}</envar> wherever appropriate. Thus a number of lines can be just copied from one script to another. Para hacer el código en <filename>rc.d</filename> más uniforme, es común usar <envar>${name}</envar> donde sea apropiado. Por tanto, se pueden copiar varias líneas de un script a otro.
We should keep in mind that <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry> provides default methods for the standard arguments. Consequently, we must override a standard method with a no-op <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> expression if we want it to do nothing. Debemos tener en cuenta que <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry> proporciona métodos predeterminados para los argumentos estándar. En consecuencia, debemos anular un método estándar con un no-op <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> expresión si queremos que no haga nada.
The body of a sophisticated method can be implemented as a function. It is a good idea to make the function name meaningful. El cuerpo de un método sofisticado se puede implementar como una función. Es una buena idea hacer que el nombre de la función sea significativo.

Loading…

User avatar juanda-097

New translation

FreeBSD Doc / articles_rc-scripting — Spanish

#!/bin/sh<co xml:id="rcng-dummy-shebang"/>

. /etc/rc.subr<co xml:id="rcng-dummy-include"/>

name="dummy"<co xml:id="rcng-dummy-name"/>
start_cmd="${name}_start"<co xml:id="rcng-dummy-startcmd"/>
stop_cmd=":"<co xml:id="rcng-dummy-stopcmd"/>

dummy_start()<co xml:id="rcng-dummy-startfn"/>
{
echo "Nothing started."
}

load_rc_config $name<co xml:id="rcng-dummy-loadconfig"/>
run_rc_command "$1"<co xml:id="rcng-dummy-runcommand"/>
#!/bin/sh<co xml:id="rcng-dummy-shebang"/>

. /etc/rc.subr<co xml:id="rcng-dummy-include"/>

name="dummy"<co xml:id="rcng-dummy-name"/>
start_cmd="${name}_start"<co xml:id="rcng-dummy-startcmd"/>
stop_cmd=":"<co xml:id="rcng-dummy-stopcmd"/>

dummy_start()<co xml:id="rcng-dummy-startfn"/>
{
echo "Nothing started."
}

load_rc_config $name<co xml:id="rcng-dummy-loadconfig"/>
run_rc_command "$1"<co xml:id="rcng-dummy-runcommand"/>
3 months ago
Browse all component changes

Things to check

Unchanged translation

Source and translation are identical

Reset

Glossary

English Spanish
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: informalexample/programlisting
Flags
no-wrap
Source string location
article.translate.xml:202
String age
3 months ago
Source string age
a year ago
Translation file
articles/es/rc-scripting.po, string 28