Date: Sun, 30 Apr 2023 09:04:05 GMT From: Edson Brandi <ebrandi@FreeBSD.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org Subject: git: e310196197 - main - Article rc-scripting translated to pt_BR and synced with doc tree version 98c736dd127a2096dc08252d1082300f2ec28ab5 Message-ID: <202304300904.33U945oI086393@gitrepo.freebsd.org>
next in thread | raw e-mail | index | archive | help
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 ***
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202304300904.33U945oI086393>