git: e310196197 - main - Article rc-scripting translated to pt_BR and synced with doc tree version 98c736dd127a2096dc08252d1082300f2ec28ab5
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 30 Apr 2023 09:04:05 UTC
The branch main has been updated by ebrandi:
URL: https://cgit.FreeBSD.org/doc/commit/?id=e31019619775d5a2622bfa65974ed9ac8901ce66
commit e31019619775d5a2622bfa65974ed9ac8901ce66
Author: Edson Brandi <ebrandi@FreeBSD.org>
AuthorDate: 2023-04-30 09:02:52 +0000
Commit: Edson Brandi <ebrandi@FreeBSD.org>
CommitDate: 2023-04-30 09:02:52 +0000
Article rc-scripting translated to pt_BR and synced with doc tree version 98c736dd127a2096dc08252d1082300f2ec28ab5
---
.../pt-br/articles/rc-scripting/_index.adoc | 238 +-
.../content/pt-br/articles/rc-scripting/_index.po | 2337 ++++++++++++++++++++
2 files changed, 2464 insertions(+), 111 deletions(-)
diff --git a/documentation/content/pt-br/articles/rc-scripting/_index.adoc b/documentation/content/pt-br/articles/rc-scripting/_index.adoc
index 2f4e667517..786fc7b14d 100644
--- a/documentation/content/pt-br/articles/rc-scripting/_index.adoc
+++ b/documentation/content/pt-br/articles/rc-scripting/_index.adoc
@@ -1,13 +1,16 @@
---
-title: Scripts rc.d práticos no BSD
authors:
- - author: Yar Tikhiy
+ -
+ author: 'Yar Tikhiy'
email: yar@FreeBSD.org
-copyright: 2005-2006, 2012 The FreeBSD Project
+copyright: '2005-2006, 2012 The FreeBSD Project'
+description: 'Um guia para escrever novos scripts rc.d e entender aqueles que já existem'
+tags: ["rc.d", "scripting", "guide", "tutorial", "FreeBSD"]
+title: 'Scripting rc.d na prática no BSD'
trademarks: ["freebsd", "netbsd", "general"]
---
-= Scripts rc.d práticos no BSD
+= Scripting rc.d na prática no BSD
:doctype: article
:toc: macro
:toclevels: 1
@@ -41,7 +44,7 @@ endif::[]
[.abstract-title]
Resumo
-Os iniciantes podem achar difícil relacionar os fatos da documentação formal do framework [.filename]#rc.d# do BSD com as tarefas práticas do script [.filename]#rc.d#. Neste artigo, consideramos alguns casos típicos de complexidade crescente, vamos mostrar os recursos do [.filename]#rc.d# adequados para cada caso e vamos discutir como eles funcionam. Esse exame deve fornecer pontos de referência para um estudo mais aprofundado do design e da aplicação eficiente do [.filename]#rc.d#.
+Os iniciantes podem achar difícil relacionar os fatos da documentação formal sobre o framework [.filename]#rc.d# do BSD com as tarefas práticas de escrever scripts [.filename]#rc.d#. Neste artigo, consideramos alguns casos típicos de crescente complexidade, mostramos recursos do [.filename]#rc.d# adequados para cada caso e discutimos como eles funcionam. Essa análise deve fornecer pontos de referência para estudos posteriores do design e aplicação eficiente do [.filename]#rc.d#.
'''
@@ -50,26 +53,26 @@ toc::[]
[[rcng-intro]]
== Introdução
-Historicamente o BSD tinha um script de inicialização monolítico, o [.filename]#/etc/rc#. Ele era chamado pelo man:init[8] no momento da inicialização do sistema e executava todas as tarefas necessárias para a operação multi-usuário: verificação e montagem do sistemas de arquivos, configuração de rede, iniciava daemons e assim por diante. A lista precisa de tarefas não era a mesma em todos os sistemas; os administradores precisavam personalizá-lo. Com poucas exceções, o [.filename]#/etc/rc# teve que ser modificado, e os verdadeiros hackers gostaram disso.
+No histórico BSD, havia um script de inicialização monolítico, [.filename]#/etc/rc#. Ele era invocado pelo man:init[8] no momento da inicialização do sistema e realizava todas as tarefas de usuário necessárias para a operação multiusuário: verificação e montagem de sistemas de arquivos, configuração da rede, inicialização de daemons e assim por diante. A lista precisa de tarefas não era a mesma em todos os sistemas; os administradores precisavam personalizá-la. Com poucas exceções, o [.filename]#/etc/rc# tinha que ser modificado, e os verdadeiros hackers gostavam disso.
-O problema real com a abordagem monolítica era que ela não fornecia nenhum controle sobre os componentes individuais iniciados a partir do [.filename]#/etc/rc#. Por exemplo, o [.filename]#/etc/rc# não podia reiniciar um único daemon. O administrador do sistema tinha que encontrar o processo daemon manualmente, matá-lo, esperar até que ele realmente finalizasse, então procurar pelas flags no [.filename]#/etc/rc#, e finalmente digitar a linha de comando completa para iniciar o daemon novamente. A tarefa se tornaria ainda mais difícil e propensa a erros se o serviço de reinicialização consistisse em mais de um daemon ou exigisse ações adicionais. Em poucas palavras, o único script não cumpriu o objetivo dos scripts: tornar a vida do administrador do sistema mais fácil.
+O problema real com a abordagem monolítica era que ela não fornecia controle sobre os componentes individuais iniciados a partir do [.filename]#/etc/rc#. Por exemplo, o [.filename]#/etc/rc# não podia reiniciar um único daemon. O administrador do sistema tinha que encontrar o processo do daemon manualmente, matá-lo, aguardar até que ele realmente finalizasse, navegar por [.filename]#/etc/rc# em busca das flags e, finalmente, digitar a linha de comando completa para iniciar o daemon novamente. A tarefa se tornaria ainda mais difícil e propensa a erros se o serviço a ser reiniciado consistisse em mais de um daemon ou exigisse ações adicionais. Em poucas palavras, o script único falhou em cumprir o objetivo pelo qual um script é criado: tornar a vida do administrador do sistema mais fácil.
-Mais tarde, houve uma tentativa de dividir algumas partes do [.filename]#/etc/rc# para iniciar os subsistemas mais importantes separadamente. O exemplo notório foi o [.filename]#/etc/netstart# para configurar a rede. Ele permitia acessar a rede a partir do modo single-user, mas não se integrou bem ao processo de inicialização automática porque partes de seu código precisavam intercalar com ações essencialmente não relacionadas à rede. Foi por isso que o [.filename]#/etc/netstart# mudou para [.filename]#/etc/rc.network#. Este último não era mais um script comum; ele era composto por um emaranhado de funções man:sh[1] chamadas pelo [.filename]#/etc/rc# em diferentes estágios da inicialização do sistema. No entanto, a medida que as tarefas de inicialização cresciam variadas e sofisticadas, a abordagem "quase modular" tornou-se ainda mais engessada do que o monolítico [.filename]#/etc/rc#.
+Mais tarde, houve uma tentativa de dividir algumas partes do [.filename]#/etc/rc# para iniciar os subsistemas mais importantes separadamente. O exemplo notório foi o [.filename]#/etc/netstart# para iniciar a rede. Isso permitiu o acesso à rede no modo de usuário único, mas não se integrou bem ao processo de inicialização automática porque partes de seu código precisavam intercalar com ações essencialmente não relacionadas à rede. Foi por isso que o [.filename]#/etc/netstart# se transformou em [.filename]#/etc/rc.network#. Este último não era mais um script comum; era composto de grandes funções man:sh[1] complexas chamadas pelo [.filename]#/etc/rc# em diferentes estágios da inicialização do sistema. No entanto, à medida que as tarefas de inicialização ficaram mais diversas e sofisticadas, a abordagem "quase modular" tornou-se ainda mais pesada do que o monolítico [.filename]#/etc/rc# tinha sido.
-Sem um framework limpo e bem projetado, os scripts de inicialização tiveram que se curvar para satisfazer as necessidades de desenvolvimento rápido dos sistemas operacionais baseados no BSD. Tornou-se óbvio, finalmente, que mais passos eram necessários no caminho para construção de um sistema [.filename]#rc# extensível e customizável. Assim nasceu o BSD [.filename]#rc.d#. Seus pais reconhecidos foram o Luke Mewburn e a comunidade do NetBSD. Mais tarde ele foi importado para o FreeBSD. Seu nome se refere à localização dos scripts do sistema para serviços individuais, que é o [.filename]#/etc/rc.d#. Em breve, vamos aprender sobre mais componentes do sistema [.filename]#rc.d# e vamos ver como os scripts individuais são invocados.
+Sem um framework limpo e bem projetado, os scripts de inicialização tiveram que se dobrar para atender às necessidades dos sistemas operacionais baseados em BSD que estavam em rápida evolução. Tornou-se evidente, finalmente, que mais etapas eram necessárias para se chegar a um sistema [.filename]#rc# refinado, granular e extensível. Assim nasceu o [.filename]#rc.d# do BSD. Seus pais reconhecidos foram Luke Mewburn e a comunidade NetBSD. Mais tarde, foi importado para o FreeBSD. Seu nome se refere ao local dos scripts do sistema para serviços individuais, que está em [.filename]#/etc/rc.d#. Em breve, aprenderemos mais sobre os componentes do sistema [.filename]#rc.d# e veremos como os scripts individuais são invocados.
-As idéias básicas por trás do BSD [.filename]#rc.d# são _modularidade fina_ e __reutilização de código__. _Modularidade fina_ significa que cada "serviço básico", como um daemon do sistema ou uma tarefa de inicialização primitiva, obtém seu próprio script man:sh[] capaz de iniciar o serviço, pará-lo, recarregá-lo e verificar seu status. Uma ação específica é escolhida pelo argumento da linha de comando para o script. O script [.filename]#/etc/rc# ainda comanda a inicialização do sistema, mas agora ele simplesmente invoca os scripts menores um por um com o argumento `start`. É fácil executar tarefas de desligamento executando o mesmo conjunto de scripts com o argumento `stop`, o que é feito pelo [.filename]#/etc/rc.shutdown#. Observe como isso segue de perto o modo Unix de ter um conjunto de pequenas ferramentas especializadas, cada uma cumprindo sua tarefa da melhor forma possível. _Reutilização de código_ significa que operações comuns são implementa
das como funções man:sh[1] e coletadas em [.filename]#/etc/rc.subr#. Agora, um script típico pode conter apenas algumas linhas de código man:sh[1]. Finalmente, uma parte importante do framework do [.filename]#rc.d# é man:rcorder[8], o qual ajuda o [.filename]#/etc/rc# a executar os pequenos scripts ordenadamente em relação às dependências entre eles. Ele também pode ajudar o [.filename]#/etc/rc.shutdown#, porque a ordem apropriada para a sequência de encerramento é oposta à da inicialização.
+As ideias básicas por trás do [.filename]#rc.d# do BSD são _modularidade fina_ e __reutilização de código__. _Modularidade fina_ significa que cada "serviço" básico, como um daemon do sistema ou uma tarefa de inicialização primitiva, possui seu próprio script man:sh[1] capaz de iniciar o serviço, pará-lo, recarregá-lo e verificar seu status. Uma ação específica é escolhida pelo argumento da linha de comando do script. O script [.filename]#/etc/rc# ainda conduz a inicialização do sistema, mas agora ele apenas invoca os scripts menores um por um com o argumento `start`. Também é fácil realizar tarefas de desligamento executando o mesmo conjunto de scripts com o argumento `stop`, que é feito por [.filename]#/etc/rc.shutdown#. Observe como isso segue de perto a maneira Unix de ter um conjunto de ferramentas especializadas pequenas, cada uma cumprindo sua tarefa da melhor maneira possível. _Reutilização de código_ significa que operações comuns são implemen
tadas como funções man:sh[1] e coletadas em [.filename]#/etc/rc.subr#. Agora, um script típico pode ser composto apenas de algumas linhas de código man:sh[1]. Finalmente, uma parte importante do framework [.filename]#rc.d# é o man:rcorder[8], que ajuda o [.filename]#/etc/rc# a executar os pequenos scripts de maneira ordenada com respeito às dependências entre eles. Isso também pode ajudar o [.filename]#/etc/rc.shutdown#, porque a ordem apropriada para a sequência de desligamento é oposta à de inicialização.
-O design do BSD [.filename]#rc.d# é descrito no <<lukem, the original article by Luke Mewburn>>, e os componentes do [.filename]#rc.d# são documentados em grande detalhe nas <<manpages, the respective manual pages>>. No entanto, pode não parecer óbvio para um novato em [.filename]#rc.d# como amarrar os inúmeros pedaços juntos para criar um script bem estilizado para uma tarefa específica. Portanto, este artigo tentará uma abordagem diferente para descrever o [.filename]#rc.d#. Ele mostrará quais recursos devem ser usados em vários casos típicos e por quê. Note que este não é um documento explicativo porque nosso objetivo não é fornecer receitas prontas, mas mostrar algumas entradas fáceis no domínio do [.filename]#rc.d#. Nem este artigo é um substituto para as páginas de manual relevantes. Não hesite em consultá-los para obter uma documentação mais formal e completa ao ler este artigo.
+O design do BSD [.filename]#rc.d# é descrito no <<lukem, artigo original de Luke Mewburn>>, e os componentes do [.filename]#rc.d# são documentados em grande detalhe nas <<manpages, respectivas páginas do manual>>. No entanto, pode não ser óbvio para um iniciante no [.filename]#rc.d# como ele deve unir as numerosas partes para criar um script bem estruturado para uma tarefa específica. Portanto, este artigo tentará abordar o [.filename]#rc.d# de forma diferente. Mostrará quais recursos devem ser usados em vários casos típicos e por que. Observe que este não é um documento de "como fazer", porque nosso objetivo não é fornecer receitas prontas, mas mostrar algumas entradas fáceis no mundo do [.filename]#rc.d#. Este artigo também não substitui as páginas do manual relevantes. Não hesite em consultá-las para obter documentação mais formal e completa enquanto lê este artigo.
-Existem pré-requisitos para entender este artigo. Primeiro de tudo, você deve estar familiarizado com a linguagem de script man:sh[1] para poder dominar o [.filename]#rc.d#. Além disso, você deve saber como o sistema executa as tarefas de inicialização e encerramento do userland, o que está descrito em man:rc[8].
+Existem pré-requisitos para entender este artigo. Em primeiro lugar, você deve estar familiarizado com a linguagem de script man:sh[1] para dominar o [.filename]#rc.d#. Além disso, você deve saber como o sistema realiza tarefas de inicialização e desligamento do espaço do usuário, o que é descrito em man:rc[8].
-Este artigo foca no branch [.filename]#rc.d# do FreeBSD. No entanto, ele também pode ser útil para os desenvolvedores do NetBSD, porque os dois branchs [.filename]#rc.d# do BSD não apenas compartilham o mesmo design, mas também permanecem similares em seus aspectos visíveis aos autores do script.
+Este artigo foca no ramo do FreeBSD do [.filename]#rc.d#. No entanto, ele pode ser útil também para desenvolvedores do NetBSD, pois os dois ramos do [.filename]#rc.d# não apenas compartilham o mesmo design, mas também permanecem similares em seus aspectos visíveis aos autores de scripts.
[[rcng-task]]
== Esboçando a tarefa
-Um pouco de consideração antes de iniciar o `$EDITOR` não irá prejudicar. Para escrever um script [.filename]#rc.d# corretamente customizado para um serviço do sistema, devemos poder responder as seguintes questões primeiro:
+Uma pequena reflexão antes de iniciar o `$EDITOR` não fará mal. Para escrever um script [.filename]#rc.d# bem elaborado para um serviço do sistema, devemos ser capazes de responder às seguintes perguntas primeiro:
* O serviço é obrigatório ou opcional?
* O script servirá um único programa, por exemplo, um daemon, ou realizará ações mais complexas?
@@ -101,67 +104,67 @@ load_rc_config $name <.>
run_rc_command "$1" <.>
....
-Os pontos a serem observadas são:
+Os pontos a serem observados são:
-➊ Um script interpretado deve começar com a linha mágica "shebang". Essa linha especifica o programa interpretador para o script. Devido a linha shebang, o script pode ser invocado exatamente como um programa binário, desde que tenha o bit de execução definido. (Veja man:chmod[1].) Por exemplo, um administrador do sistema pode executar nosso script manualmente, a partir da linha de comando:
+➊ Um script interpretado deve começar com a linha mágica "shebang". Essa linha especifica o programa interpretador para o script. Devido à linha shebang, o script pode ser invocado exatamente como um programa binário, desde que tenha o bit de execução definido. (Veja man:chmod[1].) Por exemplo, um administrador do sistema pode executar nosso script manualmente, a partir da linha de comando:
-[source,shell]
+[source, shell]
....
# /etc/rc.d/dummy start
....
[NOTE]
====
-Para ser adequadamente gerenciado pelo framework do [.filename]#rc.d#, seus scripts precisam ser escritos na linguagem man:sh[1]. Se você tiver um serviço ou port que use um utilitário de controle binário ou uma rotina de inicialização escrita em outra linguagem, instale este elemento em [.filename]#/usr/sbin# (para o sistema) ou em [.filename]#/usr/local/sbin# (para um port) e invoque-o por meio de um script man:sh[1] no diretório apropriado do [.filename]#rc.d#.
+Para ser gerenciado corretamente pelo framework [.filename]#rc.d#, os scripts devem ser escritos na linguagem man:sh[1]. Se você tiver um serviço ou port que usa um utilitário de controle binário ou uma rotina de inicialização escrita em outra linguagem, instale esse elemento em [.filename]#/usr/sbin# (para o sistema) ou [.filename]#/usr/local/sbin# (para ports) e chame-o a partir de um script man:sh[1] no diretório [.filename]#rc.d# apropriado.
====
[TIP]
====
-Caso você queira aprender os detalhes do porque os scripts [.filename]#rc.d# devem ser escritos na linguagem man:sh[1], veja como o [.filename]#/etc/rc# invoca-os por meio de `run_rc_script`, e então estude a implementação de `run_rc_script` em [.filename]#/etc/rc. subr#.
+Se você gostaria de aprender os detalhes de por que os scripts [.filename]#rc.d# devem ser escritos na linguagem man:sh[1], veja como o [.filename]#/etc/rc# os invoca por meio de `run_rc_script` e, em seguida, estude a implementação de `run_rc_script` em [.filename]#/etc/rc.subr#.
====
-➋ Em [.filename]#/etc/rc.subr#, várias funções man:sh[1] estão definidas para serem utilizadas por um script [.filename]#rc.d#. As funções estão documentadas em man:rc.subr[8]. Embora seja teoricamente possível escrever um script [.filename]#rc.d# sem usar o man:rc.subr[8], as suas funções são extremamente úteis e tornam o trabalho mais fácil. Portanto, não é de surpreender que todos recorram a scripts man:rc.subr[8] em [.filename]#rc.d#. Nós não vamos ser uma exceção.
+➋ Em [.filename]#/etc/rc.subr#, uma série de funções man:sh[1] estão definidas para serem utilizadas por um script [.filename]#rc.d#. As funções estão documentadas em man:rc.subr[8]. Embora seja teoricamente possível escrever um script [.filename]#rc.d# sem nunca usar o man:rc.subr[8], suas funções provam ser extremamente úteis e tornam o trabalho uma ordem de magnitude mais fácil. Portanto, não é surpresa que todo mundo recorra ao man:rc.subr[8] em scripts [.filename]#rc.d#. Não seremos uma exceção.
-Um script [.filename]#rc.d# deve "incluir" o [.filename]#/etc/rc.subr# (isto por ser feito usando o comando "`.`") _antes_ que ele chame as funções do man:rc.subr[8] para que o man:sh[1] tenha a oportunidade para aprender as funções. O estilo preferido é incluir o [.filename]#/etc/rc.subr# antes de tudo.
+Um script [.filename]#rc.d# deve fazer o "source" do [.filename]#/etc/rc.subr# (inclua-o usando "`.`") _antes_ de chamar as funções man:rc.subr[8] para que o man:sh[1] tenha a oportunidade de aprender as funções. O estilo preferido é incluir o [.filename]#/etc/rc.subr# antes de tudo.
[NOTE]
====
-Algumas funções úteis relacionadas a rede são fornecidas por outro arquivo include, o [.filename]#/etc/network.subr#.
+Algumas funções úteis relacionadas à rede são fornecidas por outro arquivo de inclusão, o [.filename]#/etc/network.subr#.
====
-➌ [[name-var]]A variável obrigatória `name` especifica o nome do nosso script. Ela é exigida pelo man:rc.subr[8]. Ou seja, cada script [.filename]#rc.d# __deve__ definir a variável `name` antes de chamar funções do man:rc.subr[8].
+➌ A variável obrigatória `name` especifica o nome do nosso script. Ela é exigida pelo man:rc.subr[8]. Isso significa que cada script [.filename]#rc.d# _deve_ definir `name` antes de chamar funções do man:rc.subr[8].
Agora é o momento certo para escolher um nome exclusivo para o nosso script de uma vez por todas. Vamos usá-lo em vários lugares enquanto desenvolvemos o script. Para começar, também vamos dar o mesmo nome ao arquivo de script.
[NOTE]
====
-O estilo atual do script [.filename]#rc.d# é incluir valores atribuídos as variáveis entre aspas duplas. Tenha em mente que é apenas um problema de estilo que nem sempre pode ser aplicável. Você pode omitir com segurança as aspas das palavras simples sem os metacaracteres do man:sh[1] nelas, enquanto em certos casos você precisará de aspas simples para evitar qualquer interpretação do valor pelo man:sh[1]. Um programador deve ser capaz de dizer a sintaxe da linguagem a partir das convenções de estilo e bem como de usá-las sabiamente.
+O estilo atual de escrita de scripts [.filename]#rc.d# é envolver os valores atribuídos às variáveis em aspas duplas. Tenha em mente que isso é apenas uma questão de estilo que nem sempre é aplicável. Você pode seguramente omitir as aspas ao redor de palavras simples sem metacaracteres man:sh[1], enquanto em certos casos você precisará de aspas simples para evitar qualquer interpretação do valor por man:sh[1]. Um programador deve ser capaz de distinguir a sintaxe da linguagem das convenções de estilo e usá-las sabiamente.
====
-➍ A idéia principal por trás do man:rc.subr[8] é que um script [.filename]#rc.d# fornece manipuladores, ou métodos, para o man:rc.subr[8] invocar. Em particular, `start`, `stop` e outros argumentos para um script [.filename]#rc.d# são tratados desta maneira. Um método é uma expressão man:sh[1] armazenada em uma variável denominada `argument_cmd`, no qual _argument_ corresponde ao que pode ser especificado na linha de comando do script. Vamos ver mais adiante como o man:rc.subr[8] fornece métodos default para os argumentos padrão.
+➍ Cada script [.filename]#rc.d# fornece manipuladores, ou métodos, para o man:rc.subr[8] invocar. Em particular, `start`, `stop`, e outros argumentos para um script [.filename]#rc.d# são manipulados desta forma. Um método é uma expressão man:sh[1] armazenada em uma variável chamada `argument_cmd`, onde _argument_ corresponde ao que pode ser especificado na linha de comando do script. Veremos mais tarde como o man:rc.subr[8] fornece métodos padrão para os argumentos padrão.
[NOTE]
====
-Para tornar o código em [.filename]#rc.d# mais uniforme, é comum usar `${name}` onde for apropriado. Assim, várias linhas podem ser copiadas de um script para outro.
+Para tornar o código em [.filename]#rc.d# mais uniforme, é comum usar `${name}` sempre que apropriado. Assim, várias linhas podem ser simplesmente copiadas de um script para outro.
====
-➎ Devemos ter em mente que o man:rc.subr[8] fornece métodos default para os argumentos padrões. Consequentemente, devemos sobrescrever um método default com uma expressão no-op man:sh[] se desejarmos que ele não faça nada.
+➎ Devemos ter em mente que o man:rc.subr[8] fornece métodos padrões para os argumentos padrões. Consequentemente, devemos substituir um método padrão por uma expressão man:sh[1] sem efeito se quisermos que ele não faça nada.
-➏ O corpo de um método sofisticado pode ser implementado como uma função. É uma boa ideia tornar o nome da função significativo.
+➏ O corpo de um método sofisticado pode ser implementado como uma função. É uma boa ideia dar um nome significativo à função.
[IMPORTANT]
====
-É altamente recomendado adicionar o prefixo `${name}` aos nomes de todas as funções definidas em nosso script, para que eles nunca entrem em conflito com as funções do man:rc.subr[8] ou outro arquivo de inclusão comum.
+Recomenda-se fortemente adicionar o prefixo `${name}` aos nomes de todas as funções definidas no nosso script para que nunca entrem em conflito com as funções de man:rc.subr[8] ou outro arquivo de inclusão comum.
====
-➐ Essa chamada ao man:rc.subr[8] carrega as variáveis do man:rc.conf[5]. Nosso script não faz uso delas ainda, mas ainda assim é recomendado carregar o man:rc.conf[5] pois podem haver variáveis man:rc.conf[5] controlando o man:rc.subr[8] propriamente dito.
+➐ Essa chamada para o man:rc.subr[8] carrega as variáveis do man:rc.conf[5]. Nosso script ainda não as usa, mas ainda é recomendável carregar o man:rc.conf[5] porque pode haver variáveis do man:rc.conf[5] controlando o man:rc.subr[8] em si.
-➑ Geralmente este é o último comando em um script [.filename]#rc.d#. Ele invoca o maquinário man:rc.subr[8] para executar a ação solicitada usando as variáveis e métodos que nosso script forneceu.
+➑ Geralmente, esse é o último comando em um script [.filename]#rc.d#. Ele invoca a maquinaria do man:rc.subr[8] para realizar a ação solicitada usando as variáveis e métodos que o nosso script forneceu.
[[rcng-confdummy]]
== Um script fictício configurável
-Agora vamos adicionar alguns controles ao nosso script fictício. Como você deve saber, os scripts [.filename]#rc.d# são controlados pelo man:rc.conf[5]. Felizmente, o man:rc.subr[8] esconde todas as complicações de nós. O script a seguir usa o man:rc.conf[5] via man:rc.subr[8] para ver se ele está habilitado em primeiro lugar, e buscar uma mensagem para mostrar no momento da inicialização. Estas duas tarefas são de fato independentes. Por um lado, um script [.filename]#rc.d# pode apenas suportar a ativação e desativação de seu serviço. Por outro lado, um script [.filename]#rc.d# obrigatório pode ter variáveis de configuração. Nós vamos fazer as duas coisas no mesmo script:
+Agora vamos adicionar alguns controles ao nosso script fictício. Como você deve saber, scripts [.filename]#rc.d# são controlados com o man:rc.conf[5]. Felizmente, o man:rc.subr[8] oculta todas as complicações para nós. O script a seguir usa o man:rc.conf[5] por meio do man:rc.subr[8] para verificar se está habilitado em primeiro lugar e para buscar uma mensagem para ser exibida na inicialização. Essas duas tarefas, na verdade, são independentes. Por um lado, um script [.filename]#rc.d# pode apenas suportar a habilitação e desabilitação do seu serviço. Por outro lado, um script [.filename]#rc.d# obrigatório pode ter variáveis de configuração. No entanto, faremos as duas coisas no mesmo script:
[.programlisting]
....
@@ -189,43 +192,43 @@ run_rc_command "$1"
O que mudou neste exemplo?
-➊ A variável `rcvar` especifica o nome da variável do botão ON/OFF.
+➊ A variável `rcvar` especifica o nome da variável do botão LIGA/DESLIGA.
-➋ Agora o `load_rc_config` é invocado anteriormente no script, antes que qualquer variável do man:rc.conf[5] seja acessada.
+➋ Agora, o `load_rc_config` é invocado mais cedo no script, antes que quaisquer variáveis do man:rc.conf[5] sejam acessadas.
[NOTE]
====
-Ao examinar os scripts [.filename]#rc.d#, tenha em mente que o man:sh[1] adia a avaliação de expressões em uma função até que a função seja chamada. Portanto, não é um erro invocar `load_rc_config` tão tarde quanto antes do `run_rc_comman` e ainda acessar as variáveis do man:rc.conf[5] a partir do método das funções exportadas para o `run_rc_command`. Isto ocorre porque as funções do método devem ser chamadas por `run_rc_command`, que é chamado _após_ o `load_rc_config`.
+Enquanto examina os scripts [.filename]#rc.d#, tenha em mente que o man:sh[1] adia a avaliação de expressões em uma função até que esta seja chamada. Portanto, não é um erro invocar `load_rc_config` tão tarde quanto logo antes de `run_rc_command` e ainda assim acessar as variáveis man:rc.conf[5] das funções de método exportadas para `run_rc_command`. Isso ocorre porque as funções de método devem ser chamadas por `run_rc_command`, que é invocado _após_ `load_rc_config`.
====
-➌ Um aviso será emitido pelo `run_rc_command` se o próprio `rcvar` estiver definido, mas a variável de knob indicada não estiver definida. Se o seu script [.filename]#rc.d# for para o sistema base, você deve adicionar uma configuração padrão para o knob no [.filename]#/etc/defaults/rc.conf# e documentá-lo em man:rc.conf[5]. Caso contrário, será o seu script que deverá fornecer uma configuração padrão para o knob. A abordagem canônica para o último caso é mostrada no exemplo.
+➌ Aviso será emitido pelo `run_rc_command` se o `rcvar` em si estiver configurado, mas a variável de controle indicada estiver desativada. Se o seu script [.filename]#rc.d# é para o sistema base, você deve adicionar uma configuração padrão para o knob em [.filename]#/etc/defaults/rc.conf# e documentá-lo em man:rc.conf[5]. Caso contrário, é seu script que deve fornecer uma configuração padrão para o knob. A abordagem canônica para o último caso é mostrada no exemplo.
[NOTE]
====
-Você pode fazer o man:rc.subr[8] agir como se o knob fosse definido como `ON`, independentemente da sua configuração atual, prefixando o argumento para o script com `one` ou `force`, como em `onestart` ou `forcestop`. Tenha em mente que o `force` tem outros efeitos perigosos que mencionaremos abaixo, enquanto `one` apenas sobrescreve o knob ON/OFF. Por exemplo, suponha que `dummy_enable` seja `OFF`. O comando a seguir executará o método `start` apesar da configuração:
+Você pode fazer o man:rc.subr[8] agir como se o botão estivesse definido como `ON`, independentemente de sua configuração atual, prefixando o argumento do script com `one` ou `force`, como em `onestart` ou `forcestop`. No entanto, tenha em mente que `force` tem outros efeitos perigosos que abordaremos abaixo, enquanto `one` apenas substitui o botão ON/OFF. Por exemplo, suponha que `dummy_enable` esteja definido como `OFF`. O seguinte comando executará o método `start` apesar da configuração:
-[source,shell]
+[source, shell]
....
# /etc/rc.d/dummy onestart
....
====
-➍ Agora, a mensagem a ser mostrada no momento da inicialização não é mais codificada no script. Ela é especificada por uma variável do man:rc.conf[5] chamada `dummy_msg`. Este é um exemplo trivial de como as variáveis do man:rc.conf[5] podem controlar um script [.filename]#rc.d#.
+➍ Agora a mensagem a ser exibida na inicialização não é mais codificada no script. É especificada por uma variável man:rc.conf[5] chamada `dummy_msg`. Este é um exemplo trivial de como as variáveis man:rc.conf[5] podem controlar um script [.filename]#rc.d#.
[IMPORTANT]
====
-Os nomes de todas as variáveis do man:rc.conf[5] usadas exclusivamente pelo nosso script _devem_ possuir o mesmo prefixo: `${name}_`. Por exemplo: `dummy_mode`, `dummy_state_file`, e assim por diante.
+Os nomes de todas as variáveis man:rc.conf[5] usadas exclusivamente pelo nosso script _devem_ ter o mesmo prefixo: `${name}_`. Por exemplo: `dummy_mode`, `dummy_state_file`, e assim por diante.
====
[NOTE]
====
-Embora seja possível usar um nome mais curto internamente, por exemplo, apenas `msg`, adicionar o prefixo exclusivo `${name}_` a todos os nomes globais introduzidos pelo nosso script nos salvará de possíveis colisões com o nome das funções existentes no man:rc.subr[8].
+Embora seja possível usar um nome mais curto internamente, por exemplo, apenas `msg`, adicionar o prefixo único `${name}_` a todos os nomes globais introduzidos pelo nosso script nos salvará de possíveis colisões com o namespace do man:rc.subr[8].
-Como regra, os scripts [.filename]#rc.d# do sistema base não precisam fornecer valores padrões para as suas variáveis man:rc.conf[5] porque os padrões devem ser definidos em [.filename]#/etc/defaults/rc.conf#. Por outro lado, os scripts [.filename]#rc.d# para os ports devem fornecer os valores padrões, conforme mostrado no exemplo.
+Como regra geral, os scripts [.filename]#rc.d# do sistema base não precisam fornecer valores padrão para suas variáveis man:rc.conf[5], pois os valores padrão devem ser definidos em [.filename]#/etc/defaults/rc.conf#. Por outro lado, os scripts [.filename]#rc.d# para ports devem fornecer os valores padrão conforme mostrado no exemplo.
====
-➎ Aqui usamos `dummy_msg` para realmente controlar nosso script, ou seja, para emitir uma mensagem variável. O uso de uma função de shell é um exagero aqui, já que ele só executa um único comando; uma alternativa igualmente válida seria:
+➎ Aqui usamos `dummy_msg` para controlar nosso script, ou seja, para emitir uma mensagem variável. O uso de uma função shell é excessivo aqui, uma vez que ela executa apenas um único comando; uma alternativa igualmente válida é:
[.programlisting]
....
@@ -235,7 +238,7 @@ start_cmd="echo \"$dummy_msg\""
[[rcng-daemon]]
== Inicialização e desligamento de um daemon simples
-Dissemos anteriormente que o man:rc.subr[8] poderia fornecer métodos padrão. Obviamente, estes padrões não podem ser muito gerais. Eles são adequados para o caso comum de iniciar e encerrar um programa daemon simples. Vamos supor agora que precisamos escrever um script [.filename]#rc.d# para um daemon chamado `mumbled`. Aqui está:
+Dissemos anteriormente que o man:rc.subr[8] pode fornecer métodos padrões. Obviamente, tais padrões não podem ser muito gerais. Eles são adequados para o caso comum de iniciar e desligar um programa de daemon simples. Vamos supor agora que precisamos escrever um script [.filename]#rc.d# para um daemon chamado `mumbled`. Aqui está:
[.programlisting]
....
@@ -254,20 +257,20 @@ run_rc_command "$1"
Agradavelmente simples, não é? Vamos examinar nosso pequeno script. A única coisa nova a observar é o seguinte:
-➊ A variável `command` é significativa para o man:rc.subr[8]. Se estiver definido, o man:rc.subr[8] agirá de acordo com o cenário de servir um daemon convencional. Em particular, os métodos padrão serão fornecidos para tais argumentos: `start`, `stop`, `restart`, `poll`, e `status`.
+➊ A variável `command` é significativa para man:rc.subr[8]. Se ela estiver definida, man:rc.subr[8] agirá de acordo com o cenário de servir a um daemon convencional. Em particular, os métodos padrão serão fornecidos para esses argumentos: `start`, `stop`, `restart`, `poll` e `status`.
-O daemon será iniciado executando `$command` com os sinalizadores de linha de comando especificados por `$mumbled_flags`. Assim, todos os dados de entrada para o método padrão `start` estão disponíveis nas variáveis configuradas pelo nosso script. Ao contrário do `start`, outros métodos podem requerer informações adicionais sobre o processo iniciado. Por exemplo, `stop` deve conhecer o PID do processo para terminá-lo. No presente caso, man:rc.subr[8]varrerá a lista de todos os processos, procurando por um processo com seu nome igual a `$procname`. Esta última é outra variável de significado para man:rc.subr[8], e seu valor é padronizado para `command`. Em outras palavras, quando definimos o `command`, `procname` é efetivamente definido para o mesmo valor. Isso permite que nosso script mate o daemon e verifique se ele está sendo executado em primeiro lugar.
+O daemon será iniciado executando `$command` com as flags de linha de comando especificadas por `$mumbled_flags`. Assim, todos os dados de entrada para o método `start` padrão estão disponíveis nas variáveis definidas pelo nosso script. Ao contrário de `start`, outros métodos podem exigir informações adicionais sobre o processo iniciado. Por exemplo, `stop` deve saber o PID do processo para terminá-lo. No caso presente, man:rc.subr[8] irá pesquisar a lista de todos os processos, procurando por um processo com o nome igual a `procname`. Este último é outra variável com significado para man:rc.subr[8], e seu valor padrão é o de `command`. Em outras palavras, quando definimos `command`, `procname` é efetivamente definido para o mesmo valor. Isso permite que nosso script mate o daemon e verifique se ele está em execução.
[NOTE]
====
-Alguns programas são, na verdade, scripts executáveis. O sistema executa esse script iniciando seu interpretador e passando o nome do script para ele como um argumento de linha de comando. Isso é refletido na lista de processos, que podem confundir o man:rc.subr[8]. Você também deve definir o `command_interpreter` para permitir que o man:rc.subr[8] saiba o nome real do processo se o `$command` é um script.
+Algumas vezes, programas são de fato scripts executáveis. O sistema executa esse script iniciando o seu interpretador e passando o nome do script como um argumento na linha de comando. Isso é refletido na lista de processos, o que pode confundir man:rc.subr[8]. Você deve adicionalmente definir `command_interpreter` para que man:rc.subr[8] saiba o nome real do processo se `$command` for um script.
-Para cada script [.filename]#rc.d#, existe uma variável man:rc.conf[] que tem precedência sobre `command`. Seu nome é construído da seguinte forma: `${name}_program`, onde `name` é a variável obrigatória que discutimos <<name-var, earlier>>. Por exemplo, neste caso, será `mumbled_program`. É man:rc.subr[8] que organiza `${name}_program` para substituir o comando.
+A cada script [.filename]#rc.d#, há uma variável opcional do man:rc.conf[5] que tem precedência sobre `command`. Seu nome é construído da seguinte forma: `${name}_program`, onde `name` é a variável obrigatória discutida anteriormente. Por exemplo, neste caso, será `mumbled_program`. É o man:rc.subr[8] que arruma `${name}_program` para substituir `command`.
-Obviamente, o man:sh[1] permitirá que você defina `${name}_program` a partir do man:rc.conf[5] ou o próprio script, mesmo que o `command` esteja indefinido. Nesse caso, as propriedades especiais de `${name}_program` são perdidas e se tornam uma variável comum que seu script pode usar para seus próprios propósitos. No entanto, o uso exclusivo de `${name}_program` é desencorajado porque usá-lo junto com o `command` tornou-se um idioma na escrita de scripts [.filename]#rc.d#.
+Claro que o man:sh[1] permite definir `${name}_program` a partir do man:rc.conf[5] ou do próprio script, mesmo se `command` não estiver definido. Nesse caso, as propriedades especiais de `${name}_program` são perdidas, e ela se torna uma variável comum que o script pode usar para seus próprios fins. No entanto, o uso exclusivo de `${name}_program` é desencorajado, pois usá-la em conjunto com `command` se tornou idiomático em [.filename]#rc.d# scripting.
====
-Para obter informações mais detalhadas sobre métodos padrões, consulte man:rc.subr[8].
+Para obter informações mais detalhadas sobre os métodos padrões, consulte man:rc.subr[8].
[[rcng-daemon-adv]]
== Inicialização e desligamento de um daemon avançado
@@ -288,7 +291,7 @@ command_args="mock arguments > /dev/null 2>&1" <.>
pidfile="/var/run/${name}.pid" <.>
-required_files="/etc/${name}.conf /usr/shared/misc/${name}.rules" <.>
+required_files="/etc/${name}.conf /usr/share/misc/${name}.rules" <.>
sig_reload="USR1" <.>
@@ -330,75 +333,75 @@ load_rc_config $name
run_rc_command "$1"
....
-➊ Argumentos adicionais para `$command` podem ser passados em `command_args`. Eles serão adicionados a linha de comando após `$mumbled_flags`. Como a linha de comando final é passada para `eval` para sua execução real, os redirecionamentos de entrada e saída podem ser especificados em `command_args`.
+➊ Argumentos adicionais para `$command` podem ser passados em `command_args`. Eles serão adicionados à linha de comando após `$mumbled_flags`. Como a linha de comando final é passada para `eval` para sua execução real, redirecionamentos de entrada e saída podem ser especificados em `command_args`.
[NOTE]
====
-_Nunca_ inclua opções tracejadas, como `-X` ou `--foo`, em `command_args`. O conteúdo de `command_args` aparecerá no final da linha de comando final, portanto é provável que eles sigam os argumentos presentes em `${name}_flags`; mas a maioria dos comandos não reconhecerá opções tracejadas após argumentos comuns. Uma maneira melhor de passar opções adicionais para `$command` é adicioná-las ao início de `${name}_flags`. Outra maneira é modificar `rc_flags` <<rc-flags, as shown later>>.
+_Nunca_ inclua opções com hífen, como `-X` ou `--foo`, em `command_args`. O conteúdo de `command_args` aparecerá no final da linha de comando final, portanto, é provável que sigam argumentos presentes em `${name}_flags`; mas a maioria dos comandos não reconhecerá opções com hífen após argumentos comuns. Uma maneira melhor de passar opções adicionais para `$command` é adicioná-las no início de `${name}_flags`. Outra maneira é modificar `rc_flags` <<rc-flags, conforme mostrado posteriormente>>.
====
-➋ Um daemon de boas maneiras deve criar um _pidfile_ para que seu processo possa ser encontrado com mais facilidade e confiabilidade. A variável `pidfile`, se configurada, informa ao man:rc.subr[8] onde pode encontrar o pidfile para seus métodos padrão possam usar.
+➋ Um daemon bem comportado deve criar um _pidfile_ para que seu processo possa ser encontrado de forma mais fácil e confiável. A variável `pidfile`, se definida, informa ao man:rc.subr[8] onde ele pode encontrar o pidfile para ser utilizado em seus métodos padrões.
[NOTE]
====
-De fato, o man:rc.subr[8] também usará o pidfile para ver se o daemon já está em execução antes de iniciá-lo. Esta verificação pode ser ignorada usando o argumento `faststart`.
+De fato, o man:rc.subr[8] também usa o pidfile para ver se o daemon já está em execução antes de iniciá-lo. Essa verificação pode ser ignorada usando o argumento `faststart`.
====
-➌ Se o daemon não puder ser executado a menos que existam certos arquivos, apenas liste-os em `required_files`, e man:rc.subr[8] irá verificar se esses arquivos existem antes de iniciar o daemon. Também existem `required_dirs` e `required_vars` para diretórios e variáveis de ambiente, respectivamente. Todos eles são descritos em detalhes em man:rc.subr[8].
+➌ Se o daemon não puder ser executado a menos que certos arquivos existam, basta listá-los em `required_files`, e o man:rc.subr[8] verificará se esses arquivos existem antes de iniciar o daemon. Existem também `required_dirs` e `required_vars` para diretórios e variáveis de ambiente, respectivamente. Todos eles são descritos em detalhes no man:rc.subr[8].
[NOTE]
====
-O método padrão de man:rc.subr[8] pode ser forçado a ignorar as verificações de pré-requisitos usando `forcestart` como o argumento para o script.
+O método padrão do man:rc.subr[8] pode ser forçado a pular as verificações de pré-requisito usando `forcestart` como argumento para o script.
====
-➍ Podemos personalizar sinais para enviar para o daemon caso eles sejam diferentes dos mais conhecidos. Em particular, `sig_reload` especifica o sinal que faz o daemon recarregar sua configuração; é `SIGHUP` por padrão. Outro sinal é enviado para parar o processo do daemon; o padrão é `SIGTERM`, mas isso pode ser alterado definindo `sig_stop` apropriadamente.
+➍ Podemos personalizar sinais a serem enviados ao daemon caso eles difiram dos sinais conhecidos. Em particular, `sig_reload` especifica o sinal que faz com que o daemon recarregue sua configuração; por padrão, é o SIGHUP. Outro sinal é enviado para interromper o processo do daemon; o padrão é o SIGTERM, mas isso pode ser alterado configurando `sig_stop` adequadamente.
[NOTE]
====
-Os nomes dos sinais devem ser especificados para o man:rc.subr[8] sem o prefixo `SIG`, como é mostrado no exemplo. A versão do FreeBSD do man:kill[1] pode reconhecer o prefixo `SIG`, mas as versões de outros tipos de sistema operacional não.
+As sinalizações devem ser especificadas para o man:rc.subr[8] sem o prefixo `SIG`, como é mostrado no exemplo. A versão do FreeBSD do man:kill[1] pode reconhecer o prefixo `SIG`, mas as versões de outros sistemas operacionais podem não reconhecer.
====
-➎➏ Realizar tarefas adicionais antes ou depois dos métodos padrão é fácil. Para cada argumento de comando suportado pelo nosso script, podemos definir o argumento `_precmd` e `_postcmd`. Esses comandos no man:sh[1] são invocados antes e depois do respectivo método, como é evidente em seus nomes.
+➎➏ Realizar tarefas adicionais antes ou depois dos métodos padrões é fácil. Para cada argumento de comando suportado por nosso script, podemos definir `argument_precmd` e `argument_postcmd`. Esses comandos man:sh[1] são invocados antes e depois do respectivo método, como é evidente pelos seus nomes.
[NOTE]
====
-Sobrescrever um método padrão com um `argumento _cmd` personalizado ainda não nos impede de fazer uso do `argumento _precmd` ou `argumento _postcmd` se precisarmos. Em particular, o primeiro é bom para verificar condições personalizadas e sofisticadas que devem ser atendidas antes de executar o comando em si. Usar o `argumento _precmd` junto com o `argumento _cmd` nos permite separar logicamente as verificações da ação.
+Sobrescrever um método padrão com um `argument_cmd` personalizado ainda não nos impede de usar `argument_precmd` ou `argument_postcmd` se precisarmos. Em particular, o primeiro é bom para verificar condições personalizadas e sofisticadas que devem ser atendidas antes de executar o próprio comando. Usar `argument_precmd` juntamente com `argument_cmd` nos permite separar logicamente as verificações da ação.
-Não se esqueça de que você pode amontoar qualquer expressão válida do man:sh[1] nos métodos, pré e pós-comandos definidos por você. Apenas invocar uma função que faz com que o trabalho real seja um bom estilo na maioria dos casos, mas nunca deixe o estilo limitar sua compreensão do que está acontecendo por trás da cortina.
+Não se esqueça de que você pode colocar qualquer expressão válida do man:sh[1] nos métodos, pre e pós comandos que você define. Invocar uma função que realiza o trabalho real é um bom estilo na maioria dos casos, mas nunca deixe o estilo limitar sua compreensão do que está acontecendo nos bastidores.
====
-➐ Se quisermos implementar argumentos customizados, que também podem ser considerados como _comandos_ para o nosso script, precisamos listá-los em `extra_commands` e fornecer métodos para manipulá-los.
+➐ Se quisermos implementar argumentos personalizados, que também podem ser considerados como _comandos_ para o nosso script, precisamos listá-los em `extra_commands` e fornecer métodos para lidar com eles.
[NOTE]
====
-O comando `reload` é especial. Por um lado, tem um método predefinido em man:rc.subr[8]. Por outro lado, `reload` não é oferecido por padrão. A razão é que nem todos os daemons usam o mesmo mecanismo de recarga e alguns não têm nada para recarregar. Portanto, precisamos solicitar explicitamente que a funcionalidade incorporada seja fornecida. Podemos fazer isso via `extra_commands`.
+O comando `reload` é especial. Por um lado, ele possui um método predefinido em man:rc.subr[8]. Por outro lado, `reload` não é oferecido por padrão. A razão é que nem todos os daemons usam o mesmo mecanismo de recarga e alguns não têm nada para recarregar. Portanto, precisamos pedir explicitamente que a funcionalidade integrada seja fornecida. Podemos fazer isso por meio de `extra_commands`.
-O que obtemos do método padrão para `reload`? Muitas vezes, os daemons recarregam sua configuração na recepção de um sinal - normalmente, `SIGHUP`. Portanto, o man:rc.subr[8] tenta recarregar o daemon enviando um sinal para ele. O sinal é predefinido para `SIGHUP`, mas pode ser personalizado via `sig_reload`, caso necessário.
+O que recebemos do método padrão para `reload`? Muitas vezes, os daemons recarregam sua configuração após receber um sinal - geralmente, SIGHUP. Portanto, o man:rc.subr[8] tenta recarregar o daemon enviando um sinal para ele. O sinal é pré-definido como SIGHUP, mas pode ser personalizado via `sig_reload`, se necessário.
====
-➑⓮ Nosso script suporta dois comandos não padrão, `plugh` e `xyzzy`. Nós os vimos listados em `extra_commands`, e agora é hora de fornecer métodos para eles. O método para `xyzzy` é apenas embutido, enquanto que para `plugh` é implementado como a função `mumbled_plugh`.
+➑⓮ O nosso script suporta dois comandos não padrão, `plugh` e `xyzzy`. Nós os vimos listados em `extra_commands`, e agora é hora de fornecer métodos para eles. O método para `xyzzy` é apenas inserido em linha enquanto que para `plugh` é implementado como a função `mumbled_plugh`.
-Comandos não padrão não são chamados durante a inicialização ou o desligamento. Geralmente eles são para a conveniência do administrador do sistema. Eles também podem ser usados de outros subsistemas, por exemplo, man:devd[8] se especificado em man:devd.conf[5].
+Comandos não padrão não são invocados durante a inicialização ou desligamento. Geralmente, eles são para a conveniência do administrador do sistema. Eles também podem ser usados em outros subsistemas, por exemplo, o man:devd[8] se especificados em man:devd.conf[5].
-A lista completa de comandos disponíveis pode ser encontrada na linha de uso impressa por man:rc.subr[8] quando o script é invocado sem argumentos. Por exemplo, aqui está a linha de uso do script em estudo:
+A lista completa de comandos disponíveis pode ser encontrada na linha de uso impressa pelo man:rc.subr[8] quando o script é invocado sem argumentos. Por exemplo, aqui está a linha de uso do script em estudo:
-[source,shell]
+[source, shell]
....
# /etc/rc.d/mumbled
-Uso: /etc/rc.d/mumbled [fast|force|one](start|stop|restart|rcvar|reload|plugh|xyzzy|status|poll)
+Usage: /etc/rc.d/mumbled [fast|force|one](start|stop|restart|rcvar|reload|plugh|xyzzy|status|poll)
....
-⓭ Um script pode invocar seus próprios comandos padrão ou não padrão, se necessário. Isto pode parecer semelhante as funções de chamada, mas sabemos que comandos e funções de shell nem sempre são a mesma coisa. Por exemplo, `xyzzy` não é implementado como uma função aqui. Além disso, pode haver um pré-comando e um pós-comando, que devem ser chamados ordenadamente. Portanto, a maneira correta de um script executar seu próprio comando é por meio de man:rc.subr[8], conforme mostrado no exemplo.
+⓭ Um script pode invocar seus próprios comandos padrão ou não-padrão, se necessário. Isso pode parecer semelhante a chamar funções, mas sabemos que comandos e funções do shell nem sempre são a mesma coisa. Por exemplo, `xyzzy` não é implementado como uma função aqui. Além disso, pode haver um pré-comando e um pós-comando, que devem ser invocados ordenadamente. Portanto, a maneira adequada para um script executar seu próprio comando é por meio do man:rc.subr[8], como mostrado no exemplo.
-➒ Uma função útil chamada `checkyesno` é fornecida por man:rc.subr[8]. Ele usa um nome de variável como argumento e retorna um código de saída zero se, e somente se, a variável estiver configurada como `YES`, ou `TRUE`, ou `ON`, ou `1`, sem distinção entre maiúsculas e minúsculas; um código de saída diferente de zero é retornado de outra forma. No último caso, a função testa a variável como sendo definida como `NO`,`FALSE`,`OFF` ou `0` insensível a maiúsculas e minúsculas; imprime uma mensagem de aviso se a variável contiver qualquer outra coisa, ou seja, lixo.
+➒ Uma função útil chamada `checkyesno` é fornecida pelo man:rc.subr[8]. Ela recebe um nome de variável como argumento e retorna um código de saída zero se e somente se a variável estiver definida como `YES`, ou `TRUE`, ou `ON`, ou `1`, insensível a maiúsculas e minúsculas; um código de saída não-zero é retornado caso contrário. Neste último caso, a função testa se a variável está definida como `NO`, `FALSE`, `OFF` ou `0`, insensível a maiúsculas e minúsculas; ela imprime uma mensagem de aviso se a variável contiver qualquer outra coisa, ou seja, lixo.
-Tenha em mente que para o man:sh[1] um código de saída zero significa verdadeiro e um código de saída diferente de zero significa falso.
+Tenha em mente que para o man:sh[1], um código de saída zero significa verdadeiro e um código de saída não-zero significa falso.
[IMPORTANT]
====
-A função `checkyesno` recebe um __nome da variável__. Não passe o _valor_ expandido de uma variável para ele; não funcionará como esperado.
+A função `checkyesno` recebe um __nome de variável__. Não passe o _valor expandido_ de uma variável para ela; isso não funcionará como esperado.
-O uso correto de `checkyesno` é:
+Aqui está o uso correto de `checkyesno`:
[.programlisting]
....
@@ -407,7 +410,7 @@ if checkyesno mumbled_enable; then
fi
....
-Pelo contrário, chamar `checkyesno` como mostrado abaixo não funcionará - pelo menos não como esperado:
+Ao contrário, chamar `checkyesno` como mostrado abaixo não funcionará - pelo menos não como esperado:
[.programlisting]
....
@@ -418,34 +421,34 @@ fi
====
-➓ [[rc-flags]] Podemos afetar os sinalizadores a serem passados para `$command` modificando `rc_flags` em `$start_precmd`.
+➓ [[rc-flags]]Podemos afetar as flags que serão passadas para `$command` modificando `rc_flags` em `$start_precmd`.
-⓫ Em certos casos, podemos precisar emitir uma mensagem importante que também deve ser enviada para o `syslog`. Isto pode ser feito facilmente com as seguintes funções man:rc.subr[8]: `debug`, `info`, `warn` e `err`. A última função, em seguida, sai do script com o código especificado.
+⓫ Em certos casos, podemos precisar emitir uma mensagem importante que também deve ser registrada no `syslog`. Isso pode ser feito facilmente com as seguintes funções do man:rc.subr[8]: `debug`, `info`, `warn` e `err`. Esta última função finaliza o script com o código especificado.
-⓬ Os códigos de saída dos métodos e seus pré-comandos não são apenas ignorados por padrão. Se o argumento `_precmd` retornar um código de saída diferente de zero, o método principal não será executado. Por sua vez, o `argumento_postcmd` não será invocado a menos que o método principal retorne um código de saída zero.
+⓬ Os códigos de saída dos métodos e seus pre-comandos não são apenas ignorados por padrão. Se `argument_precmd` retornar um código de saída diferente de zero, o método principal não será executado. Por sua vez, `argument_postcmd` não será chamado, a menos que o método principal retorne um código de saída igual a zero.
[NOTE]
====
-No entanto, o man:rc.subr[8] pode ser instruído a partir da linha de comando para ignorar esses códigos de saída e invocar todos os comandos, prefixando um argumento com `force`, como em `forcestart`.
+Entretanto, é possível instruir o man:rc.subr[8] a ignorar esses códigos de saída e executar todos os comandos mesmo assim, adicionando um argumento com o prefixo `force`, como em `forcestart`.
====
[[rcng-hookup]]
== Conectando um script ao framework rc.d
-Depois que um script foi escrito, ele precisa ser integrado em [.filename]#rc.d>#. O passo crucial é instalar o script em [.filename]#/etc/rc.d# (para o sistema base) ou [.filename]#/usr/local/etc/rc.d# (para ports). Ambos [.filename]#bsd.prog.mk# e [.filename]#bsd.port.mk# fornecer ganchos convenientes para isso, e geralmente você não precisa se preocupar com a propriedade e o modo adequado. Os scripts do sistema devem ser instalados a partir do [.filename]#src /etc/rc.d# através do [.filename]#Makefile# encontrado lá. Os scripts de porta podem ser instalados usando `USE_RC_SUBR` conforme descrito em extref:{porters-handbook}[no Manual do Porter, rc-scripts].
+Depois que um script é escrito, ele precisa ser integrado ao [.filename]#rc.d#. O passo crucial é instalar o script em [.filename]#/etc/rc.d# (para o sistema base) ou [.filename]#/usr/local/etc/rc.d# (para o ports). Tanto o [.filename]#bsd.prog.mk# quanto o [.filename]#bsd.port.mk# fornecem ganchos convenientes para isso, e geralmente você não precisa se preocupar com a propriedade e o modo adequados. Os scripts do sistema devem ser instalados a partir de [.filename]#src/libexec/rc/rc.d# através do [.filename]#Makefile# encontrado lá. Scripts de ports podem ser instalados usando `USE_RC_SUBR` como descrito no extref:{porters-handbook}[Porter's Handbook, rc-scripts].
No entanto, devemos considerar antecipadamente o local do nosso script na sequência de inicialização do sistema. O serviço manipulado pelo nosso script provavelmente depende de outros serviços. Por exemplo, um daemon de rede não pode funcionar sem as interfaces de rede e o roteamento em funcionamento. Mesmo que um serviço pareça não exigir nada, dificilmente pode ser iniciado antes que os sistemas de arquivos básicos tenham sido verificados e montados.
-Nós já mencionamos o man:rcorder[8]. Agora é hora de dar uma olhada de perto. Em poucas palavras, o man:rcorder[8] pega um conjunto de arquivos, examina seu conteúdo e imprime uma lista ordenada por dependência de arquivos do conjunto para `stdout`. O objetivo é manter as informações de dependência _dentro_ dos arquivos para que cada arquivo possa falar por si só. Um arquivo pode especificar as seguintes informações:
+Nós já mencionamos o man:rcorder[8]. Agora é hora de dar uma olhada mais de perto nele. Em poucas palavras, o man:rcorder[8] pega um conjunto de arquivos, examina seus conteúdos e imprime uma lista ordenada por dependência dos arquivos do conjunto no `stdout`. O objetivo é manter as informações de dependência _dentro_ dos arquivos, de modo que cada arquivo possa falar apenas por si mesmo. Um arquivo pode especificar as seguintes informações:
-* os nomes das "condições" (o que significa serviços para nós) que ele __fornece__;
+* os nomes das "condições" (ou seja, serviços para nós) que ele __fornece__;
* os nomes das "condições" que ele __requer__;
-* os nomes das "condições" deste arquivo devem ser executados __antes__;
-* _palavras-chave adicionais_ que podem ser usadas para selecionar um subconjunto de todo o conjunto de arquivos (man:rcorder[8] podem ser instruídos através de opções para incluir ou omitir os arquivos com determinadas palavras-chave listadas.)
+* os nomes das "condições" que este arquivo deve ser executado __antes__;
+* palavras-chave adicionais que podem ser usadas para selecionar um subconjunto do conjunto completo de arquivos (man:rcorder[8] pode ser instruído via opções para incluir ou omitir os arquivos que possuem determinadas palavras-chave listadas.)
-Não é surpresa que man:rcorder[8] possa manipular apenas arquivos de texto com uma sintaxe próxima a de man:sh[1]. Ou seja, linhas especiais compreendidas por man:rcorder[8] se parecem com comentários man:sh[1]. A sintaxe de tais linhas especiais é bastante rígida para simplificar seu processamento. Veja man:rcorder[8] para detalhes.
+Não é surpresa que o man:rcorder[8] possa lidar apenas com arquivos de texto com uma sintaxe próxima à do man:sh[1]. Ou seja, as linhas especiais entendidas pelo man:rcorder[8] se parecem com comentários do man:sh[1]. A sintaxe dessas linhas especiais é bastante rígida para simplificar seu processamento. Consulte man:rcorder[8] para obter detalhes.
-Além de usar linhas especiais do man:rcorder[8], um script pode insistir em sua dependência de outro serviço apenas iniciando-o forçadamente. Isso pode ser necessário quando o outro serviço é opcional e não será iniciado automaticamente porque o administrador do sistema o desativou por engano no man:rc.conf[5].
+Além de usar as linhas especiais entendidas pelo man:rcorder[8], um script pode exigir sua dependência de outro serviço simplesmente iniciando-o forçadamente. Isso pode ser necessário quando o outro serviço é opcional e não iniciará por si só porque o administrador do sistema o desativou por engano em man:rc.conf[5].
Com este conhecimento geral em mente, vamos considerar o simples script daemon aprimorado com coisas de dependência:
@@ -481,44 +484,55 @@ run_rc_command "$1"
Como antes, a análise detalhada segue:
-➊ Esta linha declara os nomes das "condições" que nosso script fornece. Agora, outros scripts podem registrar uma dependência em nosso script por estes nomes.
+➊ Essa linha declara os nomes das "condições" que nosso script fornece. Agora, outros scripts podem registrar uma dependência em nosso script por esses nomes.
[NOTE]
====
Geralmente, um script especifica uma única condição fornecida. No entanto, nada nos impede de listar várias condições, por exemplo, por razões de compatibilidade.
-Em qualquer caso, o nome da condição principal, ou a única, `PROVIDE:` deve ser o mesmo que `${name}`.
+Em qualquer caso, o nome da condição principal, ou única, `PROVIDE:` deve ser o mesmo que `${name}`.
====
-➋➌ Portanto, nosso script indica quais condições "" são fornecidas por outros scripts dos quais depende. De acordo com as linhas, nosso script pede ao man:rcorder[8] para colocá-lo após o(s) script(s) fornecendo [.filename]#DAEMON# e [.filename]#cleanvar#, mas antes disso prover [.filename]#LOGIN#.
+➋➌ Então, nosso script indica em quais "condições" fornecidas por outros scripts ele depende. De acordo com as linhas, nosso script pede para o man:rcorder[8] colocá-lo após o(s) script(s) fornecendo o [.filename]#DAEMON# e o [.filename]#cleanvar#, mas antes daquele que fornece [.filename]#LOGIN#.
[NOTE]
====
-A linha `BEFORE:` não deve ser abusada para contornar uma lista de dependências incompleta no outro script. O caso apropriado para usar o `BEFORE:` é quando o outro script não se importa com o nosso, mas nosso script pode fazer sua tarefa melhor se for executado antes do outro. Um típico exemplo da vida real são as interfaces de rede versus o firewall: embora as interfaces não dependam do firewall em realizar seu trabalho, a segurança do sistema se beneficiará do firewall estar pronto antes que haja qualquer tráfego de rede.
+A linha `BEFORE:` não deve ser usada para contornar uma lista de dependências incompleta em outro script. O caso apropriado para usar `BEFORE:` é quando o outro script não se importa com o nosso, mas nosso script pode executar sua tarefa melhor se for executado antes do outro. Um exemplo típico da vida real é a relação entre as interfaces de rede e o firewall: embora as interfaces não dependam do firewall para fazer o trabalho delas, a segurança do sistema se beneficiará se o firewall estiver pronto antes de haver qualquer tráfego de rede.
-Além das condições correspondentes a um único serviço, existem meta-condições e seus scripts "placeholder" usados para garantir que determinados grupos de operações sejam executados antes dos outros. Estes são denotados pelos nomes [.filename]#UPPERCASE#. Sua lista e finalidades podem ser encontradas em man:rc[8].
+Além das condições correspondentes a um único serviço, existem meta-condições e seus scripts "placeholder" usados para garantir que certos grupos de operações sejam executados antes de outros. Estes são denotados por nomes em [.filename]#UPPERCASE#. Sua lista e propósitos podem ser encontrados no manual man:rc[8].
-Tenha em mente que colocar um nome de serviço na linha `REQUIRE:` não garante que o serviço estará realmente em execução no momento em que nosso script for iniciado. O serviço necessário pode falhar ao iniciar ou simplesmente ser desativado em man:rc.conf[5]. Obviamente, o man:rcorder[8] não pode controlar tais detalhes, e o man:rc[8] também não fará isso. Consequentemente, o aplicativo iniciado por nosso script deve ser capaz de lidar com quaisquer serviços necessários indisponíveis. Em certos casos, podemos ajudá-lo conforme discutido <<forcedep, below>>
+Lembre-se de que colocar o nome de um serviço na linha `REQUIRE:` não garante que o serviço realmente estará em execução no momento em que o script começar. O serviço necessário pode falhar ao iniciar ou simplesmente ser desativado em man:rc.conf[5]. Obviamente, o man:rcorder[8] não pode controlar esses detalhes e o man:rc[8] também não fará isso. Consequentemente, a aplicação iniciada pelo nosso script deve ser capaz de lidar com qualquer serviço necessário que esteja indisponível. Em certos casos, podemos ajudá-lo conforme discutido <<forcedep, abaixo>>
====
-➍ [[keywords]] Como lembramos do texto acima, as palavras-chave do man:rcorder[8] podem ser usadas para selecionar ou deixar alguns scripts. Ou seja, qualquer consumidor man:rcorder[8] pode especificar através das opções `-k` e `-s` que as palavras-chave estão na "keep list" e na "skip list", respectivamente. De todos os arquivos a serem classificados, o man:rcorder[8] selecionará apenas aqueles que tiverem uma palavra-chave da lista de manutenção (a menos que vazia) e não uma palavra-chave da lista de itens ignorados.
+[[keywords]]➍ Como lembramos do texto acima, as palavras-chave do man:rcorder[8] podem ser usadas para selecionar ou deixar de fora alguns scripts. Qualquer consumidor do man:rcorder[8] pode especificar, através das opções `-k` e `-s`, quais palavras-chave estarão na "lista de manutenção" e na "lista de exclusão", respectivamente. De todos os arquivos a serem ordenados por dependência, man:rcorder[8] escolherá apenas aqueles que tiverem uma palavra-chave da lista de manutenção (a menos que esteja vazia) e que não tiverem uma palavra-chave da lista de exclusão.
-No FreeBSD, o man:rcorder[8] é usado por [.filename]#/etc/rc# e [.filename]#/etc/rc.shutdown#. Esses dois scripts definem a lista padrão de palavras-chave do [.filename]#rc.d# do FreeBSD e seus significados da seguinte forma:
+No FreeBSD, o man:rcorder[8] é usado por [.filename]#/etc/rc# e [.filename]#/etc/rc.shutdown#. Esses dois scripts definem a lista padrão de palavras-chaves do FreeBSD [.filename]#rc.d# e seus significados da seguinte forma:
-➎ [[forcedep]] Para começar, `force_depend` deve ser usado com muito cuidado. Geralmente é melhor revisar a hierarquia de variáveis de configuração para seus scripts [.filename]#rc.# se eles forem interdependentes.
+nojail:: O serviço não é para ambiente man:jail[8]. Os procedimentos automáticos de inicialização e desligamento ignorarão o script se estiver dentro de uma jail.
-Se você ainda não pode fazer sem `force_depend`, o exemplo oferece uma expressão de como invocá-lo condicionalmente. No exemplo, nosso daemon `mumbled` requer que outro, `frotz`, seja iniciado antecipadamente. No entanto, `frotz` é opcional também; e man:rcorder[8] não sabe nada sobre esses detalhes. Felizmente, nosso script tem acesso a todas as variáveis man:rc.conf[5]. Se `frotz_enable` estiver como true, esperamos pelo melhor e dependemos de [.filename]#rc.d# para iniciar `frotz`. Caso contrário, nós forçadamente verificaremos o status de `frotz`. Finalmente, impomos nossa dependência ao `frotz` se ele não estiver sendo executado. Uma mensagem de aviso será emitida por `force_depend` porque ele deve ser chamado apenas se um erro de configuração for detectado.
+nostart:: O serviço deve ser iniciado manualmente ou não iniciado de forma alguma. O procedimento de inicialização automático ignorará o script. Em conjunto com a palavra-chave [.filename]#shutdown#, isso pode ser usado para escrever scripts que fazem algo apenas no desligamento do sistema.
+
+shutdown:: Este palavra-chave deve ser listada de forma __explícita__ se o serviço precisa ser parado antes do desligamento do sistema.
+
+[NOTE]
+====
+Quando o sistema está prestes a desligar, o arquivo [.filename]#/etc/rc.shutdown# é executado. Ele assume que a maioria dos scripts [.filename]#rc.d# não tem nada a fazer nesse momento. Portanto, o [.filename]#/etc/rc.shutdown# invoca seletivamente scripts [.filename]#rc.d# com a palavra-chave [.filename]#shutdown#, ignorando efetivamente o restante dos scripts. Para desligamento ainda mais rápido, o [.filename]#/etc/rc.shutdown# passa o comando [.filename]#faststop# para os scripts que executa para que eles pulem verificações preliminares, como a verificação do pidfile. Como os serviços dependentes devem ser interrompidos antes de suas dependências, o [.filename]#/etc/rc.shutdown# executa os scripts em ordem de dependência reversa. Se você está escrevendo um script [.filename]#rc.d# real, deve considerar se ele é relevante no momento do desligamento do sistema. Por exemplo, se o seu script faz seu trabalho apenas em resposta ao comando [.filename]#start#, então você
não precisa incluir essa palavra-chave. No entanto, se o seu script gerencia um serviço, é provavelmente uma boa ideia pará-lo antes que o sistema prossiga para o estágio final de sua sequência de desligamento descrita em man:halt[8]. Em particular, um serviço deve ser interrompido explicitamente se precisar de tempo considerável ou ações especiais para ser desligado corretamente. Um exemplo típico desse tipo de serviço é um mecanismo de banco de dados.
+====
+
+[[forcedep]] ➎ Em primeiro lugar, `force_depend` deve ser usado com muito cuidado. Geralmente, é melhor revisar a hierarquia das variáveis de configuração para seus scripts [.filename]#rc.d# se eles são interdependentes.
+
+Se ainda assim você não puder abrir mão do `force_depend`, o exemplo oferece um exemplo de como invocá-lo condicionalmente. No exemplo, nosso daemon `mumbled` requer que outro daemon, `frotz`, seja iniciado antecipadamente. No entanto, `frotz` também é opcional; e o man:rcorder[8] não conhece esses detalhes. Felizmente, nosso script tem acesso a todas as variáveis de man:rc.conf[5]. Se `frotz_enable` for verdadeiro, esperamos o melhor e confiamos no [.filename]#rc.d# para ter iniciado `frotz`. Caso contrário, verificamos forçadamente o status de `frotz`. Finalmente, impomos nossa dependência em `frotz` se ele não estiver em execução. Uma mensagem de aviso será emitida por `force_depend`, pois ele só deve ser invocado se uma configuração incorreta for detectada.
[[rcng-args]]
== Dando mais flexibilidade a um script rc.d
-Quando chamado durante a inicialização ou desligamento, um script [.filename]#rc.d# deve agir em todo o subsistema pelo qual é responsável. Por exemplo, [.filename]#/etc/rc.d/netif# deve iniciar ou parar todas as interfaces de rede descritas por man:rc.conf[5]. Qualquer tarefa pode ser indicada exclusivamente por um único argumento de comando, como `start` ou `stop`. Entre a inicialização e o desligamento, os scripts [.filename]#rc.d# ajudam o administrador a controlar o sistema em execução, e é quando surge a necessidade de mais flexibilidade e precisão. Por exemplo, o administrador pode querer adicionar as configurações de uma nova interface de rede ao man:rc.conf[5] e então iniciá-lo sem interferir o funcionamento das interfaces existentes. Da próxima vez, o administrador pode precisar desligar uma única interface de rede. No espírito da linha de comando, o respectivo script [.filename]#rc.d# solicita um argumento extra, o nome da interface.
+Quando invocado durante a inicialização ou desligamento, um script [.filename]#rc.d# deve agir em todo o subsistema pelo qual é responsável. Por exemplo, o [.filename]#/etc/rc.d/netif# deve iniciar ou parar todas as interfaces de rede descritas em man:rc.conf[5]. Cada tarefa pode ser indicada por um único argumento de comando, como `start` ou `stop`. Entre a inicialização e o desligamento, os scripts [.filename]#rc.d# ajudam o administrador a controlar o sistema em execução e é quando surge a necessidade de mais flexibilidade e precisão. Por exemplo, o administrador pode querer adicionar as configurações de uma nova interface de rede em man:rc.conf[5] e, em seguida, iniciá-la sem interferir na operação das interfaces existentes. Na próxima vez, o administrador pode precisar desligar uma única interface de rede. Para facilitar o uso na linha de comando, o respectivo script [.filename]#rc.d# pede um argumento extra, o nome da interface.
-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.
+Felizmente, o 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 mudanças 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 ter acesso aos argumentos adicionais da linha de comando? Ele deve simplesmente pegá-los diretamente? De maneira alguma! Em primeiro lugar, uma função do man:sh[1] não tem acesso aos parâmetros posicionais de quem a chamou, mas o man:rc.subr[8] é apenas um conjunto dessas funções. Em segundo lugar, a boa prática do [.filename]#rc.d# dita que é responsabilidade do 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.
+Portanto, a abordagem adotada pelo man:rc.subr[8] é a seguinte: `run_rc_command` passa todos os seus argumentos, exceto o primeiro, ao respectivo método sem alterações. O primeiro argumento omitido é o nome do método em si: `start`, `stop`, etc. Ele será removido por `run_rc_command`, então o que é `$2` na linha de comando original será apresentado como `$1` para o método, e assim por diante.
Para ilustrar essa oportunidade, vamos modificar o script fictício primitivo para que suas mensagens dependam dos argumentos adicionais fornecidos. Aqui vamos nós:
@@ -565,43 +579,45 @@ run_rc_command "$@" <.>
Quais mudanças essenciais podemos notar no script?
-➊ Todos os argumentos digitados após `start` podem terminar como parâmetros posicionais para o respectivo método. Podemos usá-los de qualquer maneira de acordo com nossa tarefa, habilidades e fantasia. No exemplo atual, apenas passamos todos eles para man:echo[1] como uma cadeia na linha seguinte - note `$*` entre aspas duplas. Aqui está como o script pode ser chamado agora:
+➊ Todos os argumentos que você digita após `start` podem acabar como parâmetros posicionais para o respectivo método. Podemos usá-los de qualquer maneira de acordo com nossa tarefa, habilidades e gosto. No exemplo atual, simplesmente passamos todos eles para o man:echo[1] como uma única string na próxima linha - observe o `$*` dentro das aspas duplas. Aqui está como o script pode ser invocado agora:
-[source,shell]
+[source, shell]
....
# /etc/rc.d/dummy start
Nothing started.
+
# /etc/rc.d/dummy start Hello world!
Greeting message: Hello world!
....
-➋ O mesmo se aplica a qualquer método que nosso script forneça, não apenas a um método padrão. Nós adicionamos um método customizado chamado `kiss`, e ele pode tirar proveito dos argumentos extras da mesma forma que o `start` tira. Por exemplo:
+➋ O mesmo se aplica a qualquer método que nosso script ofereça, não apenas a um padrão. Adicionamos um método personalizado chamado `kiss`, e ele pode tirar proveito dos argumentos extras da mesma forma que o `start` pode. Por exemplo:
-[source,shell]
+[source, shell]
....
# /etc/rc.d/dummy kiss
A ghost gives you a kiss.
+
# /etc/rc.d/dummy kiss Once I was Etaoin Shrdlu...
A ghost gives you a kiss and whispers: Once I was Etaoin Shrdlu...
....
-➌ Se quisermos apenas passar todos os argumentos extras para qualquer método, podemos simplesmente substituir `"$@"` por `"$ 1"` na última linha do nosso script, onde invocamos o `run_rc_command`.
+➌ Se quisermos apenas passar todos os argumentos extras para qualquer método, podemos simplesmente substituir `"$1"` por `"$@"` na última linha do nosso script, onde invocamos `run_rc_command`.
[IMPORTANT]
====
-Um programador man:sh[1] deve entender a diferença sutil entre `$*` e `$@` como as formas de designar todos os parâmetros posicionais. Para sua discussão aprofundada, consulte um bom manual sobre programação de scripts man:sh[1]. _Não_ use estas expressões até que você as compreenda completamente, porque o uso incorreto delas resultará em scripts inseguros e contendo bugs.
+Um programador em man:sh[1] deve entender a diferença sutil entre `$*` e `$@` como formas de designar todos os parâmetros posicionais. Para uma discussão aprofundada, consulte um bom manual de man:sh[1]. Não use essas expressões até entender completamente o seu uso, pois o uso incorreto pode resultar em scripts com bugs e inseguros.
====
[NOTE]
====
-Atualmente, o `run_rc_command` pode ter um bug que o impede de manter os limites originais entre os argumentos. Ou seja, argumentos com espaços em branco incorporados podem não ser processados corretamente. O bug deriva do uso inadequado de `$*`.
+Atualmente, o `run_rc_command` pode ter um bug que o impede de manter as fronteiras originais entre os argumentos. Ou seja, argumentos com espaços em branco embutidos podem não ser processados corretamente. O bug decorre do uso inadequado de `$*`.
====
[[rcng-furthur]]
== Leitura adicional
-[[lukem]]http://www.mewburn.net/luke/papers/rc.d.pdf[O artigo original de Luke Mewburn] oferece uma visão geral do [.filename]#rc.d# e o raciocínio detalhado que o levou a suas decisões de design. Ele fornece informações sobre toda o framework do [.filename]#rc.d# e o seu lugar em um moderno sistema operacional BSD.
+[[lukem]]http://www.mewburn.net/luke/papers/rc.d.pdf[O artigo original de Luke Mewburn] oferece uma visão geral do [.filename]#rc.d# e uma justificativa detalhada para suas decisões de design. Ele fornece uma compreensão do quadro geral do [.filename]#rc.d# e seu lugar em um sistema operacional BSD moderno.
-[[manpages]]As páginas de manual man:rc[8], man:rc.subr[8] e man:rcorder[8] documentam os componentes do [.filename]#rc.d# com grande detalhe. Você não pode usar totalmente o poder do [.filename]#rc.d# sem estudar as páginas de manual e se referir a elas enquanto escreve seus próprios scripts.
+[[manpages]]As páginas do manual para man:rc[8], man:rc.subr[8] e man:rcorder[8] documentam em detalhes os componentes do sistema [.filename]#rc.d#. Você não pode aproveitar completamente o poder do [.filename]#rc.d# sem estudar as páginas do manual e consultá-las ao escrever seus próprios scripts.
-A sua principal fonte de inspiração são os exemplos da vida real, existentes em no [.filename]#/etc/rc.d# de um sistema vivo. Seu conteúdo é fácil e agradável de ler, porque a maioria dos cantos ásperos estão escondidos fundo no man:rc.subr[8]. Tenha em mente que os scripts [.filename]#/etc/rc.d# não foram escritos por anjos, então eles podem sofrer de bugs e decisões sub-ótimas de design. Agora você pode melhorá-los!
+A principal fonte de exemplos práticos e funcionais é o diretório [.filename]#/etc/rc.d# em um sistema em operação. O seu conteúdo é fácil e agradável de ler, pois a maioria das partes difíceis está escondida profundamente em man:rc.subr[8]. No entanto, tenha em mente que os scripts em [.filename]#/etc/rc.d# não foram escritos por anjos, então eles podem conter bugs e decisões de design subótimas. Agora você pode melhorá-los!
diff --git a/documentation/content/pt-br/articles/rc-scripting/_index.po b/documentation/content/pt-br/articles/rc-scripting/_index.po
new file mode 100644
index 0000000000..eaee8ffb75
--- /dev/null
+++ b/documentation/content/pt-br/articles/rc-scripting/_index.po
@@ -0,0 +1,2337 @@
+# SOME DESCRIPTIVE TITLE
+# Copyright (C) YEAR The FreeBSD Project
+# This file is distributed under the same license as the FreeBSD Documentation package.
+# Danilo G. Baio <dbaio@FreeBSD.org>, 2021, 2022.
+# Edson Brandi <ebrandi@freebsd.org>, 2023.
+# "Danilo G. Baio" <dbaio@FreeBSD.org>, 2023.
+msgid ""
+msgstr ""
+"Project-Id-Version: FreeBSD Documentation VERSION\n"
+"POT-Creation-Date: 2022-07-07 23:23-0300\n"
+"PO-Revision-Date: 2023-04-30 08:49+0000\n"
+"Last-Translator: Edson Brandi <ebrandi@freebsd.org>\n"
+"Language-Team: Portuguese (Brazil) <https://translate-dev.freebsd.org/"
+"projects/documentation/articlesrc-scripting_index/pt_BR/>\n"
+"Language: pt_BR\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"Plural-Forms: nplurals=2; plural=n > 1;\n"
+"X-Generator: Weblate 4.17\n"
+
+#. type: YAML Front Matter: description
+#: documentation/content/en/articles/rc-scripting/_index.adoc:1
+#, no-wrap
+msgid "A guide to writing new rc.d scripts and understanding those already written"
+msgstr ""
+"Um guia para escrever novos scripts rc.d e entender aqueles que já existem"
+
+#. type: Title =
+#: documentation/content/en/articles/rc-scripting/_index.adoc:1
+#: documentation/content/en/articles/rc-scripting/_index.adoc:12
+#, no-wrap
+msgid "Practical rc.d scripting in BSD"
+msgstr "Scripting rc.d na prática no BSD"
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:45
+msgid "Abstract"
+msgstr "Resumo"
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:49
+msgid ""
+"Beginners may find it difficult to relate the facts from the formal "
+"documentation on the BSD [.filename]#rc.d# framework with the practical "
+"tasks of [.filename]#rc.d# scripting. In this article, we consider a few "
+"typical cases of increasing complexity, show [.filename]#rc.d# features "
+"suited for each case, and discuss how they work. Such an examination should "
+"provide reference points for further study of the design and efficient "
+"application of [.filename]#rc.d#."
+msgstr ""
+"Os iniciantes podem achar difícil relacionar os fatos da documentação formal "
+"sobre o framework [.filename]#rc.d# do BSD com as tarefas práticas de "
+"escrever scripts [.filename]#rc.d#. Neste artigo, consideramos alguns casos "
+"típicos de crescente complexidade, mostramos recursos do [.filename]#rc.d# "
+"adequados para cada caso e discutimos como eles funcionam. Essa análise deve "
+"fornecer pontos de referência para estudos posteriores do design e aplicação "
+"eficiente do [.filename]#rc.d#."
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:51
+msgid "'''"
+msgstr "'''"
+
+#. type: Title ==
+#: documentation/content/en/articles/rc-scripting/_index.adoc:55
+#, no-wrap
+msgid "Introduction"
+msgstr "Introdução"
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:61
+msgid ""
+"The historical BSD had a monolithic startup script, [.filename]#/etc/rc#. "
+"It was invoked by man:init[8] at system boot time and performed all userland "
+"tasks required for multi-user operation: checking and mounting file systems, "
+"setting up the network, starting daemons, and so on. The precise list of "
+"tasks was not the same in every system; admins needed to customize it. With "
+"few exceptions, [.filename]#/etc/rc# had to be modified, and true hackers "
+"liked it."
+msgstr ""
+"No histórico BSD, havia um script de inicialização monolítico, [.filename]#/"
+"etc/rc#. Ele era invocado pelo man:init[8] no momento da inicialização do "
+"sistema e realizava todas as tarefas de usuário necessárias para a operação "
+"multiusuário: verificação e montagem de sistemas de arquivos, configuração "
+"da rede, inicialização de daemons e assim por diante. A lista precisa de "
+"tarefas não era a mesma em todos os sistemas; os administradores precisavam "
+"personalizá-la. Com poucas exceções, o [.filename]#/etc/rc# tinha que ser "
+"modificado, e os verdadeiros hackers gostavam disso."
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:67
+msgid ""
+"The real problem with the monolithic approach was that it provided no "
+"control over the individual components started from [.filename]#/etc/rc#. "
+"For instance, [.filename]#/etc/rc# 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# 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."
+msgstr ""
+"O problema real com a abordagem monolítica era que ela não fornecia controle "
+"sobre os componentes individuais iniciados a partir do [.filename]#/etc/rc#. "
+"Por exemplo, o [.filename]#/etc/rc# não podia reiniciar um único daemon. O "
+"administrador do sistema tinha que encontrar o processo do daemon "
+"manualmente, matá-lo, aguardar até que ele realmente finalizasse, navegar "
+"por [.filename]#/etc/rc# em busca das flags e, finalmente, digitar a linha "
+"de comando completa para iniciar o daemon novamente. A tarefa se tornaria "
+"ainda mais difícil e propensa a erros se o serviço a ser reiniciado "
+"consistisse em mais de um daemon ou exigisse ações adicionais. Em poucas "
+"palavras, o script único falhou em cumprir o objetivo pelo qual um script é "
+"criado: tornar a vida do administrador do sistema mais fácil."
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:74
+msgid ""
+"Later there was an attempt to split out some parts of [.filename]#/etc/rc# "
+"for the sake of starting the most important subsystems separately. The "
+"notorious example was [.filename]#/etc/netstart# 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# mutated into [.filename]#/etc/rc."
+"network#. The latter was no longer an ordinary script; it comprised of "
+"large, tangled man:sh[1] functions called from [.filename]#/etc/rc# at "
+"different stages of system startup. However, as the startup tasks grew "
+"diverse and sophisticated, the \"quasi-modular\" approach became even more "
+"of a drag than the monolithic [.filename]#/etc/rc# had been."
+msgstr ""
+"Mais tarde, houve uma tentativa de dividir algumas partes do [.filename]#/"
+"etc/rc# para iniciar os subsistemas mais importantes separadamente. O "
+"exemplo notório foi o [.filename]#/etc/netstart# para iniciar a rede. Isso "
+"permitiu o acesso à rede no modo de usuário único, mas não se integrou bem "
+"ao processo de inicialização automática porque partes de seu código "
+"precisavam intercalar com ações essencialmente não relacionadas à rede. Foi "
+"por isso que o [.filename]#/etc/netstart# se transformou em [.filename]#/etc/"
+"rc.network#. Este último não era mais um script comum; era composto de "
+"grandes funções man:sh[1] complexas chamadas pelo [.filename]#/etc/rc# em "
+"diferentes estágios da inicialização do sistema. No entanto, à medida que as "
+"tarefas de inicialização ficaram mais diversas e sofisticadas, a abordagem "
+"\"quase modular\" tornou-se ainda mais pesada do que o monolítico [."
+"filename]#/etc/rc# tinha sido."
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:82
+msgid ""
+"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."
+msgstr ""
+"Sem um framework limpo e bem projetado, os scripts de inicialização tiveram "
+"que se dobrar para atender às necessidades dos sistemas operacionais "
+"baseados em BSD que estavam em rápida evolução. Tornou-se evidente, "
+"finalmente, que mais etapas eram necessárias para se chegar a um sistema [."
+"filename]#rc# refinado, granular e extensível. Assim nasceu o [.filename]#rc."
+"d# do BSD. Seus pais reconhecidos foram Luke Mewburn e a comunidade NetBSD. "
+"Mais tarde, foi importado para o FreeBSD. Seu nome se refere ao local dos "
+"scripts do sistema para serviços individuais, que está em [.filename]#/etc/rc"
+".d#. Em breve, aprenderemos mais sobre os componentes do sistema [."
+"filename]#rc.d# e veremos como os scripts individuais são invocados."
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:93
+msgid ""
+"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."
+msgstr ""
+"As ideias básicas por trás do [.filename]#rc.d# do BSD são _modularidade "
+"fina_ e __reutilização de código__. _Modularidade fina_ significa que cada "
+"\"serviço\" básico, como um daemon do sistema ou uma tarefa de inicialização "
+"primitiva, possui seu próprio script man:sh[1] capaz de iniciar o serviço, "
+"pará-lo, recarregá-lo e verificar seu status. Uma ação específica é "
+"escolhida pelo argumento da linha de comando do script. O script [."
+"filename]#/etc/rc# ainda conduz a inicialização do sistema, mas agora ele "
+"apenas invoca os scripts menores um por um com o argumento `start`. Também é "
+"fácil realizar tarefas de desligamento executando o mesmo conjunto de "
+"scripts com o argumento `stop`, que é feito por [.filename]#/etc/rc.shutdown#"
+". Observe como isso segue de perto a maneira Unix de ter um conjunto de "
+"ferramentas especializadas pequenas, cada uma cumprindo sua tarefa da melhor "
+"maneira possível. _Reutilização de código_ significa que operações comuns "
+"são implementadas como funções man:sh[1] e coletadas em [.filename]#/etc/rc."
+"subr#. Agora, um script típico pode ser composto apenas de algumas linhas de "
+"código man:sh[1]. Finalmente, uma parte importante do framework [."
+"filename]#rc.d# é o man:rcorder[8], que ajuda o [.filename]#/etc/rc# a "
+"executar os pequenos scripts de maneira ordenada com respeito às "
+"dependências entre eles. Isso também pode ajudar o [.filename]#/etc/rc."
+"shutdown#, porque a ordem apropriada para a sequência de desligamento é "
+"oposta à de inicialização."
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:101
+msgid ""
+"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."
+msgstr ""
+"O design do BSD [.filename]#rc.d# é descrito no <<lukem, artigo original de "
+"Luke Mewburn>>, e os componentes do [.filename]#rc.d# são documentados em "
+"grande detalhe nas <<manpages, respectivas páginas do manual>>. No entanto, "
+"pode não ser óbvio para um iniciante no [.filename]#rc.d# como ele deve unir "
+"as numerosas partes para criar um script bem estruturado para uma tarefa "
+"específica. Portanto, este artigo tentará abordar o [.filename]#rc.d# de "
+"forma diferente. Mostrará quais recursos devem ser usados em vários casos "
+"típicos e por que. Observe que este não é um documento de \"como fazer\", "
+"porque nosso objetivo não é fornecer receitas prontas, mas mostrar algumas "
+"entradas fáceis no mundo do [.filename]#rc.d#. Este artigo também não "
+"substitui as páginas do manual relevantes. Não hesite em consultá-las para "
+"obter documentação mais formal e completa enquanto lê este artigo."
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:105
+msgid ""
+"There are prerequisites to understanding this article. First of all, you "
+"should be familiar with the man:sh[1] scripting language in order to master "
+"[.filename]#rc.d#. In addition, you should know how the system performs "
+"userland startup and shutdown tasks, which is described in man:rc[8]."
+msgstr ""
+"Existem pré-requisitos para entender este artigo. Em primeiro lugar, você "
+"deve estar familiarizado com a linguagem de script man:sh[1] para dominar o ["
+".filename]#rc.d#. Além disso, você deve saber como o sistema realiza tarefas "
+"de inicialização e desligamento do espaço do usuário, o que é descrito em "
+"man:rc[8]."
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:108
+msgid ""
+"This article focuses on the FreeBSD branch of [.filename]#rc.d#. "
+"Nevertheless, it may be useful to NetBSD developers, too, because the two "
+"branches of BSD [.filename]#rc.d# not only share the same design but also "
+"stay similar in their aspects visible to script authors."
+msgstr ""
+"Este artigo foca no ramo do FreeBSD do [.filename]#rc.d#. No entanto, ele "
+"pode ser útil também para desenvolvedores do NetBSD, pois os dois ramos do [."
+"filename]#rc.d# não apenas compartilham o mesmo design, mas também "
+"permanecem similares em seus aspectos visíveis aos autores de scripts."
+
+#. type: Title ==
+#: documentation/content/en/articles/rc-scripting/_index.adoc:110
+#, no-wrap
+msgid "Outlining the task"
+msgstr "Esboçando a tarefa"
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:114
+msgid ""
+"A little consideration before starting `$EDITOR` will not hurt. In order to "
+"write a well-tempered [.filename]#rc.d# script for a system service, we "
+"should be able to answer the following questions first:"
+msgstr ""
+"Uma pequena reflexão antes de iniciar o `$EDITOR` não fará mal. Para "
+"escrever um script [.filename]#rc.d# bem elaborado para um serviço do "
+"sistema, devemos ser capazes de responder às seguintes perguntas primeiro:"
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:116
+msgid "Is the service mandatory or optional?"
+msgstr "O serviço é obrigatório ou opcional?"
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:117
+msgid ""
+"Will the script serve a single program, e.g., a daemon, or perform more "
+"complex actions?"
+msgstr ""
+"O script servirá um único programa, por exemplo, um daemon, ou realizará "
+"ações mais complexas?"
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:118
+msgid "Which other services will our service depend on, and vice versa?"
+msgstr "De quais outros serviços nosso serviço dependerá e vice-versa?"
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:120
+msgid ""
+"From the examples that follow we will see why it is important to know the "
+"answers to these questions."
+msgstr ""
+"A partir dos exemplos que se seguem, veremos o porque é importante conhecer "
+"as respostas a essas perguntas."
+
+#. type: Title ==
+#: documentation/content/en/articles/rc-scripting/_index.adoc:122
+#, no-wrap
+msgid "A dummy script"
+msgstr "Um script fictício"
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:125
+msgid ""
+"The following script just emits a message each time the system boots up:"
+msgstr ""
+"O script a seguir apenas emite uma mensagem toda vez que o sistema é "
+"inicializado:"
+
+#. type: delimited block . 4
+#: documentation/content/en/articles/rc-scripting/_index.adoc:129
+#, no-wrap
+msgid "#!/bin/sh <.>\n"
+msgstr "#!/bin/sh <.>\n"
+
+#. type: delimited block . 4
+#: documentation/content/en/articles/rc-scripting/_index.adoc:131
+#, no-wrap
+msgid ". /etc/rc.subr <.>\n"
+msgstr ". /etc/rc.subr <.>\n"
+
+#. type: delimited block . 4
+#: documentation/content/en/articles/rc-scripting/_index.adoc:135
+#, no-wrap
+msgid ""
+"name=\"dummy\" <.>\n"
+"start_cmd=\"${name}_start\" <.>\n"
+"stop_cmd=\":\" <.>\n"
+msgstr ""
+"name=\"dummy\" <.>\n"
+"start_cmd=\"${name}_start\" <.>\n"
+"stop_cmd=\":\" <.>\n"
+
+#. type: delimited block . 4
+#: documentation/content/en/articles/rc-scripting/_index.adoc:140
+#, no-wrap
+msgid ""
+"dummy_start() <.>\n"
+"{\n"
+"\techo \"Nothing started.\"\n"
+"}\n"
+msgstr ""
+"dummy_start() <.>\n"
+"{\n"
+"\techo \"Nothing started.\"\n"
+"}\n"
+
+#. type: delimited block . 4
+#: documentation/content/en/articles/rc-scripting/_index.adoc:143
+#, no-wrap
+msgid ""
+"load_rc_config $name <.>\n"
+"run_rc_command \"$1\" <.>\n"
+msgstr ""
+"load_rc_config $name <.>\n"
+"run_rc_command \"$1\" <.>\n"
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:146
+msgid "Things to note are:"
+msgstr "Os pontos a serem observados são:"
+
+#. type: Plain text
+#: documentation/content/en/articles/rc-scripting/_index.adoc:152
+msgid ""
+"➊ An interpreted script should begin with the magic \"shebang\" "
+"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 man:chmod[1].) For example, "
+"a system admin can run our script manually, from the command line:"
+msgstr ""
+"➊ Um script interpretado deve começar com a linha mágica \"shebang\". "
+"Essa linha especifica o programa interpretador para o script. Devido à linha "
+"shebang, o script pode ser invocado exatamente como um programa binário, "
+"desde que tenha o bit de execução definido. (Veja man:chmod[1].) Por "
+"exemplo, um administrador do sistema pode executar nosso script manualmente, "
+"a partir da linha de comando:"
+
+#. type: delimited block . 4
+#: documentation/content/en/articles/rc-scripting/_index.adoc:156
+#, no-wrap
+msgid "# /etc/rc.d/dummy start\n"
+msgstr "# /etc/rc.d/dummy start\n"
+
+#. type: delimited block = 4
+#: documentation/content/en/articles/rc-scripting/_index.adoc:162
+msgid ""
+"In order to be properly managed by the [.filename]#rc.d# framework, its "
+"scripts need to be written in the man:sh[1] 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# (for the "
+"system) or [.filename]#/usr/local/sbin# (for ports) and call it from a man:"
+"sh[1] script in the appropriate [.filename]#rc.d# directory."
+msgstr ""
+"Para ser gerenciado corretamente pelo framework [.filename]#rc.d#, os "
+"scripts devem ser escritos na linguagem man:sh[1]. Se você tiver um serviço "
+"ou port que usa um utilitário de controle binário ou uma rotina de "
+"inicialização escrita em outra linguagem, instale esse elemento em [."
+"filename]#/usr/sbin# (para o sistema) ou [.filename]#/usr/local/sbin# (para "
+"ports) e chame-o a partir de um script man:sh[1] no diretório [.filename]#rc."
+"d# apropriado."
+
+#. type: delimited block = 4
+#: documentation/content/en/articles/rc-scripting/_index.adoc:167
+msgid ""
+"If you would like to learn the details of why [.filename]#rc.d# scripts must "
+"be written in the man:sh[1] language, see how [.filename]#/etc/rc# invokes "
*** 1909 LINES SKIPPED ***