Translation

(itstool) path: sect1/para
English
Things to note are:
33/190
Context English Portuguese (Brazil) State
Later there was an attempt to split out some parts of <filename>/etc/rc</filename> for the sake of starting the most important subsystems separately. The notorious example was <filename>/etc/netstart</filename> to bring up networking. It did allow for accessing the network from single-user mode, but it did not integrate well into the automatic startup process because parts of its code needed to interleave with actions essentially unrelated to networking. That was why <filename>/etc/netstart</filename> mutated into <filename>/etc/rc.network</filename>. The latter was no longer an ordinary script; it comprised of large, tangled <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> functions called from <filename>/etc/rc</filename> at different stages of system startup. However, as the startup tasks grew diverse and sophisticated, the <quote>quasi-modular</quote> approach became even more of a drag than the monolithic <filename>/etc/rc</filename> had been. Mais tarde, houve uma tentativa de dividir algumas partes do <filename>/etc/rc</filename> para iniciar os subsistemas mais importantes separadamente. O exemplo notório foi o <filename>/etc/netstart</filename> 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</filename> mudou para <filename>/etc/rc.network</filename>. Este último não era mais um script comum; ele era composto por um emaranhado de funções <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> chamadas pelo <filename>/etc/rc</filename> 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 <quote>quase modular</quote> tornou-se ainda mais engessada do que o monolítico <filename>/etc/rc</filename>.
Without a clean and well-designed framework, the startup scripts had to bend over backwards to satisfy the needs of rapidly developing BSD-based operating systems. It became obvious at last that more steps are necessary on the way to a fine-grained and extensible <filename>rc</filename> system. Thus BSD <filename>rc.d</filename> was born. Its acknowledged fathers were Luke Mewburn and the NetBSD community. Later it was imported into FreeBSD. Its name refers to the location of system scripts for individual services, which is in <filename>/etc/rc.d</filename>. Soon we will learn about more components of the <filename>rc.d</filename> system and see how the individual scripts are invoked. 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</filename> extensível e customizável. Assim nasceu o BSD <filename>rc.d</filename>. 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</filename>. Em breve, vamos aprender sobre mais componentes do sistema <filename>rc.d</filename> e vamos ver como os scripts individuais são invocados.
The basic ideas behind BSD <filename>rc.d</filename> are <emphasis>fine modularity</emphasis> and <emphasis>code reuse</emphasis>. <emphasis>Fine modularity</emphasis> means that each basic <quote>service</quote> such as a system daemon or primitive startup task gets its own <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> script able to start the service, stop it, reload it, check its status. A particular action is chosen by the command-line argument to the script. The <filename>/etc/rc</filename> script still drives system startup, but now it merely invokes the smaller scripts one by one with the <option>start</option> argument. It is easy to perform shutdown tasks as well by running the same set of scripts with the <option>stop</option> argument, which is done by <filename>/etc/rc.shutdown</filename>. Note how closely this follows the Unix way of having a set of small specialized tools, each fulfilling its task as well as possible. <emphasis>Code reuse</emphasis> means that common operations are implemented as <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> functions and collected in <filename>/etc/rc.subr</filename>. Now a typical script can be just a few lines' worth of <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> code. Finally, an important part of the <filename>rc.d</filename> framework is <citerefentry><refentrytitle>rcorder</refentrytitle><manvolnum>8</manvolnum></citerefentry>, which helps <filename>/etc/rc</filename> to run the small scripts orderly with respect to dependencies between them. It can help <filename>/etc/rc.shutdown</filename>, too, because the proper order for the shutdown sequence is opposite to that of startup. As idéias básicas por trás do BSD <filename>rc.d</filename> são <emphasis>modularidade fina</emphasis> e <emphasis>reutilização de código</emphasis>. <emphasis>Modularidade fina</emphasis> significa que cada <quote>serviço básico</quote>, como um daemon do sistema ou uma tarefa de inicialização primitiva, obtém seu próprio script <citerefentry><refentrytitle>sh</refentrytitle> <manvolnum></manvolnum></citerefentry> 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</filename> ainda comanda a inicialização do sistema, mas agora ele simplesmente invoca os scripts menores um por um com o argumento <option>start</option>. É fácil executar tarefas de desligamento executando o mesmo conjunto de scripts com o argumento <option>stop</option>, o que é feito pelo <filename>/etc/rc.shutdown</filename>. 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. <emphasis>Reutilização de código</emphasis> significa que operações comuns são implementadas como funções <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> e coletadas em <filename>/etc/rc.subr </filename>. Agora, um script típico pode conter apenas algumas linhas de código <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum> </citerefentry>. Finalmente, uma parte importante do framework do <filename>rc.d</filename> é <citerefentry> <refentrytitle>rcorder</refentrytitle> <manvolnum>8</manvolnum> </citerefentry>, o qual ajuda o <filename>/etc/rc</filename> a executar os pequenos scripts ordenadamente em relação às dependências entre eles. Ele também pode ajudar o <filename>/etc/rc.shutdown</filename>, porque a ordem apropriada para a sequência de encerramento é oposta à da inicialização.
The BSD <filename>rc.d</filename> design is described in <link linkend="lukem">the original article by Luke Mewburn</link>, and the <filename>rc.d</filename> components are documented in great detail in <link linkend="manpages">the respective manual pages</link>. However, it might not appear obvious to an <filename>rc.d</filename> newbie how to tie the numerous bits and pieces together in order to create a well-styled script for a particular task. Therefore this article will try a different approach to describe <filename>rc.d</filename>. It will show which features should be used in a number of typical cases, and why. Note that this is not a how-to document because our aim is not at giving ready-made recipes, but at showing a few easy entrances into the <filename>rc.d</filename> realm. Neither is this article a replacement for the relevant manual pages. Do not hesitate to refer to them for more formal and complete documentation while reading this article. O design do BSD <filename>rc.d</filename> é descrito no <link linkend="lukem">artigo original de Luke Mewburn</link>, e os componentes do <filename>rc.d</filename> são documentados em grande detalhe nas <link linkend="manpages">respectivas páginas de manual</link>. No entanto, pode não parecer óbvio para um novato em <filename>rc.d</filename> 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</filename>. 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</filename>. 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.
There are prerequisites to understanding this article. First of all, you should be familiar with the <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> scripting language in order to master <filename>rc.d</filename>. In addition, you should know how the system performs userland startup and shutdown tasks, which is described in <citerefentry><refentrytitle>rc</refentrytitle><manvolnum>8</manvolnum></citerefentry>. Existem pré-requisitos para entender este artigo. Primeiro de tudo, você deve estar familiarizado com a linguagem de script <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> para poder dominar o <filename>rc.d</filename>. Além disso, você deve saber como o sistema executa as tarefas de inicialização e encerramento do userland, o que está descrito em <citerefentry><refentrytitle>rc</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
This article focuses on the FreeBSD branch of <filename>rc.d</filename>. Nevertheless, it may be useful to NetBSD developers, too, because the two branches of BSD <filename>rc.d</filename> not only share the same design but also stay similar in their aspects visible to script authors. Este artigo foca no branch <filename>rc.d</filename> do FreeBSD. No entanto, ele também pode ser útil para os desenvolvedores do NetBSD, porque os dois branchs <filename>rc.d</filename> do BSD não apenas compartilham o mesmo design, mas também permanecem similares em seus aspectos visíveis aos autores do script.
Outlining the task Esboçando a tarefa
A little consideration before starting <envar>$EDITOR</envar> will not hurt. In order to write a well-tempered <filename>rc.d</filename> script for a system service, we should be able to answer the following questions first: Um pouco de consideração antes de iniciar o <envar>$EDITOR</envar> não irá prejudicar. Para escrever um script <filename>rc.d</filename> corretamente customizado para um serviço do sistema, devemos poder responder as seguintes questões primeiro:
Is the service mandatory or optional? O serviço é obrigatório ou opcional?
Will the script serve a single program, e.g., a daemon, or perform more complex actions? O script servirá um único programa, por exemplo, um daemon, ou realizará ações mais complexas?
Which other services will our service depend on, and vice versa? De quais outros serviços nosso serviço dependerá e vice-versa?
From the examples that follow we will see why it is important to know the answers to these questions. A partir dos exemplos que se seguem, veremos o porque é importante conhecer as respostas a essas perguntas.
A dummy script Um script fictício
The following script just emits a message each time the system boots up: O script a seguir apenas emite uma mensagem toda vez que o sistema é inicializado:
#!/bin/sh<co xml:id="rcng-dummy-shebang"/>

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

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

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

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

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

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

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

load_rc_config $name<co xml:id="rcng-dummy-loadconfig"/>
run_rc_command "$1"<co xml:id="rcng-dummy-runcommand"/>
Things to note are: Os pontos a serem observadas são:
An interpreted script should begin with the magic <quote>shebang</quote> line. That line specifies the interpreter program for the script. Due to the shebang line, the script can be invoked exactly like a binary program provided that it has the execute bit set. (See <citerefentry><refentrytitle>chmod</refentrytitle><manvolnum>1</manvolnum></citerefentry>.) For example, a system admin can run our script manually, from the command line: Um script interpretado deve começar com a linha mágica <quote>shebang</quote>. 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 <citerefentry><refentrytitle>chmod</refentrytitle><manvolnum>1</manvolnum></citerefentry>.) Por exemplo, um administrador do sistema pode executar nosso script manualmente, a partir da linha de comando:
<prompt>#</prompt> <userinput>/etc/rc.d/dummy start</userinput> <prompt>#</prompt> <userinput>/etc/rc.d/dummy start</userinput>
In order to be properly managed by the <filename>rc.d</filename> framework, its scripts need to be written in the <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> language. If you have a service or port that uses a binary control utility or a startup routine written in another language, install that element in <filename>/usr/sbin</filename> (for the system) or <filename>/usr/local/sbin</filename> (for ports) and call it from a <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> script in the appropriate <filename>rc.d</filename> directory. Para ser adequadamente gerenciado pelo framework do <filename>rc.d</filename>, seus scripts precisam ser escritos na linguagem <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry>. 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</filename> (para o sistema) ou em <filename>/usr/local/sbin</filename> (para um port) e invoque-o por meio de um script <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> no diretório apropriado do <filename>rc.d</filename>.
If you would like to learn the details of why <filename>rc.d</filename> scripts must be written in the <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> language, see how <filename>/etc/rc</filename> invokes them by means of <function>run_rc_script</function>, then study the implementation of <function>run_rc_script</function> in <filename>/etc/rc.subr</filename>. Caso você queira aprender os detalhes do porque os scripts <filename>rc.d</filename> devem ser escritos na linguagem <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry>, veja como o <filename>/etc/rc</filename> invoca-os por meio de <function>run_rc_script</function>, e então estude a implementação de <function>run_rc_script</function> em <filename>/etc/rc. subr</filename>.
In <filename>/etc/rc.subr</filename>, a number of <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> functions are defined for an <filename>rc.d</filename> script to use. The functions are documented in <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry>. While it is theoretically possible to write an <filename>rc.d</filename> script without ever using <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry>, its functions prove extremely handy and make the job an order of magnitude easier. So it is no surprise that everybody resorts to <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry> in <filename>rc.d</filename> scripts. We are not going to be an exception. Em <filename>/etc/rc.subr</filename>, várias funções <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> estão definidas para serem utilizadas por um script <filename>rc.d</filename>. As funções estão documentadas em <citerefentry><refentrytitle>rc.subr</refentrytitle> <manvolnum>8</manvolnum></citerefentry>. Embora seja teoricamente possível escrever um script <filename>rc.d</filename> sem usar o <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry>, 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 <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry> em <filename>rc.d</filename>. Nós não vamos ser uma exceção.
An <filename>rc.d</filename> script must <quote>source</quote> <filename>/etc/rc.subr</filename> (include it using <quote><command>.</command></quote>) <emphasis>before</emphasis> it calls <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry> functions so that <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> has an opportunity to learn the functions. The preferred style is to source <filename>/etc/rc.subr</filename> first of all. Um script <filename>rc.d</filename> deve <quote>incluir</quote> o <filename>/etc/rc.subr</filename> (isto por ser feito usando o comando <quote><command>.</command></quote>) <emphasis>antes</emphasis> que ele chame as funções do <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry> para que o <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum> </citerefentry> tenha a oportunidade para aprender as funções. O estilo preferido é incluir o <filename>/etc/rc.subr</filename> antes de tudo.
Some useful functions related to networking are provided by another include file, <filename>/etc/network.subr</filename>. Algumas funções úteis relacionadas a rede são fornecidas por outro arquivo include, o <filename>/etc/network.subr</filename>.
<anchor xml:id="name-var"/>The mandatory variable <envar>name</envar> specifies the name of our script. It is required by <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry>. That is, each <filename>rc.d</filename> script <emphasis>must</emphasis> set <envar>name</envar> before it calls <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry> functions. <anchor xml:id="name-var"/>A variável obrigatória <envar>name</envar> especifica o nome do nosso script. Ela é exigida pelo <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry>. Ou seja, cada script <filename>rc.d</filename> <emphasis>deve</emphasis> definir a variável <envar>name</envar> antes de chamar funções do <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
Now it is the right time to choose a unique name for our script once and for all. We will use it in a number of places while developing the script. For a start, let us give the same name to the script file, too. 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.
The current style of <filename>rc.d</filename> scripting is to enclose values assigned to variables in double quotes. Keep in mind that it is just a style issue that may not always be applicable. You can safely omit quotes from around simple words without <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> metacharacters in them, while in certain cases you will need single quotes to prevent any interpretation of the value by <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry>. A programmer should be able to tell the language syntax from style conventions and use both of them wisely. O estilo atual do script <filename>rc.d</filename> é 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 <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> nelas, enquanto em certos casos você precisará de aspas simples para evitar qualquer interpretação do valor pelo <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry>. 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.
The main idea behind <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry> is that an <filename>rc.d</filename> script provides handlers, or methods, for <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry> to invoke. In particular, <option>start</option>, <option>stop</option>, and other arguments to an <filename>rc.d</filename> script are handled this way. A method is a <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> expression stored in a variable named <envar><replaceable>argument</replaceable>_cmd</envar>, where <replaceable>argument</replaceable> corresponds to what can be specified on the script's command line. We will see later how <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry> provides default methods for the standard arguments. A idéia principal por trás do <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry> é que um script <filename>rc.d</filename> fornece manipuladores, ou métodos, para o <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry> invocar. Em particular, <option>start</option>, <option>stop</option> e outros argumentos para um script <filename>rc.d</filename> são tratados desta maneira. Um método é uma expressão <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum> </citerefentry> armazenada em uma variável denominada <envar><replaceable>argument</replaceable>_cmd</envar>, no qual <replaceable>argument</replaceable> corresponde ao que pode ser especificado na linha de comando do script. Vamos ver mais adiante como o <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry> fornece métodos default para os argumentos padrão.
To make the code in <filename>rc.d</filename> more uniform, it is common to use <envar>${name}</envar> wherever appropriate. Thus a number of lines can be just copied from one script to another. Para tornar o código em <filename>rc.d</filename> mais uniforme, é comum usar <envar>${name}</envar> onde for apropriado. Assim, várias linhas podem ser copiadas de um script para outro.
We should keep in mind that <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry> provides default methods for the standard arguments. Consequently, we must override a standard method with a no-op <citerefentry><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry> expression if we want it to do nothing. Devemos ter em mente que o <citerefentry> <refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry> fornece métodos default para os argumentos padrões. Consequentemente, devemos sobrescrever um método default com uma expressão no-op <citerefentry><refentrytitle>sh</refentrytitle><manvolnum></manvolnum></citerefentry> se desejarmos que ele não faça nada.
The body of a sophisticated method can be implemented as a function. It is a good idea to make the function name meaningful. O corpo de um método sofisticado pode ser implementado como uma função. É uma boa ideia tornar o nome da função significativo.
It is strongly recommended to add the prefix <envar>${name}</envar> to the names of all functions defined in our script so they never clash with the functions from <citerefentry><refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry> or another common include file. É altamente recomendado adicionar o prefixo <envar>${name}</envar> aos nomes de todas as funções definidas em nosso script, para que eles nunca entrem em conflito com as funções do <citerefentry> <refentrytitle>rc.subr</refentrytitle><manvolnum>8</manvolnum></citerefentry> ou outro arquivo de inclusão comum.

Loading…

New source string a year ago
Browse all component changes

Glossary

English Portuguese (Brazil)
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect1/para
Source string location
article.translate.xml:219
String age
a year ago
Source string age
a year ago
Translation file
articles/pt_BR/rc-scripting.po, string 29