Translate

Mostrar mensagens com a etiqueta bash. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta bash. Mostrar todas as mensagens

quarta-feira, 28 de janeiro de 2026

💥 Git no z/OS: O Casamento IMPROVÁVEL que Virou Revolução DevOps no Mainframe

 

Bellacosa Mainframe apresenta o GIT para padawans em Mainframe

💥 Git no z/OS: O Casamento IMPROVÁVEL que Virou Revolução DevOps no Mainframe


🧠 Contexto: Antes era “impossível”… hoje é padrão

Em 2018, falar de git rodando dentro do z/OS era quase heresia.

  • Não existia Z Open Automation Utilities
  • Open Source no mainframe? Ainda engatinhando
  • DevOps? Só no mundo distribuído

Hoje… 👇
👉 Temos comunidade ativa
👉 Bash rodando no USS
👉 Ferramentas open source integradas
👉 E sim… git funcionando NATIVAMENTE no z/OS

💣 Traduzindo: o mainframe deixou de ser isolado e entrou no jogo moderno.


🔗 Parte 1 — Conectando z/OS ao GitHub (SSH)

Aqui começa a mágica.

🧩 Problema clássico

z/OS “raiz” muitas vezes não tem DNS configurado.

🔧 Solução (tradução + comentário)

vi /etc/resolv.conf

Adicione:

nameserver 8.8.8.8

💡 Comentário Bellacosa:
Isso aqui parece simples, mas é o que separa você de:

❌ “Host desconhecido”
✔️ Integração com o mundo externo


🔄 Restart do resolver

opercmd "stop resolver"
opercmd "start resolver"

💥 Aqui entra realidade de mainframe:

  • Precisa permissão
  • Ou chama o sysprog amigo 😎

🔍 Teste de DNS

host github.com

Se vier IP → 🎯 sucesso


🔐 Parte 2 — Criando chave SSH (segurança de verdade)

ssh-keygen -t rsa -b 4096 -C "seu-email"

👉 Isso gera:

  • chave privada (fica no z/OS)
  • chave pública (vai pro GitHub)

🚀 Ativando agente SSH

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_rsa

📋 Copiando chave pública

vi ~/.ssh/id_rsa.pub

Cola no GitHub:

  • Settings
  • SSH Keys
  • New Key

💡 Insight Bellacosa:
Isso elimina senha.
Você entra no mundo:

👉 autenticação forte
👉 automação
👉 pipelines DevOps reais


🧰 Parte 3 — Instalando Git no z/OS

Aqui é onde muita gente trava.

📦 Solução moderna:

zopen install -y git

🔥 Isso instala:

  • git
  • dependências
  • bash (ESSENCIAL!)

💡 Tradução prática:
Você acabou de transformar seu z/OS em um mini Linux dentro do USS.


🧪 Testando conexão com GitHub

ssh git@github.com

Saída esperada:

You've successfully authenticated, but GitHub does not provide shell access.

💣 Isso aqui é perfeito.
Significa:

👉 conexão OK
👉 autenticação OK
👉 pronto pra usar git


⚙️ Parte 4 — Configuração do ambiente

Edite o profile:

vi ~/.profile

Adicione:

git config --global user.name "Seu Nome"
git config --global user.email "seu-email"
git config --global init.defaultBranch main
bash

💡 Insight poderoso:

👉 O bash aqui muda o jogo
👉 Você sai do shell limitado e entra num ambiente moderno


🔄 Reinicie sessão e valide

ps

Se aparecer:

bash

🎯 Missão cumprida


📂 Parte 5 — Clonando repositório

git clone git@github.com:usuario/repositorio.git
cd repositorio

💡 Aqui começa o DevOps REAL no mainframe.


🌿 Trabalhando com branch (fluxo moderno)

Criar branch

git checkout -b WordPressChange

Adicionar alteração

git add setenv.sh

Validar

git status

Commit

git commit

Enviar pro GitHub

git push origin WordPressChange

💥 TRADUÇÃO BELLACOSA:

Você acabou de fazer isso no z/OS:

👉 versionamento moderno
👉 branch strategy
👉 integração com GitHub
👉 colaboração distribuída

🔥 ISSO É DEVOPS NO MAINFRAME


🧠 Camada EXTRA — O que ninguém te conta

💣 1. USS é o segredo

Sem USS (Unix System Services), isso aqui não existiria.


💣 2. Git não entende dataset nativo

Você está trabalhando com:

👉 arquivos USS
👉 não diretamente com PDS/VSAM


💣 3. Ponte com COBOL

Fluxo real:

  1. Código COBOL no USS
  2. Versionado com git
  3. Deploy → dataset
  4. Compilação via JCL

🔥 Isso conecta dois mundos.


💣 4. Open Source salvando o mainframe

Sem a comunidade:

👉 nada disso existiria
👉 IBM acelerou depois


🧪 Exemplo real (mentalidade enterprise)

Imagine:

  • Squad distribuído
  • Dev Java + Dev COBOL
  • Pipeline CI/CD

👉 GitHub → z/OS → compile → deploy → CICS

🔥 Isso já é realidade hoje


🏁 Conclusão estilo Bellacosa

💥 O que antes era “mainframe isolado” virou:

👉 plataforma integrada
👉 DevOps-ready
👉 open source friendly

E o git?

👉 virou a ponte entre gerações de tecnologia


☕ Frase pra fechar no estilo raiz:

“O mainframe não ficou ultrapassado…
você que ainda não viu ele rodando com git.” 😎🔥

 

sexta-feira, 23 de fevereiro de 2018

IBM JCL vs Shell Script

 


☕ Um Café no Bellacosa Mainframe

IBM JCL vs Shell Script

O Que Todo Programador COBOL Padawan Precisa Saber Sobre as Semelhanças e Diferenças Entre a Linguagem de Controle do Mainframe e a Automação do Mundo Linux

"Você não está aprendendo duas tecnologias diferentes. Está descobrindo duas filosofias de automação que nasceram em épocas distintas para resolver exatamente o mesmo problema: fazer o computador trabalhar sozinho."


Introdução

Existe uma frase muito comum entre profissionais que estão migrando do IBM Mainframe para Linux:

"Shell Script é o JCL do Linux."

Embora essa frase seja extremamente útil para explicar rapidamente o conceito, ela não é totalmente correta.

Na realidade, JCL e Shell Script possuem objetivos semelhantes, mas nasceram em épocas diferentes, foram projetados para sistemas operacionais completamente distintos e seguem filosofias arquitetônicas bastante diferentes.

Se você é um Programador COBOL Padawan, provavelmente domina conceitos como:

  • JOB

  • EXEC

  • DD Statements

  • PROC

  • COND

  • RC

  • GDG

  • IDCAMS

  • SORT

  • IKJEFT01

Ao começar a estudar Linux, você encontrará conceitos aparentemente novos:

  • Bash

  • Variáveis

  • Loops

  • Pipes

  • Exit Status

  • Cron

  • sed

  • awk

  • grep

A boa notícia é que boa parte dessa lógica já faz parte da sua experiência.

Hoje vamos tomar um café e descobrir que o universo Mainframe e o universo Linux possuem muito mais pontos em comum do que a maioria das pessoas imagina.


Dois mundos separados por décadas

IBM Mainframe

O primeiro System/360 foi anunciado pela IBM em 7 de abril de 1964.

Foi uma revolução.

Pela primeira vez uma família inteira de computadores utilizava a mesma arquitetura.

Junto com ela surgiu o conceito de execução Batch em larga escala.

Era necessário criar uma linguagem capaz de dizer ao sistema operacional:

  • qual programa executar;

  • quais arquivos utilizar;

  • quais impressoras imprimir;

  • onde gravar a saída;

  • como controlar o fluxo.

Nascia o Job Control Language (JCL).


UNIX

Cinco anos depois, em 1969, Ken Thompson iniciou o UNIX nos Bell Labs.

A filosofia era completamente diferente.

Em vez de grandes computadores corporativos, o objetivo era construir um sistema operacional simples, modular e portátil.

Ao invés de Jobs Batch, surgiram pequenos comandos.

Ao invés de DD Statements, surgiram arquivos comuns.

Ao invés de datasets catalogados, surgiram diretórios.

Ao invés do JCL, surgiu o Shell.


O Problema que Ambos Resolvem

Apesar das diferenças históricas, ambos procuram responder exatamente às mesmas perguntas:

O que deve ser executado?

Em que ordem?

Quais arquivos serão utilizados?

Como tratar erros?

O que fazer quando terminar?

É justamente por isso que tantas empresas conseguem integrar Mainframe e Linux.


A Filosofia de Cada Um

JCL

O JCL é uma linguagem declarativa.

Ele descreve um trabalho.

O sistema operacional executa.

Exemplo:

//JOB1 JOB ...
//STEP1 EXEC PGM=COBOLPGM
//SYSIN DD *
...

Você informa:

  • programa

  • datasets

  • parâmetros

O restante fica sob responsabilidade do z/OS.


Shell Script

O Shell Script é procedural.

Você escreve cada passo.

cp arquivo backup

gzip backup

rm arquivo

O Shell executa exatamente na ordem definida.


Primeira Grande Diferença

JCL controla programas.

Shell Script executa comandos.

Essa distinção parece pequena.

Mas muda completamente a arquitetura.


Quem executa?

Mainframe

JCL

↓

JES2/JES3

↓

Initiator

↓

Programa COBOL

O JES agenda.

Controla filas.

Seleciona recursos.

Gerencia prioridades.


Linux

Shell

↓

Kernel

↓

Processo

Muito mais direto.

Não existe um JES intermediário.


Comparando Conceitos

IBM JCLShell Script
JOBScript
STEPComando
EXECExecução
DDArquivo
PROCFunção
PARM$1 $2
RCExit Status
CONDif
Schedulercron
SYSINstdin
SYSOUTstdout
SYSPRINTstdout
JESShell + Kernel

Observe que praticamente todos os conceitos possuem um equivalente.


JOB x Script

No Mainframe:

//MEUJOB JOB ...

No Linux

#!/bin/bash

Ambos representam o início da automação.


STEP x Comando

Cada STEP executa um programa.

//STEP01 EXEC PGM=SORT

No Shell

sort arquivo.txt

A ideia é exatamente a mesma.


DD Statement x Arquivos

No Mainframe

//ENTRADA DD DSN=CLIENTES

No Linux

clientes.txt

O conceito é semelhante.

A implementação é completamente diferente.


Dataset vs Sistema de Arquivos

Mainframe

CLIENTES.VENDAS.2025

Linux

/clientes/vendas/2025.txt

No Mainframe existe um catálogo.

No Linux existe uma árvore de diretórios.


GDG x Arquivos Versionados

O GDG cria gerações automaticamente.

ARQ(+1)

ARQ(0)

ARQ(-1)

No Linux normalmente fazemos:

backup-20260704.tar.gz

Ou utilizamos ferramentas como:

  • rsnapshot

  • borg

  • restic


PROC x Funções

PROC

// EXEC PROC=BACKUP

Shell

backup(){

}

Ambos evitam repetição.


RC x Exit Status

Talvez a maior semelhança.

Mainframe

RC=0000

Linux

$?

↓

0

RC 8

No Linux

Exit Status 8

A filosofia permanece.


COND x IF

JCL

COND=(4,LT)

Shell

if [ $? -lt 4 ]
then

fi

Mesmo conceito.

Sintaxe diferente.


Scheduler x Cron

Mainframe

Control-M

CA-7

IBM Workload Scheduler

ESP

Linux

Cron

Systemd Timer

Kubernetes CronJob

Airflow

A ideia continua sendo:

"Execute automaticamente."


SYSIN x stdin

Mainframe

//SYSIN DD *

Linux

comando < entrada.txt

Ambos fornecem entrada ao programa.


SYSOUT x stdout

Mainframe

//SYSPRINT DD SYSOUT=*

Linux

>

Redirecionamento.


RC e Tratamento de Erros

Mainframe

IF RC > 8

Linux

if [ $? -gt 8 ]

Scripts profissionais verificam sempre o retorno da operação anterior.


Pipes

Aqui surge uma diferença enorme.

O JCL não possui Pipes nativos.

No Linux:

grep ERROR log \
| awk '{print $2}' \
| sort \
| uniq

Os dados fluem diretamente entre processos.

É uma das maiores inovações do UNIX.


grep x SORT Utility

Mainframe

DFSORT

ICETOOL

SYNCSORT

Linux

grep

sort

uniq

cut

awk

sed

São ferramentas menores, porém extremamente especializadas.


IDCAMS x Comandos Linux

IDCAMS

LISTCAT

DELETE

DEFINE

ALTER

No Linux

ls

rm

mkdir

mv

cp

Ambos administram recursos.


IKJEFT01

No Mainframe

Executa comandos TSO em Batch.

No Linux

O próprio Shell executa comandos diretamente.


Variáveis

No JCL

&DATA

No Shell

$DATA

Conceito muito semelhante.


Loops

JCL praticamente não possui repetição.

Shell

for

while

until

Essa é uma enorme vantagem do Shell.


Expressões Regulares

Outro diferencial.

O Shell possui:

grep

sed

awk

regex

O JCL depende normalmente do programa executado.


Permissões

No Mainframe

RACF

ACF2

Top Secret

No Linux

rwx

Controlados por:

chmod

chown

ACL


Segurança

Mainframe

RACF

Linux

PAM

SELinux

AppArmor

Embora diferentes, ambos seguem princípios semelhantes de autenticação e autorização.


Performance

O Mainframe foi criado para:

milhões de transações

Linux

milhões de processos

Cada um otimizado para seu ambiente.


Cloud

JCL praticamente não conversa diretamente com APIs REST.

Shell Script faz isso naturalmente.

curl

wget

Essa integração explica sua enorme popularidade.


DevOps

Ferramentas modernas utilizam Shell Script diariamente.

Jenkins

GitLab

GitHub

Docker

Kubernetes

Ansible

Terraform

Mesmo quando escritas em outras linguagens, o Shell continua sendo a "cola" que integra todas elas.


Shell no IBM Z

Aqui muitos profissionais se surpreendem.

O z/OS possui o UNIX System Services (USS).

Isso significa que é possível executar:

  • Bash

  • Korn Shell

  • POSIX Shell

  • Git

  • Python

  • Java

Tudo dentro do IBM Z.

É justamente esse recurso que permite pipelines modernos envolvendo COBOL, Git, Jenkins e DevOps.


Curiosidades

  • O JCL possui mais de 60 anos de história e continua em uso em bancos, seguradoras e governos.

  • O Bash, lançado em 1989, permanece como o shell padrão de inúmeras distribuições Linux.

  • O primeiro shell do UNIX era extremamente simples e não possuía muitos dos recursos atuais, como histórico de comandos e autocompletar.

  • O conceito de pipe (|) foi introduzido no UNIX na década de 1970 e tornou-se um dos maiores símbolos da filosofia UNIX.

  • Muitos scripts corporativos executados diariamente ainda são compostos por poucas dezenas de linhas, mas movimentam bilhões de dólares em operações.


Easter Eggs

Algumas curiosidades divertidas:

  • O nome Bash significa Bourne Again Shell, uma brincadeira com o Bourne Shell original.

  • O comando : é um comando válido que não faz nada e retorna sucesso (0).

  • true sempre retorna código de sucesso.

  • false sempre retorna um código de erro.

  • No JCL, um único parâmetro incorreto em um DD Statement pode impedir a execução de um Job inteiro; no Shell, esquecer aspas em uma variável pode causar efeitos igualmente inesperados.


Quando Escolher Cada Um?

Use JCL quando:

  • estiver executando workloads Batch do z/OS;

  • precisar integrar programas COBOL, PL/I, Assembler ou Db2 no ambiente Mainframe;

  • utilizar JES, datasets, PROCs e schedulers corporativos.

Use Shell Script quando:

  • administrar servidores Linux;

  • automatizar tarefas DevOps;

  • criar pipelines CI/CD;

  • integrar APIs REST;

  • trabalhar com containers, Kubernetes e serviços em nuvem;

  • automatizar operações no z/OS UNIX System Services.

Em muitos ambientes modernos, os dois convivem: o JCL inicia processos no z/OS, enquanto o Shell Script automatiza componentes Linux, integra aplicações via APIs e participa dos pipelines de entrega contínua.

Conclusão

JCL e Shell Script são filhos de épocas diferentes, mas compartilham a mesma missão: automatizar o trabalho do computador para que o operador não precise repetir tarefas manualmente. O JCL nasceu em um mundo dominado por processamento batch, grandes volumes de dados e controle rigoroso de recursos do IBM Mainframe. O Shell Script surgiu em um ambiente UNIX que valorizava simplicidade, modularidade e a composição de pequenos programas especializados.

Para um Programador COBOL Padawan, compreender essa relação é um enorme diferencial. Em vez de enxergar o Linux como um universo completamente novo, é possível reconhecer conceitos familiares: JOB e script, STEP e comando, PROC e função, RC e Exit Status, SYSIN e stdin, SYSOUT e stdout. Essa ponte reduz a curva de aprendizado e facilita a atuação em projetos de modernização.

Na era da transformação digital, não existe mais uma divisão rígida entre Mainframe e plataformas abertas. Bancos, seguradoras, indústrias e órgãos governamentais executam aplicações COBOL no IBM Z, integram serviços por APIs, utilizam Git, Jenkins, Ansible, Kubernetes e automatizam grande parte da infraestrutura com Shell Script. O profissional que domina esses dois mundos torna-se capaz de construir soluções híbridas, conectar tecnologias históricas às plataformas modernas e participar da evolução contínua da computação corporativa.

Em outras palavras, aprender Shell Script não significa abandonar o Mainframe. Significa ampliar sua caixa de ferramentas e levar a experiência adquirida no IBM Z para um ecossistema cada vez mais integrado, automatizado e orientado à nuvem. Esse é o caminho do Programador COBOL Padawan rumo ao próximo nível de sua jornada profissional.

terça-feira, 30 de janeiro de 2018

Shell Scripting - O Que Todo Programador COBOL Padawan Precisa Saber Sobre a Linguagem que Automatiza o Mundo Linux, DevOps, Cloud e Infraestrutura Moderna

 

Bellacosa Mainframe e o shell scripting

☕ Um Café no Bellacosa Mainframe

Shell Scripting

O Que Todo Programador COBOL Padawan Precisa Saber Sobre a Linguagem que Automatiza o Mundo Linux, DevOps, Cloud e Infraestrutura Moderna

"Você não está apenas aprendendo Shell Script. Está descobrindo a linguagem que faz no Linux aquilo que o JCL faz no Mainframe: coordenar, automatizar e colocar toda a infraestrutura para trabalhar em perfeita harmonia."


Introdução

Existe um momento na carreira de praticamente todo profissional de tecnologia em que ele percebe que digitar dezenas de comandos repetidamente não faz mais sentido.

Criar usuários.

Mover arquivos.

Executar backups.

Monitorar logs.

Subir aplicações.

Executar testes.

Parar servidores.

Gerar relatórios.

Se tudo isso pode ser automatizado, por que continuar fazendo manualmente?

Foi exatamente essa pergunta que ajudou a moldar um dos conceitos mais elegantes da história da computação: o Shell Script.

Hoje, praticamente toda infraestrutura Linux do planeta — desde pequenos servidores domésticos até supercomputadores, clusters Kubernetes, ambientes IBM LinuxONE, IBM Z, AWS, Azure e Google Cloud — depende diariamente de milhares de Shell Scripts.

Se você é um Programador COBOL Padawan, provavelmente já domina conceitos como JCL, Return Codes (RC), Jobs Batch, PROCs, Schedulers, datasets e automação no z/OS.

A boa notícia é que Shell Script não é um universo completamente novo.

Na verdade, diversos conceitos já fazem parte do seu dia a dia.

A diferença é que agora eles vivem no mundo Linux.

Pegue sua caneca de café.

Hoje vamos entender por que Shell Script continua sendo uma das habilidades mais valiosas da computação moderna.


A Origem do Shell

Para entender Shell Script precisamos voltar aproximadamente cinquenta anos.

Em 1969, Ken Thompson iniciou o desenvolvimento do UNIX nos laboratórios Bell Labs.

O sistema operacional precisava de uma interface simples para executar comandos.

Nascia então o primeiro Shell.

O Shell era apenas um interpretador.

Ele recebia comandos digitados pelo usuário.

Interpretava.

Chamava funções do Kernel.

Mostrava os resultados.

Naquela época ninguém imaginava que alguns anos depois aqueles comandos poderiam ser gravados em arquivos texto e executados automaticamente.

Assim surgiram os primeiros scripts.


O Shell Não é o Linux

Esse é um dos maiores equívocos dos iniciantes.

Muitos acreditam que Shell e Linux sejam a mesma coisa.

Não são.

A arquitetura simplificada funciona assim:

Usuário

↓

Shell

↓

Kernel Linux

↓

Hardware

O Kernel conversa com discos, memória, processadores e dispositivos.

O Shell conversa com o usuário.

Ele traduz comandos humanos em chamadas para o Kernel.


O Nascimento do Bourne Shell

Em 1977, Stephen Bourne desenvolveu o Bourne Shell (sh).

Foi uma revolução.

Pela primeira vez era possível escrever programas inteiros utilizando comandos do próprio sistema operacional.

A linguagem era simples.

Mas incrivelmente poderosa.

Até hoje praticamente todos os Shells modernos descendem dele.


O Surgimento do Bash

Em 1989, Brian Fox, no projeto GNU, lançou o Bash (Bourne Again Shell).

O nome é um trocadilho com "Born Again".

Ele foi desenvolvido para substituir o Bourne Shell tradicional, mantendo compatibilidade e adicionando diversos recursos modernos.

O Bash tornou-se rapidamente o padrão das distribuições GNU/Linux.

Hoje ele está presente em praticamente todas as distribuições Linux e em diversos sistemas UNIX.


Linha do Tempo dos Principais Shells

AnoShellCriador
1971Thompson ShellKen Thompson
1977Bourne Shell (sh)Stephen Bourne
1983Korn Shell (ksh)David Korn
1989BashBrian Fox (GNU)
1990Z Shell (zsh)Paul Falstad
2005Fish ShellAxel Liljencrantz

Cada um possui características específicas, mas Bash continua sendo a principal referência para automação.


Por que o Shell Existe?

Imagine administrar mil servidores.

Sem Shell Script seria necessário executar centenas de comandos manualmente em cada máquina.

Com um único script você consegue:

  • atualizar aplicações;

  • reiniciar serviços;

  • copiar arquivos;

  • verificar espaço em disco;

  • consultar APIs;

  • monitorar processos;

  • enviar alertas;

  • automatizar backups.

É exatamente por isso que o Shell é considerado uma das ferramentas fundamentais de DevOps.


A Filosofia UNIX

Existe um princípio que influenciou praticamente toda a engenharia de software moderna:

Faça uma coisa. Faça bem feita.

Em vez de criar programas gigantes, o UNIX passou a oferecer dezenas de pequenas ferramentas especializadas.

Cada comando resolve apenas um problema.

Por exemplo:

  • grep procura padrões.

  • sort ordena dados.

  • uniq elimina duplicatas.

  • cut extrai colunas.

  • sed transforma textos.

  • awk processa dados estruturados.

  • wc conta linhas, palavras e caracteres.

O verdadeiro poder surge quando essas ferramentas são combinadas por meio de pipes.


O Poder dos Pipes

O caractere | é muito mais do que um simples símbolo.

Ele conecta a saída de um comando diretamente à entrada do próximo.

Imagine uma linha de montagem industrial:

Matéria-prima
     ↓
Corte
     ↓
Pintura
     ↓
Montagem
     ↓
Embalagem

No Linux:

cat

↓

grep

↓

awk

↓

sort

↓

uniq

↓

wc

Cada comando realiza uma tarefa específica e entrega o resultado ao próximo.

Esse modelo permitiu construir sistemas extremamente eficientes décadas antes da popularização dos microsserviços.


Shell Script e o Mundo Mainframe

Esta é provavelmente a parte mais interessante para um Programador COBOL Padawan.

Observe a comparação:

MainframeLinux
JCLShell Script
PROCFunção
PARM$1, $2
Return CodeExit Status
DatasetArquivo
SchedulerCron
SYSINstdin
SYSOUTstdout
SYSPRINTstdout
CONDif
IF/THEN JCLif/then

Percebe a semelhança?

Os conceitos mudam de nome, mas a lógica permanece.

Quem domina JCL normalmente aprende Shell Script muito mais rapidamente.


Shebang

Todo script profissional começa com algo parecido com:

#!/usr/bin/env bash

Esse cabeçalho informa qual interpretador será utilizado.

Sem ele, o sistema pode tentar executar o script utilizando outro Shell, causando incompatibilidades.

É equivalente a informar explicitamente qual ambiente executará o programa.


Variáveis

No Shell praticamente tudo começa com variáveis.

NOME="Bellacosa"
IDADE=52

Elas armazenam dados temporários utilizados durante a execução.

O acesso ocorre por meio do caractere $.

echo "$NOME"

Diferentemente de linguagens como Java ou COBOL, não há necessidade de declarar tipos de dados.

Tudo inicialmente é tratado como texto.


Variáveis de Ambiente

Algumas variáveis já existem antes mesmo do script iniciar.

Entre as mais importantes estão:

  • HOME

  • PATH

  • USER

  • SHELL

  • PWD

  • HOSTNAME

  • LANG

  • TERM

Essas informações descrevem o ambiente onde o processo está sendo executado.


Variáveis Especiais

O Shell também cria automaticamente variáveis especiais:

  • $0 → nome do script.

  • $1 → primeiro argumento.

  • $2 → segundo argumento.

  • $# → quantidade de argumentos.

  • $@ → todos os argumentos preservando cada um individualmente.

  • $* → todos os argumentos como uma única expansão.

  • $$ → PID do processo atual.

  • $! → PID do último processo em background.

  • $? → código de retorno do último comando.

Essa coleção de variáveis torna os scripts altamente reutilizáveis.


Condições

Assim como em COBOL existe IF, o Shell possui:

if
then
else
fi

É possível tomar decisões baseadas em:

  • existência de arquivos;

  • valores numéricos;

  • comparação de textos;

  • permissões;

  • retorno de comandos.


Loops

O Shell oferece diferentes formas de repetição.

For

Ideal quando conhecemos previamente os elementos.

for arquivo in *.txt
do
    echo "$arquivo"
done

While

Executa enquanto uma condição permanece verdadeira.

Until

Executa até que uma condição seja satisfeita.


Funções

Scripts profissionais utilizam funções para evitar repetição.

backup() {
    echo "Executando backup..."
}

log() {
    echo "$(date) $1"
}

Isso melhora organização, manutenção e reutilização.


Operadores de Arquivos

Antes de manipular arquivos, normalmente verificamos seu estado.

Exemplos:

  • -f → arquivo regular.

  • -d → diretório.

  • -r → leitura.

  • -w → escrita.

  • -x → executável.

  • -e → existe.

  • -s → não vazio.

  • -L → link simbólico.

Esses testes evitam erros durante a execução.


Redirecionamento

Todo processo Linux trabalha com três fluxos principais:

StreamNúmero
stdin0
stdout1
stderr2

Com isso podemos controlar exatamente para onde cada informação será enviada.

Exemplos:

>

Sobrescreve um arquivo.

>>

Acrescenta conteúdo.

2>

Redireciona apenas mensagens de erro.

&

Permite combinar fluxos.


O Poder do grep

O grep talvez seja o comando mais famoso do Linux.

Seu nome vem de Global Regular Expression Print.

Ele pesquisa padrões em arquivos.

grep ERROR servidor.log

Combinado com expressões regulares torna-se uma poderosa ferramenta de análise de logs.


AWK

Apesar de parecer apenas mais um comando, AWK é uma linguagem completa.

Ela trabalha naturalmente com colunas.

Por isso é muito utilizada em:

  • arquivos CSV;

  • relatórios;

  • processamento de logs;

  • extração de métricas.

Poucas ferramentas conseguem manipular dados textuais com tanta eficiência.


sed

O Stream Editor permite modificar arquivos sem abrir um editor.

Trocar:

IBM

por

Red Hat

é uma simples linha de comando.

Por isso o sed aparece frequentemente em pipelines de automação.


xargs

Outro comando extremamente poderoso.

Ele transforma a saída de um programa em argumentos para outro.

É muito utilizado em conjunto com find.


Exit Status

No Mainframe conhecemos os Return Codes.

No Linux existe exatamente o mesmo conceito.

Após qualquer comando podemos consultar:

echo $?

Se retornar zero:

Sucesso.

Qualquer outro valor indica algum tipo de erro.

Scripts profissionais nunca ignoram Exit Status.


DevOps e Shell Script

Hoje praticamente toda ferramenta DevOps depende, em algum momento, de Shell Script.

Exemplos:

Docker.

Kubernetes.

GitHub Actions.

GitLab CI.

Jenkins.

Ansible.

Terraform.

OpenShift.

IBM Cloud.

AWS.

Azure.

Google Cloud.

Mesmo quando utilizamos ferramentas sofisticadas, nos bastidores normalmente existem Shell Scripts coordenando processos.


Shell Script no IBM Z

Muitos profissionais acreditam que Shell Script pertence apenas ao Linux.

Não é verdade.

O IBM z/OS UNIX System Services (USS) oferece um ambiente POSIX compatível com Shell.

Isso significa que é possível executar scripts Bash ou Korn Shell diretamente no IBM Z.

Essa integração permite:

  • automatizar tarefas administrativas;

  • integrar aplicações COBOL com ambientes UNIX;

  • manipular arquivos no USS;

  • chamar programas tradicionais;

  • trabalhar com OpenSSH, Git, Python e Java.

É um dos pilares da modernização do ecossistema IBM Z.


Curiosidades

  • O Bash possui milhares de comandos internos (builtins).

  • O Shell consegue chamar programas escritos em C, COBOL, Java, Python e diversas outras linguagens.

  • Grande parte dos scripts de inicialização do Linux são Shell Scripts.

  • O Shell pode controlar processos distribuídos por SSH em centenas de servidores simultaneamente.

  • Muitos instaladores de software corporativo são escritos em Shell Script.


Easter Eggs

Algumas curiosidades divertidas:

  • O nome Bash significa Bourne Again Shell, um trocadilho com o Bourne Shell.

  • O comando : é um comando válido que não faz absolutamente nada, retornando sucesso (0).

  • O comando true sempre retorna sucesso.

  • O comando false sempre retorna erro.

  • É possível criar scripts de apenas uma linha capazes de automatizar tarefas extremamente complexas.

  • Muitos administradores brincam dizendo que "um bom Shell Script substitui centenas de cliques".


Releases e Evolução

Ao longo das décadas, o Bash evoluiu significativamente:

  • suporte aprimorado a arrays;

  • expansão de parâmetros;

  • autocompletar inteligente;

  • histórico avançado;

  • melhorias em segurança;

  • compatibilidade POSIX;

  • otimizações de desempenho.

Novas versões continuam sendo lançadas e mantidas pela comunidade GNU, garantindo correções de bugs, melhorias de segurança e novos recursos.


Por que Aprender Shell Script em 2026?

Porque praticamente toda infraestrutura moderna depende dele.

Empresas utilizam Shell Script para:

  • automação de Data Centers;

  • CI/CD;

  • monitoramento;

  • backup;

  • segurança;

  • observabilidade;

  • containers;

  • Kubernetes;

  • administração Linux;

  • IBM Z USS;

  • LinuxONE;

  • Cloud Computing;

  • IA e MLOps;

  • automação de pipelines de dados.

Mesmo linguagens modernas como Python e Go frequentemente executam Shell Scripts durante processos de instalação, build ou deploy.


Compatibilidade com o Mundo Mainframe

Para quem vem do COBOL, aprender Shell Script oferece diversas vantagens:

  • compreensão rápida da lógica de automação;

  • facilidade para trabalhar com z/OS UNIX System Services;

  • integração com Git, DevOps e CI/CD;

  • modernização de aplicações IBM Z;

  • comunicação entre ambientes Linux e Mainframe.

Em projetos de transformação digital é comum encontrar pipelines que envolvem simultaneamente COBOL, JCL, Git, Jenkins, Ansible e Shell Script.


Conclusão

Shell Script é muito mais do que uma linguagem de comandos. Ele representa uma filosofia de engenharia que atravessa mais de cinco décadas de evolução da computação. Desde os primeiros laboratórios da Bell Labs até os atuais ambientes de nuvem híbrida, inteligência artificial, IBM Z, LinuxONE e plataformas de automação em escala global, o Shell continua sendo uma das ferramentas mais eficientes para transformar tarefas repetitivas em processos confiáveis e reproduzíveis.

Para um Programador COBOL Padawan, essa jornada é especialmente natural. Conceitos como controle de fluxo, códigos de retorno, automação batch, parametrização e orquestração já fazem parte da experiência adquirida no Mainframe. O Shell Script amplia esse repertório, conectando o universo IBM Z ao ecossistema Linux, DevOps, containers, APIs, pipelines de integração contínua e infraestrutura como código.

Aprender Shell Script hoje não significa apenas dominar comandos como grep, awk, sed, find ou xargs. Significa adquirir a capacidade de construir soluções reutilizáveis, integrar tecnologias distintas, administrar ambientes complexos e participar ativamente da modernização das plataformas corporativas. Assim como o COBOL continua movimentando bilhões de transações diariamente, o Shell Script permanece como uma das engrenagens invisíveis que sustentam servidores, aplicações, clusters e serviços em praticamente todos os grandes ambientes computacionais do mundo.

No fim das contas, o Shell Script ensina uma lição que vale para toda a carreira em tecnologia: automatize o repetitivo, simplifique o complexo e deixe que os computadores façam aquilo para o qual foram criados. Esse é o espírito do UNIX, do Linux, do DevOps e, acima de tudo, da engenharia de software moderna.