Primeiras aulas do curso Certificação Linux LPI Essentials parte 8: Turning Commands into a Script

Certificação Linux LPI Essentials parte 8: Turning Commands into a Script

Criação de um script simples - O básico sobre scripts e o shebang

Nesta seção da prova vamos falar sobre como vamos parar de executar comandos soltos e passar a criar scripts, que são uma sequência de comandos para serem executadas em uma sequência determinada. Não necessariamente uma coisa e outra, podemos colocar loops, laços, podemos colocar condicionais, como ifs. Vamos ver tudo isso aqui nessa seção da prova.

A primeira coisa que ele quer cobrar para nós é como podemos transformar comandos repetitivos em scripts simples. Isso é, tenho um conjunto de comandos que executo diversas vezes e não quero ter que ficar executando esses comandos toda vez. Queria que ele já executasse isso para mim, essa sequência desses comandos se eu desse só um nome mais simples para esse comando, para essa sequência de comandos.

Queremos criar um script que junta diversos passos ou um único passo mais complexo que quero executar. Vamos lá. A primeira coisa é ir no Ubuntu, logando na minha máquina. Estou no terminal, já fizemos diversas coisas nesse terminal, entre elas se eu der uma olhada no meu histórico "Ctrl + R", vou olhar que já fiz um find em que procurei todos os arquivos que tinham a palavra log e que tinham a palavra 2016.

O que eu fazia com eles? Eu “zipava” esse cara. Eu “zipava” ele e por fim rodava um wc para saber quantos foram compactados. Se eu quisesse saber só exatamente quantos foram compactados coloco um -l para saber só o número de linhas que foi na minha saída, no meu zip, isso é, quantos foram compactados.

Vou tentar executar esse cara, executo no meu diretório atual, ele fala que compactou seis arquivos. Funcionou. Agora, não queria toda vez ter que digitar essa linha inteira, até porque está no meu histórico, se eu limpar meu histórico me dou mal. Lembra do bash history? Tenho um arquivo aqui que é meu bash_history que no padrão do Ubuntu armazena todos os comandos que executei.

Então quer dizer que vou ficar executando esse cara se de repente esse meu history limpa, acaba, estoura o limite dele, ele limpa, decide começar de novo, alguma coisa do gênero, não tenho mais essa informação. O que faço? Dou copy paste em um arquivo txt e compartilho com todos os meus amigos esse comando?

Não, o que vou fazer? Vou criar outro comando, um script que vai falar quando você chamar esse script, na verdade quero que você chame todos esses comandos. Já vimos um pouco isso quando trabalhamos com os arquivos mostra idade, o sucesso, o help e o falha, todos esses arquivos foram scripts que nós criamos. Vamos criar um novo script, um script que rode esse comando que procura tudo que tem log e 2016, zipa e me mostra o número de arquivos que foram zipados.

Esse é o script que eu gostaria de criar. Vamos criar ele. Vou criar um abrir editor, um gedit, vou criar o nome desse meu script, esse meu script vai se chamar compacta-logs.sh, sh de shell, é um padrão necessário? Não é um padrão necessário. Mas você vai encontrar isso várias vezes, para sinalizar para quem está vendo esse arquivo que esse cara é um script do shell.

Repare que nós criamos nossos scripts sem extensão sh, não é obrigado a extensão com sh, até porque como já vimos .sh, .exe, .bat, .txt, .gif, tudo isso na verdade é só uma dica para um programa do que é o conteúdo que tem ali dentro. No Linux não é necessariamente a extensão, existe uma estrutura chamada extensão, já falamos isso, sobre a estrutura de arquivos no Linux.

Mas a extensão, esse pedaço do nome do arquivo ponto alguma coisa indica para nós o que esse cara deve ser. Deve ser um script do shell. Vou editar esse cara, compacta logs. O que vou colocar aqui? O comando do nosso find. Olha, find tudo neste diretório atual que tenha o nome *log*, então a partir do diretório atual, intra recursivo, tudo que tenha log no nome, e que tenha também a palavra 2016 no nome.

Para mim está ótimo, esse é o find que quero executar. Pega esses caras todos e zipa para mim -@ para pegar do input, na entrada padrão, que é a saída do nosso zip, pega da entrada padrão e roda um zip “zipando” um arquivo chamado logs.zip.

No final roda um wc para mostrar para mim o número de linhas, isso é, o número de arquivos que foram compactados. Ele está fazendo isso para nós. No final, posso colocar salvar esse cara, "Ctrl + S" para salvar ele, fechei meu arquivo. Dou um ls, tenho meu arquivo compacta-logs.sh, maravilha.

Se quero executar esse arquivo já vimos antes. Tenho que falar, por exemplo, bash compacta-logs.sh, ele roda e mostra para nós a saída. Já vimos que se queremos executar um script vamos falar para o nosso shell ou para um shell qualquer que tenha instalado, se tivesse outro shell aqui eu ia falar outro shell, por exemplo, shell sh, se tenho shell sh instalado, um shell básico, posso falar para ele compacta-logs.sh, e ele executa com esse interpretador aqui.

Se eu tivesse um cshell ou um outro shell, poderia colocar aqui o nome do meu shell e executo o meu script.sh, ele vai executar com aquele shell. Lembra que aqui no Ubuntu estamos usando obash, então estamos usando obash, estou digitando bash compacta-logs.sh.

Só que o que acontece? Na prática parece razoavelmente código demais ficarmos falando bash explicitamente compacta-logs.sh. Tem esse problema primeiro. Tem um segundo problema. Se estou usando um shell do bash comandos que estão baseados nobash, isto é, os comandos que estou executando aqui dentro estão baseados nobash, a linguagem que estou usando aqui dentro é dobash, eu poderia não querer que o “colocar” executasse com outro shell, com cshell. Não quero que você execute com cshell, porque o código que está aqui não é compatível com cshell.

Ou, por exemplo, eu escrevi um shell meu mesmo, escrevi um script meu compatível com cshell, e não com o bash, então eu queria falar que é para executar com o cshell e não com esse.

Repare que tem alguns perigos de termos que falar explicitamente toda vez que vamos encontrar, invocar um script, temos que falar o nome do interpretador desse script, o nome do programa de shell que interpreta esse script. É arriscado.

Uma outra alternativa é falarmos que esse cara tem permissão de execução. Vou falar que esse cara tem permissão de execução. Já vimos isso, é o chmod +x compacta-logs.sh, adicionar permissão de execução a esse arquivo.

Quando damos ls, com color, que é o padrão do alias do Ubuntu, ele mostra que ele é executável. Quando passa a ser executável podemos invocar ele de outras maneiras. Já vimos isso também. Podemos chamar absolutamente, /home/Guilherme/compacta-logs.sh ou chamar ele relativo ao diretório atual, isso é ./compacta-logs.sh, também executa.

Por mais que funcione executar um script da maneira que estou fazendo aqui no meubash, acabei de falar um problema, que se estou executando dessa maneira ele está usando meu bash atual, da maneira atual, e azar se eu estivesse usando um bash errado, um shell errado.

Qual o risco de fazer só isso que fiz? Se eu estivesse usando um shell errado, estou usando cshell e quero agora executar um programa que é compatível combash, ou estou usando bash e quero executar um programa agora que deve ser interpretado pelo cshell, e agora? Como vou fazer isso?

Tudo bem, parei de escrever a palavra bash aqui, mas por padrão ele vai usar meu shell atual, porque tenho que interpretar esse cara, vou usar o shell atual. O que temos que fazer? Temos que pegar esse nosso arquivo compacta-logs.sh, e para isso vou abrir nosso editor separadamente, para podermos editar ele ao mesmo tempo.

Vou abrir nosso arquivo, quando eu salvar agora ele vai salvar um arquivo de backup, o gedit faz isso para nós com um til no final. Repare que ele tem o comando que quero executar, mas eu gostaria de falar, por favor, ao executar esse script use para mim o /bin/bash, quero que você use o /bin/bash para mim, quero que você use o shell bash que está instalado no /bin/bash.

O que falo aqui para ele? Para falar que é exatamente isso que estou falando para você, usamos dois caracteres. O caractere de comentário, ficou colorido porque é um comentário do meu arquivo. Não é para ser interpretado como um comando, por exemplo, ls. É só um comentário. Só estou descrevendo o que vai acontecer aqui.

Procura os arquivos com log e 2016 compactando em logs.zip, estou descrevendo o que meu programa faz. Cerquilha é só um comentário. Só que aqui são dois caracteres que falei para vocês. Cerquilha e exclamação.

A primeira linha de um script é especial, principalmente se ela tiver cerquilha e exclamação. Deram até um nome para essa combinação desses dois caracteres. Eles chamam de shebangs. Se te perguntarem o que é o shebangs, é esse cara, esses dois símbolos.

Nós usamos esses dois símbolos e aí quem é o shell que vai interpretar esse nosso script? Na verdade, quem é o programa que vai interpretar esse nosso script. Não precisa ser obash, pode ser qualquer outro programa que vai interpretar esse nosso script. Ele vai ser invocado com esse conteúdo para ser executado.

Repare que esses dois caracteres são especiais, sempre cerquilha e exclamação. E com isso também vimos um comentário aqui, como funciona cerquilha para comentar, vou salvar e executar de novo.

Executei. Não teve muita diferença. O resultado foi o mesmo. Porque ele usou o bash para mostrar nosso resultado e acabou, não teve muita graça. Vou limpar a tela e executar de novo. Vamos abrir nosso gedit de novo. O que quero falar é que gostaria de executar obash, mas vamos fazer um teste. Vamos ver se ele está executando mesmo esse nosso bash com esse comando.

Vou colocar uma opção dobash, a opção de verbose, nós já vimos o verbose em outros programas, que fala o que está acontecendo para nós. O verbose costuma dizer isso. Fala o que está acontecendo. E o -v costuma ser o padrão do verbose. Cuidado que alguns programas não usam o -v para verbose.

Vou salvar, no caso do bash é -v. Vou executar de novo e olha a diferença. O que ele mostrou para nós agora? Cada linha que estava sendo interpretada, inclusive a linha em branco, e ele mostrou que essa linha também foi interpretada, é um comentário, não fiz nada. Essa linha foi executada. O resultado foi 6. O -v do verbose no bash mostra todas as linhas sendo executadas.

Repare que agora sim mostrei para vocês que de verdade, isso é verdade, não era mentira. Quando colocávamos um comando, o que ele vai fazer? Vai executar esse comando, interpretando esse nosso arquivo. Nosso arquivo inteiro.

Foi isso que ele fez, interpretou nosso arquivo inteiro, ficou feliz e contente com o /bin/bash, temos diversas maneiras de executar um script nosso. Vimos que podemos simplesmente falar o nome do interpretador, por exemplo,bash, e o nome do script, funciona.

Ou posso dar permissão de execução, chmod +x, e pedir para executar esse script, através do path absoluto, ou através do path relativo, com ./ e o nome do arquivo no diretório atual, ou relativo, literalmente, nome de um diretório, nome de outro e nome de um arquivo, ou colocar no path.

Já vimos a questão do path, posso colocar na variável de ambiente path, o diretório onde está esse meu script, e executo ele feliz e contente. Posso executar, não tem problema nenhum, ele vai funcionar para mim.

É até bem comum o pessoal fazer o seguinte padrão, as pessoas criarem um diretório, algo como bin, pegar e mover esse meu compacta-logs para o diretório bin, repara que no diretório bin o que tenho agora? O compacta-logs e o backup dele que o gedit fica criando para nós.

O que vou fazer agora? Vou colocar esse diretório atual no path. Vou voltar para o diretório anterior, vou falar que path é igual ao path atual e /home/guilherme/bin. Se eu chamar agora simplesmente compacta-logs.sh ele busca do nosso diretório aquele programa e executa. Em que diretório? No diretório atual.

Extremamente importante. Cuidado. Estou executando o compacta-logs em que diretório? No diretório /home/Guilherme, não estou executando o compacta-logs no diretório /home/Guilherme/bin, vamos provar isso para você. Vamos lá no diretório bin, vou editar nosso compacta-logs, vou tirar o -v que já mostrei para vocês que ele realmente é interpretado, e o que vou fazer é simplesmente um pwd. Para mostrar o diretório atual.

Salvei, fechei. Vou sair do diretório atual, e ele fala que estou no diretório /home/Guilherme. Repara então que independente de onde está o programa que está no path, são encontrou no path ele vai executar, mas ele executa no diretório atual.

Essa é a maneira de executar um script. As diversas maneiras de executar um script, e vimos que até quando colocamos nosso script na primeira linha temos dois caracteres especiais, cerquilha e exclamação, que é o shebangs. Esse shebangs posso dizer quem é o programa que vai interpretar o meu arquivo. Muito comum de utilizarmos o shebangs /bin/bash, porque é muito comum que escrevamos scripts compatíveis com o bash. Vamos falar bem mais sobre scripts daqui a pouco.

Criação de um script simples - Redirecionando a saída padrão com a crase

Nós colocamos o nosso compacta-logs no diretório /home/Guilherme/bin. E esse diretório está no path do meu environment atual, porque “setamos” nosso path. Ele faz um pwd, compacta e mostra o número de arquivos compactados.

Eu usei o pwd para deixar claro para nós que estou compactando os arquivos que foram encontrados dentro desse diretório. Só que não está muito claro isso nos dois casos, está bem bagunçado, na verdade. Vamos mudar um pouco. Vou editar o meu arquivo, vou abrir meu editor de texto, e vou abrir nosso arquivo que está no diretório bin compacta-logs.

compacta-logs roda o pwd, o que eu queria fazer é antes mostrar a mensagem compactando os logs de 2016 em e o nome do diretório. Salvei, rodei. ‘Compactando os logs de 2016 em /home/Guilherme 6’, feio demais, está bem feio.

Não está nem na mesma linha. Que nojo. Se formos no man echo ele até tem uma opção de não colocar a linha, -n, vamos lá então. Vou editar meu colega, vou colocar um -n no começo, salvei. Vou diminuir meu terminal um pouco só para ficar mais fácil de trabalhar com os dois.

Fica mais fácil de ficar selecionando. Vou executar de novo, compactando os logs de 2016 em ‘/home/Guilherme’. Mas mesmo assim fica meio bizarro. Às vezes queremos escrever esse pwd, mas podia executar ele só aqui, não queria usar para mais nada. Queria deixar claro que ele só está sendo usado aqui, e mais nenhum outro lugar.

Repara que quando executamos um comando, por exemplo, echo e mais um monte de coisa, passamos alguns parâmetros para o echo, para o programa. Posso mandar várias coisas. Por exemplo, posso escrever *echo* Meu diretório atual é, enter, mostrou uma mensagem.

Se eu quiser executar um comando, pegar a saída desse comando e passar como argumento para esse programa aqui, como posso fazer isso? Legal, é só rodar um pdw, pegar a saída dele e redirecionar como entrada padrão para o echo. Quase.

Eu tinha falado que eu queria passar como entrada padrão? Não, porque o echo não faz nada com a entrada padrão. O que eu queria era pegar o resultado do pdw e passar como argumento para o echo. O pipe pega a saída padrão de um e seta como entrada padrão do outro.

Não tem problema. No caso do nosso zip é isso que queríamos fazer. O zip lê da entrada padrão. O echo não. O echo lê os argumentos que você passar. Eu queria executar aquele meu echo de sempre. E aqui eu queria executar o comando pwd. Não funciona, obviamente, porque pwd é uma palavra.

Não estou nem aí para isso. O que posso fazer é falar que meu diretório atual é, e aí aqui posso executar o programa pwd. Vou executar o programa pwd. Vou colocar a crase. A crase, não aspas simples.

Quando passo no bash como parâmetro como programa, ou como passo no bash crase e alguma coisa, não necessariamente um parâmetro, mas qualquer coisa, tenho aqui que passo crase e o nome. O nome que está aqui dentro é um programa que vai ser executado. Ele vai tentar executar o pwd. Vai pegar o resultado do pwd e colocar nessa posição do meu comando.

Vamos testar? Meu diretório atual é /home/Guilherme. Repare que em qualquer lugar posso fazer isso. Por exemplo, eu poderia criar DIRETORIO_ATUAL, uma variável, que tem o resultado da saída do comando pwd. A saída do comando pwd vai ser armazenada na variável de shell chamada DIRETORIO_ATUAL, vamos ver.

Rodei, echo $DIRETORIO_ATUAL, está lá a saída dele. Que mais? Poderia simplesmente executar o comando pwd. Estou executando o comando pwd que vai ser /home/Guilherme. Lembra o que o bash vai fazer? O bash vai pegar isso e vai substituir nessa linha.

Ele vai tentar executar o /home/Guilherme, não faz muito sentido. E ele fala que não faz sentido executar o /home/Guilherme, repare que a aspas simples realmente é pega o resultado desse comando e coloca no lugar dessa aspas simples. Se eu fizer para você, por exemplo, echo pwd, o que estou fazendo aqui? Estou executando o comando echo pwd, qual a saída do comando? Pwd.

E aí executo o comando pwd. Vamos ver. /home/Guilherme. Repare então que a crase pode ser usada em qualquer lugar do comando do meu bash para dizer, executa esse programa, o resultado de saída dele, a saída padrão dele vai ser substituído aqui no que estou falando.

Você lembra do nosso find, por exemplo? Tínhamos o nosso find, find tudo isso. Tínhamos todo esse find. Posso fazer alguma coisa com esse find? Posso fazer o que eu quiser. Posso executar ele, dar um “Ctrl + C”, vou tentar colocar meu find. Executei meu find. Ele deu a saída.

Posso colocar o resultado disso numa variável? Posso, ENCONTRADOS= isso aqui. Não funcionou, porque tenho que falar que ENCONTRADOS é a saída, então crase simples, executo o comando find, a saída padrão dele joga nessa variável, echo $ENCONTRADOS, está lá o resultado, sempre com o espaço.

Usamos a crase para interpretar um comando, utilizar a saída padrão desse comando para fazer alguma coisa, o que quisermos. No nosso caso, vou querer simplesmente colocar aqui em pwd. Executo esse cara, e ele mostrou compactando os logs de 2016 em ‘/home/guilherme6’.

Vamos tirar o -n que não preciso mais. Ele vai executar só compactando os logs de 2016 em ‘/home/Guilherme’. Note que o echo mesmo tendo coat interpretou nossa crase, mesmo dentro do coat, ele interpreta a crase.

Variáveis e argumentos - Variáveis e o source

Já vimos então o shebang, que é o cerquilha exclamação, eu tenho mania de falar shebangs, no plural, o “/bin/bash”, que acabamos usando como um interpretador para os nossos scripts que estão na linguagem do bash, e vamos falar sobre outras variações que queremos trabalhar.

Vamos voltar no meu terminal, quero falar um pouco sobre as variáveis. Já vimos um pouco sobre o uso de variáveis, já vimos que podemos utilizar variáveis aqui dentro, podemos usar essas variáveis que quisermos aqui dentro, eu poderia ler, por exemplo, uma variável qualquer que vai ser definida, posso ler dentro do meu script. Por exemplo, posso falar que quero que o ano seja uma variável.

Eu vou falar que ANO=2016 e gostaria que quando eu rodasse meu script ele lesse para nós a variável ano. Como fazemos isso? Já sabemos, ${ANO}, estou colocando dentro das chaves para deixar bem claro, já falamos sobre script e variáveis de shell, usando resultado da variável ano, deixando claro que é só um comentário.

Salvei, vamos tentar executar? Tentar. Vou tentar executar o script. Tento e ele fala “compactando os logs de vazio”, porque esqueci de exportar a variável. Se eu vou usar uma variável dentro de um script, quando invoco esse script tenho que exportar essa variável. Vou dar um export nessa variável. E chamo de novo.

Compactando os logs de 2016 em /home/Guilherme. Um cuidado, já falamos bastante sobre variável antes para estudar algumas coisas do bash, só que nós não falamos sobre se eu pegar uma variável e querer alterar o resultado dela. Por exemplo, o ano é 2016, agora o que quero fazer é mudar esse ano para 2017. Salvei e vou testar de novo.

Rodo o compacta-logs.sh, ele mostra para mim que era 2016, agora deve ser 2017, não, ainda é 2016. Por quê? Porque meu shell atual é um processo, nele a variável ano vale 2016 e essa variável está configurada para ser exportada. Esse nosso shell chama um outro filho, um outro processo, filho dele. Nesse processo as variáveis que foram exportadas foram copiadas para cá, todas elas foram copiadas.

Foi executado aqui dentro esse filho com 2017 e morreu, acabou, sumiu, já era, o cara original, onde ele voltou, é nosso processo original, temos os valores originais da variável, então ano continua valendo 2016. Para mudar essa nossa variável o que vou falar é ao invés de executar bash e o nome do programa, como estávamos fazendo, ou executar diretamente, vamos rodar outro programa.

Vamos rodar um cara chamado source. O source executa um comando no shell atual, executa os comandos no shell atual. Atual. Isso é, não é que ele vai startar um shell filho, executar, destruir o shell filho e as variáveis estão limpas. Não, ele vai executar no shell atual. No meu shell atual ele vai executar o cara. Vamos ver o resultado.

Então, source compacta-logs.sh, mandei ele executar como source o compacta-logs.sh, isso é, executa no meu shell atual, não é para startar um shell filho. Executa, ele está compactando os logs de 2016, echo, o ano agora é 2017, porque source pede para executar no meu shell atual. E não no shell filho, que daqui a pouco vai morrer.

Extremamente importante o source no meu dia a dia, porque se estou executando um script de configuração das variáveis de ambiente, vamos usar o source, mas repare que ele é exceção à regra, a regra geral é você quer executar um programa, um script? Ele é filho. A regra geral é essa, porque não queremos executar um programa e ele bagunça todas as minhas variáveis. Executa outra e ele bagunça de novo todas as variáveis.

Queremos ter um ambiente seguro, um ambiente que as mudanças que foram feitas fui eu quem fiz, foi o Guilherme. Então por padrão, quando executamos com o shell estamos falando “executa em um filho”, em um ambiente isolado, depois volta para esse processo.

Quando falamos com source estamos falando execute aqui mesmo. E repare que com o source não precisou estar no mesmo diretório do arquivo. Meu arquivo de script não precisava estar no mesmo diretório. Poderia executar source /home/Guilherme/bin/compacta-logs.sh? Posso executar assim também.

Agora, cuidado, estou executando esse cara no meu diretório atual, meu diretório atual continuou sendo “/home/Guilherme”, e agora a variável ano já valia 2017, porque já tínhamos dado source.

Outra maneira de chamar o source é o . compacta-logs.sh, essa é outra maneira, um atalho para o source, é só escrever ponto e espaço. Vou mudar para 2018 agora. Salvei e executei. Damos um echo no ano, 2018.

Repare que se usarmos source espaço ou ponto espaço, o nome de um script vai executar esse nosso script no shell atual, então as variáveis de ambiente que você mudar, as variáveis de shell que você mudar serão afetadas no shell atual.

Vamos mudar, vamos falar bash -v, já testamos. Vamos ver. Salvei, vou tentar de novo no compacta-logs.sh, repare que ele ignorou o -v, porque ele não startou um bash filho, um shell filho, ele executou no shell atual. Ele ignorou essa primeira linha, ele ignorou, é um comentário, ele ignorou completamente. Reparou na diferença do ponto e do source?

O ponto e o source falam para executar no shell atual. Se eu executo normalmente, sem o ponto e sem o source, ele executa em um shell filho. No shell filho as mudanças não são refletidas no shell atual. É extremamente importante para a saída os resultados de alteração das minhas variáveis de ambiente.

Aí você fala, poxa, Guilherme, então basicamente sempre vou querer usar o source, assim não preciso me preocupar. É uma maneira de ver as coisas. Em linguagem de programação temos bastante essa discussão. Eu deveria usar uma linguagem que permite alterar o valor das variáveis, ou as variáveis são escritas uma vez e depois nunca mais alteram? Sempre temos essa discussão.

Repare que o bash e o shell por padrão estão falando que por padrão essas variáveis só podem ser alteradas por você. Os seus scripts só vão alterar uma cópia das suas variáveis que você configurou como exportáveis. E quando esse script filho parar de executar esse ambiente atual continua limpo como estava antes. O ambiente atual continua limpo o tempo inteiro, o filho é o filho.

Quando falamos com source ou com ponto não, não iniciamos um processo filho, executamos no processo atual. Com isso vimos a importante do source do ponto para execução de alguns scripts. Com isso falamos um pouco mais sobre variáveis em relação a scripts.

Já tínhamos visto bastante de variáveis e scripts porque definimos o escopo de variáveis de shell e variáveis de ambiente. Agora falamos porque queríamos usar o source, falar que quero que a variável sobreviva, isso é, quero executar meu script no shell atual, mas ainda falta falar sobre diversas outras características de um script, e vamos falar sobre tudo isso.

Sobre o curso Certificação Linux LPI Essentials parte 8: Turning Commands into a Script

O curso Certificação Linux LPI Essentials parte 8: Turning Commands into a Script possui 84 minutos de vídeos, em um total de 23 atividades. Gostou? Conheça nossos outros cursos de Linux em DevOps, ou leia nossos artigos de DevOps.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

Aprenda Linux acessando integralmente esse e outros cursos, comece hoje!

Plus

  • Acesso a TODOS os cursos da plataforma

    Mais de 1200 cursos completamente atualizados, com novos lançamentos todas as semanas, em Programação, Front-end, UX & Design, Data Science, Mobile, DevOps e Inovação & Gestão.

  • Alura Challenges

    Desafios temáticos para você turbinar seu portfólio. Você aprende na prática, com exercícios e projetos que simulam o dia a dia profissional.

  • Alura Cases

    Webséries exclusivas com discussões avançadas sobre arquitetura de sistemas com profissionais de grandes corporações e startups.

  • Certificado

    Emitimos certificados para atestar que você finalizou nossos cursos e formações.

  • Alura Língua (incluindo curso Inglês para Devs)

    Estude a língua inglesa com um curso 100% focado em tecnologia e expanda seus horizontes profissionais.

12X
R$85
à vista R$1.020
Matricule-se

Pro

  • Acesso a TODOS os cursos da plataforma

    Mais de 1200 cursos completamente atualizados, com novos lançamentos todas as semanas, em Programação, Front-end, UX & Design, Data Science, Mobile, DevOps e Inovação & Gestão.

  • Alura Challenges

    Desafios temáticos para você turbinar seu portfólio. Você aprende na prática, com exercícios e projetos que simulam o dia a dia profissional.

  • Alura Cases

    Webséries exclusivas com discussões avançadas sobre arquitetura de sistemas com profissionais de grandes corporações e startups.

  • Certificado

    Emitimos certificados para atestar que você finalizou nossos cursos e formações.

  • Alura Língua (incluindo curso Inglês para Devs)

    Estude a língua inglesa com um curso 100% focado em tecnologia e expanda seus horizontes profissionais.

12X
R$120
à vista R$1.440
Matricule-se
Conheça os Planos para Empresas

Acesso completo
durante 1 ano

Estude 24h/dia
onde e quando quiser

Novos cursos
todas as semanas