Como Executar um Arquivo .sh no Linux: Guia Completo para Iniciantes e Administradores de Sistema
Os scripts shell são a base da automação Linux. Quer esteja a implementar uma aplicação web, a agendar cópias de segurança ou a configurar um servidor recém-aprovisionado, os ficheiros .sh permitem-lhe agrupar sequências de comandos complexas num único executável repetível. Este guia orienta-o através de todos os métodos para executar scripts shell em Linux — desde a execução básica até processos em segundo plano e agendamento cron — com as melhores práticas que se mantêm em ambientes de produção.
O Que É um Arquivo .sh no Linux?
Um arquivo .sh é um script de texto simples escrito em linguagem shell (normalmente Bash ou POSIX sh) que o shell do Linux interpreta e executa linha por linha. Scripts shell são usados para:
- Automatizar tarefas repetitivas de administração de sistemas
- Implantar e configurar aplicações
- Gerenciar utilizadores, permissões e sistemas de ficheiros
- Agendar trabalhos de manutenção como backups e rotação de registos
- Inicializar novos servidores após provisionamento
Se está a gerir um ambiente de VPS Hosting ou um Servidor Dedicado, a programação em shell é uma competência indispensável que lhe poupará horas de trabalho manual todas as semanas.
Pré-requisitos
Antes de executar qualquer arquivo .sh, certifique-se de que tem:
- Acesso a um terminal Linux (local ou via SSH)
- Uma conta de utilizador com permissões apropriadas
- O ficheiro de script já no sistema (criado localmente ou transferido via SCP/SFTP)
Método 1: Tornar o Ficheiro Executável com chmod
Por padrão, ficheiros .sh recém-criados ou descarregados não têm permissões de execução. Antes de executar o script como um programa, deve conceder explicitamente direitos de execução usando o comando chmod.
chmod +x script.shPara verificar se as permissões foram aplicadas corretamente:
ls -l script.shDeverá ver um resultado semelhante a:
-rwxr-xr-x 1 user user 1024 Jun 10 14:32 script.shOs sinalizadores x confirmam que o ficheiro é agora executável pelo proprietário, grupo e outros.
> Dica de segurança: Se pretender restringir a execução apenas ao proprietário do ficheiro, use chmod 700 script.sh em vez de chmod +x.
Método 2: Executar o Script Usando um Caminho Relativo ou Absoluto
Depois que o arquivo fica executável, você pode executá-lo diretamente do terminal.
Usando um Caminho Relativo (Diretório Atual)
Se o script estiver no seu diretório de trabalho atual, prefixe-o com ./:
./script.shO ./ diz ao shell para procurar no diretório atual em vez de pesquisar o sistema $PATH.
Usando um Caminho Absoluto
Se o script estiver armazenado em outro local, forneça seu caminho completo:
/home/user/scripts/script.shou
/usr/local/bin/script.shUsar caminhos absolutos é especialmente importante ao executar scripts de cron jobs ou outros contextos automatizados onde o diretório de trabalho pode ser diferente.
Método 3: Executar o Script com bash ou sh (Sem Permissão de Execução Necessária)
Você pode invocar um script shell chamando explicitamente o interpretador, mesmo que o arquivo não tenha permissões de execução. Isto é particularmente útil para testar rapidamente um script antes de torná-lo permanentemente executável.
bash script.shou, para scripts compatíveis com POSIX:
sh script.shDiferença Entre bash e sh
| Comando | Interpretador | Suporta Recursos Específicos do Bash |
|---|---|---|
bash script.sh | GNU Bash | Sim |
sh script.sh | POSIX sh (frequentemente dash no Ubuntu) | Não |
Se o seu script usa sintaxe específica do Bash como arrays, [[ ]] condicionais, ou substituição de processos, sempre use bash em vez de sh.
Método 4: Executar o Script como Superuser (sudo)
Alguns scripts requerem privilégios de nível root para modificar ficheiros do sistema, gerir serviços, instalar pacotes ou alterar configurações de rede. Use sudo para elevar permissões:
sudo ./script.shou passe o script diretamente para bash com direitos elevados:
sudo bash script.shConsiderações Importantes de Segurança
- Nunca execute um script como root sem o ler primeiro. Um script malicioso ou mal escrito com acesso sudo pode causar danos irreversíveis ao sistema.
- Prefira executar scripts com os privilégios mínimos necessários.
- Se um script apenas precisa de escrever num diretório específico, considere ajustar as permissões do diretório em vez de executar todo o script como root.
Método 5: Executar o Script em Segundo Plano
Por padrão, executar um script no terminal bloqueia sua sessão até que o script seja concluído. Para tarefas de longa duração — como transferências de arquivos grandes, migrações de banco de dados ou compilações de servidor — você vai querer enviar o processo para o segundo plano.
Usando o Operador &
./script.sh &O símbolo & bifurca o processo para o segundo plano e retorna imediatamente o controle ao seu terminal. O shell imprime o PID (ID do Processo) do trabalho em segundo plano, que você pode usar para monitorá-lo ou encerrá-lo posteriormente.
Manter o Script em Execução Após Logout com nohup
Se você desconectar do SSH, os trabalhos em segundo plano iniciados com & normalmente serão encerrados. Use nohup para evitar isso:
nohup ./script.sh &A saída é redirecionada para nohup.out por padrão. Para especificar um arquivo de log personalizado:
nohup ./script.sh > /var/log/myscript.log 2>&1 &Monitorar Trabalhos em Segundo Plano
jobs # List background jobs in the current session
ps aux | grep script.sh # Find the process by name
kill PID # Terminate a specific background processMétodo 6: Agendar Execução de Script com Cron
Para tarefas recorrentes — backups noturnos, limpezas semanais, verificações horárias de saúde — o agendador cron integrado do Linux é a solução padrão.
Abrir o Editor Crontab
crontab -eSintaxe Cron
* * * * * /path/to/script.sh
│ │ │ │ │
│ │ │ │ └── Day of week (0–7, Sunday = 0 or 7)
│ │ │ └──── Month (1–12)
│ │ └────── Day of month (1–31)
│ └──────── Hour (0–23)
└────────── Minute (0–59)Exemplos Práticos de Cron
| Agendamento | Expressão Cron | Caso de Uso Exemplo |
|---|---|---|
| Todos os dias às 2:00 AM | 0 2 * * * | Backup de banco de dados noturno |
| Toda segunda-feira às 6:00 AM | 0 6 * * 1 | Rotação de logs semanal |
| A cada hora | 0 * * * * | Verificação de monitoramento de tempo de atividade |
| A cada 15 minutos | */15 * * * * | Atualização de cache |
| Na reinicialização do sistema | @reboot | Iniciar um serviço ou script na inicialização |
Exemplo: Backup Diário Automatizado
0 2 * * * /home/user/scripts/backup.sh >> /var/log/backup.log 2>&1Isto executa backup.sh todos os dias às 2:00 AM e anexa tanto a saída padrão quanto os erros a um arquivo de log para auditoria.
> Dica profissional: Sempre use caminhos absolutos em entradas cron. Cron é executado com um ambiente mínimo e pode não ter acesso ao mesmo $PATH que seu shell interativo.
Método 7: Executar um Script (Executar no Contexto da Shell Atual)
Existe um método de execução adicional que vale a pena conhecer: sourcing de um script. Ao contrário dos métodos acima, sourcing executa o script dentro da sessão shell atual em vez de gerar uma subshell. Isto significa que quaisquer variáveis ou funções definidas no script persistem no seu ambiente atual.
source script.shou equivalentemente:
. script.shIsto é comumente usado para carregar variáveis de ambiente, ativar ambientes virtuais ou aplicar alterações de configuração à sessão atual.
Resolução de Erros Comuns
| Mensagem de Erro | Causa Provável | Solução |
|---|---|---|
Permission denied | Ficheiro sem permissão de execução | Execute chmod +x script.sh |
No such file or directory | Caminho incorreto ou ficheiro em falta | Verifique o caminho com ls e pwd |
bad interpreter: No such file or directory | Linha shebang incorreta (por exemplo, terminações de linha do Windows) | Execute dos2unix script.sh para corrigir as terminações de linha |
command not found | Script não em $PATH e sem prefixo ./ | Use ./script.sh ou caminho absoluto completo |
syntax error near unexpected token | Script escrito para bash mas executado com sh | Use bash script.sh explicitamente |
Melhores Práticas para Escrever e Executar Scripts Shell
Seguir estas práticas tornará seus scripts mais seguros, mais fáceis de manter e mais fáceis de depurar — especialmente em ambientes de servidor.
1. Sempre Comece com uma Linha Shebang
A primeira linha de cada script deve declarar o interpretador:
#!/bin/bashou para máxima portabilidade:
#!/usr/bin/env bash2. Ativar Modo Rigoroso
Adicione isto perto do topo de cada script de produção:
set -euo pipefail-e— Sair imediatamente se algum comando falhar-u— Tratar variáveis não definidas como erros-o pipefail— Capturar falhas em comandos canalizados
3. Leia o Script Antes de Executá-lo
Nunca execute um arquivo .sh de uma fonte externa ou não confiável sem revisar seu conteúdo primeiro:
cat script.shou abra-o em um editor de texto. Isto é especialmente crítico ao executar com sudo.
4. Use Comentários Generosamente
#!/bin/bash
# backup.sh — Daily backup script for /var/www
# Author: sysadmin@example.com
# Last updated: 2024-06-10
# Define source and destination directories
SOURCE="/var/www"
DEST="/mnt/backup"5. Organize Scripts em Diretórios Dedicados
| Diretório | Uso Recomendado |
|---|---|
/usr/local/bin/ | Scripts de todo o sistema acessíveis a todos os utilizadores |
~/scripts/ ou ~/bin/ | Scripts pessoais do utilizador |
/opt/scripts/ | Scripts de automação específicos da aplicação |
/etc/cron.daily/ | Scripts para executar diariamente via cron |
6. Registar Saída de Script
Sempre redirecione a saída para um arquivo de registo para scripts executados sem supervisão:
./script.sh >> /var/log/script.log 2>&17. Teste Scripts em um Ambiente Seguro Primeiro
Antes de implementar um script em um servidor de produção, teste-o em um ambiente de teste ou em uma instância VPS descartável onde erros não causarão tempo de inatividade.
Executar Scripts Shell num Servidor Linux: Considerações Práticas
Ao executar scripts num servidor Linux remoto — seja num ambiente partilhado ou numa máquina dedicada — alguns fatores adicionais entram em jogo:
- Acesso SSH: A maioria dos scripts do lado do servidor é executada via SSH. Ferramentas como
screenoutmuxpermitem manter sessões persistentes para que scripts de longa duração sobrevivam a desconexões. - Permissões de utilizador: Em ambientes de alojamento partilhado, a sua capacidade de executar scripts pode ser limitada. Um VPS com cPanel oferece acesso root completo e controlo total sobre a execução de scripts.
- Implementações automatizadas: Combine scripts shell com tarefas cron para automatizar implementações, renovações de certificados (especialmente útil juntamente com Certificados SSL), e tarefas de manutenção rotineira.
- Variáveis de ambiente: Scripts executados via cron ou SSH podem não herdar o ambiente da sua shell interativa. Defina todas as variáveis necessárias explicitamente dentro do script ou carregue um ficheiro de perfil.
Referência Rápida: Todos os Métodos em Resumo
| Método | Comando | Caso de Uso |
|---|---|---|
| Executar com permissão | chmod +x script.sh && ./script.sh | Execução padrão |
| Executar com bash | bash script.sh | Sem necessidade de permissão de execução |
| Executar com sh | sh script.sh | Scripts compatíveis com POSIX |
| Executar como root | sudo ./script.sh | Scripts que requerem privilégios elevados |
| Executar em background | ./script.sh & | Execução sem bloqueio |
| Executar persistentemente | nohup ./script.sh & | Sobreviver ao logout SSH |
| Agendar com cron | crontab -e | Tarefas automatizadas recorrentes |
| Fazer source do script | source script.sh | Aplicar alterações ao shell atual |
Conclusão
Executar arquivos .sh em Linux é uma habilidade fundamental que desbloqueia todo o poder da automação de sistemas. O fluxo de trabalho principal é simples: conceda permissão de execução com chmod +x, depois execute o script com ./script.sh ou bash script.sh. Para ambientes de produção, combine caminhos absolutos, modo estrito, logging e agendamento com cron para construir pipelines de automação robustos e confiáveis.
Se você está gerenciando scripts em um servidor, a qualidade da sua infraestrutura de hospedagem importa. O VPS Hosting e os Servidores Dedicados da AlexHost oferecem acesso root completo, uptime estável e o desempenho que você precisa para executar cargas de trabalho de automação com confiança — seja agendando backups noturnos, implantando aplicações ou gerenciando fluxos de trabalho complexos com múltiplos scripts.
em todos os serviços de alojamento