Zaoszczędź 15% na wszystkich usługach hostingowych

Sprawdź swoje umiejętności i zdobądź Rabat na dowolny plan hostingowy

Użyj kodu: Skills Rozpocznij
Sekcja
Administracja Linux

Jak uruchomić plik .sh w systemie Linux: Kompletny przewodnik dla początkujących i administratorów systemów

Skrypty powłoki są podstawą automatyzacji Linux. Niezależnie od tego, czy wdrażasz aplikację internetową, planujesz kopie zapasowe czy konfigurujesz nowo aprowizowany serwer, pliki .sh pozwalają na połączenie złożonych sekwencji poleceń w jeden powtarzalny plik wykonywalny. Ten przewodnik przeprowadzi Cię przez każdą metodę uruchamiania skryptów powłoki w Linux — od podstawowego wykonania po procesy w tle i planowanie cron — z najlepszymi praktykami, które sprawdzają się w środowiskach produkcyjnych.

Co to jest plik .sh w systemie Linux?

Plik .sh to zwykły skrypt tekstowy napisany w języku shell (zazwyczaj Bash lub POSIX sh), który shell Linux interpretuje i wykonuje linia po linii. Skrypty shell są używane do:

  • Automatyzacji powtarzających się zadań administracji systemu
  • Wdrażania i konfiguracji aplikacji
  • Zarządzania użytkownikami, uprawnieniami i systemami plików
  • Planowania zadań konserwacyjnych, takich jak kopie zapasowe i rotacja dzienników
  • Uruchamiania nowych serwerów po aprowizacji

Jeśli zarządzasz środowiskiem VPS Hosting lub Dedicated Server, skrypty shell to niezbędna umiejętność, która zaoszczędzi Ci godzin pracy ręcznej każdego tygodnia.

Wymagania wstępne

Przed uruchomieniem jakiegokolwiek pliku .sh, upewnij się, że masz:

  • Dostęp do terminala Linux (lokalnie lub przez SSH)
  • Konto użytkownika z odpowiednimi uprawnieniami
  • Plik skryptu już w systemie (utworzony lokalnie lub przesłany przez SCP/SFTP)

Metoda 1: Uczyń plik wykonywalnym za pomocą chmod

Domyślnie nowo utworzone lub pobrane .sh pliki nie mają uprawnień do wykonania. Przed uruchomieniem skryptu jako programu musisz jawnie przyznać prawa wykonania za pomocą polecenia chmod.

chmod +x script.sh

Aby sprawdzić, czy uprawnienia zostały zastosowane poprawnie:

ls -l script.sh

Powinieneś zobaczyć dane wyjściowe podobne do:

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

Flagi x potwierdzają, że plik jest teraz wykonywalny przez właściciela, grupę i innych.

> Wskazówka bezpieczeństwa: Jeśli chcesz ograniczyć wykonanie tylko do właściciela pliku, użyj chmod 700 script.sh zamiast chmod +x.

Metoda 2: Uruchomienie skryptu przy użyciu ścieżki względnej lub bezwzględnej

Po uczynieniu pliku wykonywalnym możesz uruchomić go bezpośrednio z terminala.

Używanie ścieżki względnej (bieżący katalog)

Jeśli skrypt znajduje się w bieżącym katalogu roboczym, poprzedź go znakiem ./:

./script.sh

Znak ./ mówi powłoce, aby szukała w bieżącym katalogu zamiast przeszukiwać system $PATH.

Używanie ścieżki bezwzględnej

Jeśli skrypt znajduje się w innej lokalizacji, podaj jego pełną ścieżkę:

/home/user/scripts/script.sh

lub

/usr/local/bin/script.sh

Używanie ścieżek bezwzględnych jest szczególnie ważne podczas uruchamiania skryptów z zadań cron lub innych zautomatyzowanych kontekstów, gdzie katalog roboczy może się różnić.

Metoda 3: Uruchomienie skryptu za pomocą bash lub sh (Nie wymagane uprawnienie do wykonania)

Możesz wywołać skrypt powłoki, jawnie wywołując interpreter, nawet jeśli plik nie ma uprawnień do wykonania. Jest to szczególnie przydatne do szybkiego testowania skryptu przed jego trwałym uczynieniem wykonywalnym.

bash script.sh

lub dla skryptów zgodnych z POSIX:

sh script.sh

Różnica między bash i sh

PolecenieInterpreterObsługuje funkcje specyficzne dla Bash
bash script.shGNU BashTak
sh script.shPOSIX sh (często dash na Ubuntu)Nie

Jeśli Twój skrypt używa składni specyficznej dla Bash, takiej jak tablice, [[ ]] warunki warunkowe, lub podstawianie procesów, zawsze używaj bash zamiast sh.

Metoda 4: Uruchomienie skryptu jako superużytkownik (sudo)

Niektóre skrypty wymagają uprawnień na poziomie root do modyfikacji plików systemowych, zarządzania usługami, instalacji pakietów lub zmiany konfiguracji sieci. Użyj sudo do podniesienia uprawnień:

sudo ./script.sh

lub przekaż skrypt bezpośrednio do bash z podwyższonymi prawami:

sudo bash script.sh

Ważne zagadnienia bezpieczeństwa

  • Nigdy nie uruchamiaj skryptu jako root bez wcześniejszego przeczytania go. Złośliwy lub źle napisany skrypt z dostępem sudo może spowodować nieodwracalne uszkodzenie systemu.
  • Preferuj uruchamianie skryptów z minimalnymi wymaganymi uprawnieniami.
  • Jeśli skrypt musi tylko pisać do określonego katalogu, rozważ dostosowanie uprawnień katalogu zamiast uruchamiania całego skryptu jako root.

Metoda 5: Uruchomienie skryptu w tle

Domyślnie uruchomienie skryptu w terminalu blokuje sesję do czasu zakończenia skryptu. W przypadku długotrwałych zadań — takich jak duże transfery plików, migracje baz danych lub budowanie serwerów — będziesz chciał wysłać proces do tła.

Używanie operatora &

./script.sh &

Symbol & rozwidla proces do tła i natychmiast zwraca kontrolę do terminala. Shell wypisuje PID (Process ID) zadania w tle, którego możesz użyć do monitorowania lub zakończenia go później.

Utrzymanie skryptu uruchomionego po wylogowaniu za pomocą nohup

Jeśli rozłączysz się z SSH, zadania w tle uruchomione za pomocą & zwykle się zakończą. Użyj nohup aby tego uniknąć:

nohup ./script.sh &

Dane wyjściowe są domyślnie przekierowywane do nohup.out. Aby określić niestandardowy plik dziennika:

nohup ./script.sh > /var/log/myscript.log 2>&1 &

Monitorowanie zadań w tle

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

Metoda 6: Planowanie wykonywania skryptów za pomocą Crona

W przypadku zadań powtarzających się — nocne kopie zapasowe, cotygodniowe czyszczenia, godzinowe kontrole zdrowotności — wbudowany scheduler cron Linuksa jest standardowym rozwiązaniem.

Otwórz edytor Crontab

crontab -e

Składnia Crona

* * * * * /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)

Praktyczne przykłady Crona

HarmonogramWyrażenie CronaPrzykład przypadku użycia
Każdego dnia o 2:00 AM0 2 * * *Nocna kopia zapasowa bazy danych
Każdy poniedziałek o 6:00 AM0 6 * * 1Cotygodniowa rotacja dzienników
Co godzinę0 * * * *Godzinowa kontrola dostępności
Co 15 minut*/15 * * * *Odświeżenie pamięci podręcznej
Przy ponownym uruchomieniu systemu@rebootUruchomienie usługi lub skryptu podczas rozruchu

Przykład: Zautomatyzowana codzienna kopia zapasowa

0 2 * * * /home/user/scripts/backup.sh >> /var/log/backup.log 2>&1

To uruchamia backup.sh każdego dnia o 2:00 AM i dołącza zarówno standardowe wyjście, jak i błędy do pliku dziennika w celu audytu.

> Porada profesjonalna: Zawsze używaj ścieżek bezwzględnych w wpisach crona. Cron działa w minimalnym środowisku i może nie mieć dostępu do tego samego $PATH co interaktywna powłoka.

Metoda 7: Sourcing skryptu (uruchomienie w kontekście bieżącej powłoki)

Istnieje jeszcze jedna metoda wykonywania warta poznania: sourcing skryptu. W przeciwieństwie do metod powyżej, sourcing uruchamia skrypt w ramach bieżącej sesji powłoki zamiast spawniować podpowłokę. Oznacza to, że wszelkie zmienne lub funkcje zdefiniowane w skrypcie pozostają w Twoim bieżącym środowisku.

source script.sh

lub równoważnie:

. script.sh

Jest to powszechnie używane do ładowania zmiennych środowiskowych, aktywowania wirtualnych środowisk lub stosowania zmian konfiguracji do bieżącej sesji.

Rozwiązywanie typowych błędów

Komunikat błęduPrawdopodobna przyczynaRozwiązanie
Permission deniedPlik nie ma uprawnień do wykonaniaUruchom chmod +x script.sh
No such file or directoryNieprawidłowa ścieżka lub brakujący plikSprawdź ścieżkę za pomocą ls i pwd
bad interpreter: No such file or directoryNieprawidłowa linia shebang (np. znaki końca linii Windows)Uruchom dos2unix script.sh aby naprawić znaki końca linii
command not foundSkrypt nie znajduje się w $PATH i brak prefiksu ./Użyj ./script.sh lub pełnej ścieżki bezwzględnej
syntax error near unexpected tokenSkrypt napisany dla bash ale uruchomiony z shUżyj bash script.sh jawnie

Najlepsze praktyki pisania i uruchamiania skryptów Shell

Postępowanie zgodnie z tymi praktykami sprawi, że Twoje skrypty będą bezpieczniejsze, łatwiejsze w utrzymaniu i debugowaniu — szczególnie w środowiskach serwerowych.

1. Zawsze zacznij od linii Shebang

Pierwsza linia każdego skryptu powinna deklarować interpreter:

#!/bin/bash

lub dla maksymalnej przenośności:

#!/usr/bin/env bash

2. Włącz tryb ścisły

Dodaj to w pobliżu górnej części każdego skryptu produkcyjnego:

set -euo pipefail
  • -e — Wyjdź natychmiast, jeśli jakiekolwiek polecenie się nie powiedzie
  • -u — Traktuj niezdefiniowane zmienne jako błędy
  • -o pipefail — Wyłap błędy w poleceniach potokowych

3. Przeczytaj skrypt przed jego uruchomieniem

Nigdy nie wykonuj pliku .sh z zewnętrznego lub niezaufanego źródła bez wcześniejszego przejrzenia jego zawartości:

cat script.sh

lub otwórz go w edytorze tekstu. Jest to szczególnie ważne podczas uruchamiania z sudo.

4. Używaj komentarzy obficie

#!/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. Organizuj skrypty w dedykowanych katalogach

KatalogRekomendowane użycie
/usr/local/bin/Skrypty dostępne dla całego systemu dla wszystkich użytkowników
~/scripts/ lub ~/bin/Osobiste skrypty użytkownika
/opt/scripts/Skrypty automatyzacji specyficzne dla aplikacji
/etc/cron.daily/Skrypty do uruchamiania codziennie przez cron

6. Rejestruj dane wyjściowe skryptu

Zawsze przekierowuj dane wyjściowe do pliku dziennika dla skryptów uruchamianych bez nadzoru:

./script.sh >> /var/log/script.log 2>&1

7. Najpierw przetestuj skrypty w bezpiecznym środowisku

Przed wdrożeniem skryptu na serwerze produkcyjnym przetestuj go w środowisku przejściowym lub na jednorazowej instancji VPS, gdzie błędy nie spowodują przestojów.

Uruchamianie skryptów Shell na serwerze Linux: Praktyczne zagadnienia

Podczas uruchamiania skryptów na zdalnym serwerze Linux — niezależnie od tego, czy jest to środowisko współdzielone czy dedykowana maszyna — wchodzi w grę kilka dodatkowych czynników:

  • Dostęp SSH: Większość skryptów po stronie serwera działa przez SSH. Narzędzia takie jak screen lub tmux pozwalają utrzymać trwałe sesje, dzięki czemu długotrwałe skrypty przetrwają rozłączenia.
  • Uprawnienia użytkownika: W środowiskach hostingu współdzielonego Twoja możliwość wykonywania skryptów może być ograniczona. VPS z cPanel daje Ci pełny dostęp root i pełną kontrolę nad wykonywaniem skryptów.
  • Automatyczne wdrażanie: Połącz skrypty shell z zadaniami cron, aby zautomatyzować wdrażanie, odnawianie certyfikatów (szczególnie przydatne w połączeniu z Certyfikatami SSL) i rutynowe zadania konserwacyjne.
  • Zmienne środowiskowe: Skrypty uruchamiane przez cron lub SSH mogą nie dziedziczyć środowiska interaktywnej powłoki. Zdefiniuj wszystkie niezbędne zmienne jawnie w skrypcie lub załaduj plik profilu.

Szybki przegląd: Wszystkie metody na pierwszy rzut oka

MetodaPoleceniePrzypadek użycia
Wykonaj z uprawnieniamichmod +x script.sh && ./script.shStandardowe wykonanie
Uruchom z bashbash script.shNie jest potrzebne uprawnienie do wykonania
Uruchom z shsh script.shSkrypty kompatybilne z POSIX
Uruchom jako rootsudo ./script.shSkrypty wymagające podwyższonych uprawnień
Uruchom w tle./script.sh &Wykonanie bez blokowania
Uruchom trwalenohup ./script.sh &Przetrwaj wylogowanie SSH
Zaplanuj za pomocą croncrontab -ePowtarzające się zadania zautomatyzowane
Źródło skryptusource script.shZastosuj zmiany do bieżącej powłoki

Podsumowanie

Uruchamianie .sh plików w Linux to podstawowa umiejętność, która odblokowuje pełną moc automatyzacji systemu. Podstawowy przepływ pracy jest prosty: przyznaj uprawnienia do wykonania za pomocą chmod +x, a następnie uruchom skrypt za pomocą ./script.sh lub bash script.sh. W środowiskach produkcyjnych połącz ścieżki bezwzględne, tryb ścisły, rejestrowanie i planowanie cron, aby zbudować niezawodne potoki automatyzacji.

Jeśli zarządzasz skryptami na serwerze, jakość infrastruktury hostingowej ma znaczenie. VPS Hosting i Serwery Dedykowane AlexHost dają Ci pełny dostęp root, stabilny czas pracy i wydajność potrzebną do pewnego uruchamiania obciążeń automatyzacji — niezależnie od tego, czy planujesz nocne kopie zapasowe, wdrażasz aplikacje, czy zarządzasz złożonymi przepływami pracy z wieloma skryptami.