Poupe 15% em todos os serviços de alojamento

Teste as suas habilidades e obtenha Desconto em qualquer plano

Utilizar o código: Skills Começar a trabalhar
Secções
Administração Linux

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.sh

Para verificar se as permissões foram aplicadas corretamente:

ls -l script.sh

Deverá ver um resultado semelhante a:

-rwxr-xr-x 1 user user 1024 Jun 10 14:32 script.sh

Os 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.sh

O ./ 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.sh

ou

/usr/local/bin/script.sh

Usar 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.sh

ou, para scripts compatíveis com POSIX:

sh script.sh

Diferença Entre bash e sh

ComandoInterpretadorSuporta Recursos Específicos do Bash
bash script.shGNU BashSim
sh script.shPOSIX 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.sh

ou passe o script diretamente para bash com direitos elevados:

sudo bash script.sh

Consideraçõ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 process

Mé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 -e

Sintaxe 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

AgendamentoExpressão CronCaso de Uso Exemplo
Todos os dias às 2:00 AM0 2 * * *Backup de banco de dados noturno
Toda segunda-feira às 6:00 AM0 6 * * 1Rotação de logs semanal
A cada hora0 * * * *Verificação de monitoramento de tempo de atividade
A cada 15 minutos*/15 * * * *Atualização de cache
Na reinicialização do sistema@rebootIniciar 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>&1

Isto 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.sh

ou equivalentemente:

. script.sh

Isto é 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 ErroCausa ProvávelSolução
Permission deniedFicheiro sem permissão de execuçãoExecute chmod +x script.sh
No such file or directoryCaminho incorreto ou ficheiro em faltaVerifique o caminho com ls e pwd
bad interpreter: No such file or directoryLinha shebang incorreta (por exemplo, terminações de linha do Windows)Execute dos2unix script.sh para corrigir as terminações de linha
command not foundScript não em $PATH e sem prefixo ./Use ./script.sh ou caminho absoluto completo
syntax error near unexpected tokenScript escrito para bash mas executado com shUse 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/bash

ou para máxima portabilidade:

#!/usr/bin/env bash

2. 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.sh

ou 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órioUso 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>&1

7. 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 screen ou tmux permitem 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étodoComandoCaso de Uso
Executar com permissãochmod +x script.sh && ./script.shExecução padrão
Executar com bashbash script.shSem necessidade de permissão de execução
Executar com shsh script.shScripts compatíveis com POSIX
Executar como rootsudo ./script.shScripts que requerem privilégios elevados
Executar em background./script.sh &Execução sem bloqueio
Executar persistentementenohup ./script.sh &Sobreviver ao logout SSH
Agendar com croncrontab -eTarefas automatizadas recorrentes
Fazer source do scriptsource script.shAplicar 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.