Fix manual pages macros in rc-scripting and linux-users

documentation/content/en/articles/rc-scripting/_index.adoc

@@ -40,7 +40,7 @@ Later there was an attempt to split out some parts of [.filename]#/etc/rc# for t
 
 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# system. Thus BSD [.filename]#rc.d# 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#. Soon we will learn about more components of the [.filename]#rc.d# system and see how the individual scripts are invoked.
 
-The basic ideas behind BSD [.filename]#rc.d# are _fine modularity_ and __code reuse__. _Fine modularity_ means that each basic "service" such as a system daemon or primitive startup task gets its own man:sh[1] 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# script still drives system startup, but now it merely invokes the smaller scripts one by one with the `start` argument. It is easy to perform shutdown tasks as well by running the same set of scripts with the `stop` argument, which is done by [.filename]#/etc/rc.shutdown#. Note how closely this follows the Unix way of having a set of small specialized tools, each fulfilling its task as well as possible. _Code reuse_ means that common operations are implemented as man:sh" "1" >}} functions and collected in [.filename]#/etc/rc.subr#. Now a typical script can be just a few lines' worth of man:sh" "1" >}} code. Finally, an important part of the [.filename]#rc.d# framework is man:rcorder[8], which helps [.filename]#/etc/rc# to run the small scripts orderly with respect to dependencies between them. It can help [.filename]#/etc/rc.shutdown#, too, because the proper order for the shutdown sequence is opposite to that of startup.
+The basic ideas behind BSD [.filename]#rc.d# are _fine modularity_ and __code reuse__. _Fine modularity_ means that each basic "service" such as a system daemon or primitive startup task gets its own man:sh[1] 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# script still drives system startup, but now it merely invokes the smaller scripts one by one with the `start` argument. It is easy to perform shutdown tasks as well by running the same set of scripts with the `stop` argument, which is done by [.filename]#/etc/rc.shutdown#. Note how closely this follows the Unix way of having a set of small specialized tools, each fulfilling its task as well as possible. _Code reuse_ means that common operations are implemented as man:sh[1] functions and collected in [.filename]#/etc/rc.subr#. Now a typical script can be just a few lines' worth of man:sh[1] code. Finally, an important part of the [.filename]#rc.d# framework is man:rcorder[8], which helps [.filename]#/etc/rc# to run the small scripts orderly with respect to dependencies between them. It can help [.filename]#/etc/rc.shutdown#, too, because the proper order for the shutdown sequence is opposite to that of startup.
 
 The BSD [.filename]#rc.d# design is described in <<lukem, the original article by Luke Mewburn>>, and the [.filename]#rc.d# components are documented in great detail in <<manpages, the respective manual pages>>. However, it might not appear obvious to an [.filename]#rc.d# 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#. 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# 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.
 

documentation/content/es/articles/linux-users/_index.adoc

@@ -87,7 +87,7 @@ Para obtener más información sobre los paquetes, consulte la sección 5.4 del
 
 La Colección de Ports de FreeBSD es un framework de [.filename]#Makefiles# y parches específicamente personalizados para instalar aplicaciones con su código fuente en FreeBSD. Al instalar un port, el sistema buscará el códifo fuente, aplicará los parches necesarios, compilará el código e instalará la aplicación y las dependencias necesarias.
 
-La Colección de Ports, a veces llamada el árbol de ports, se puede instalar en [.filename]#/usr/ports# utilizando man:portsnap" "8" >}}. Se pueden encontrar instrucciones detalladas para instalar la Colección de Ports en la link:{handbook}#ports-using[sección 5.5] del Manual de FreeBSD.
+La Colección de Ports, a veces llamada el árbol de ports, se puede instalar en [.filename]#/usr/ports# utilizando man:portsnap[8]. Se pueden encontrar instrucciones detalladas para instalar la Colección de Ports en la link:{handbook}#ports-using[sección 5.5] del Manual de FreeBSD.
 
 Para compilar un port, acceda al directorio del port e inicie el proceso de build. El siguiente ejemplo instala Apache 2.4 de la colección de ports:
 

documentation/content/pt-br/articles/rc-scripting/_index.adoc

@@ -505,7 +505,7 @@ Quando chamado durante a inicialização ou desligamento, um script [.filename]#
 
 Felizmente, man:rc.subr[8] permite passar qualquer número de argumentos para os métodos do script (dentro dos limites do sistema). Devido a isso, as alterações no próprio script podem ser mínimas.
 
-Como o man:rc.subr[8] pode obter acesso aos argumentos de linha de comando extra. Deveria pegá-los diretamente? Não por qualquer meio. Primeiro, uma função man:sh" "1" >}} não tem acesso aos parâmetros posicionais de seu chamador, mas o man:rc.subr[8] é apenas uma despedida de tais funções. Em segundo lugar, a boa maneira de [.filename]#rc.d# determina que é para o script principal decidir quais argumentos devem ser passados para seus métodos.
+Como o man:rc.subr[8] pode obter acesso aos argumentos de linha de comando extra. Deveria pegá-los diretamente? Não por qualquer meio. Primeiro, uma função man:sh[1] não tem acesso aos parâmetros posicionais de seu chamador, mas o man:rc.subr[8] é apenas uma despedida de tais funções. Em segundo lugar, a boa maneira de [.filename]#rc.d# determina que é para o script principal decidir quais argumentos devem ser passados para seus métodos.
 
 Portanto, a abordagem adotada por man:rc.subr[8] é a seguinte: `run_rc_command` transmite todos os seus argumentos, mas o primeiro um para o respectivo método na íntegra. O primeiro, omitido, argumento é o nome do próprio método: `start`,`stop`, etc. Ele será deslocado por `run_rc_command`, então o que é `$2` na linha de comando original será apresentado como `$1` ao método, e assim por diante.