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.shAby sprawdzić, czy uprawnienia zostały zastosowane poprawnie:
ls -l script.shPowinieneś zobaczyć dane wyjściowe podobne do:
-rwxr-xr-x 1 user user 1024 Jun 10 14:32 script.shFlagi 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.shZnak ./ 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.shlub
/usr/local/bin/script.shUż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.shlub dla skryptów zgodnych z POSIX:
sh script.shRóżnica między bash i sh
| Polecenie | Interpreter | Obsługuje funkcje specyficzne dla Bash |
|---|---|---|
bash script.sh | GNU Bash | Tak |
sh script.sh | POSIX 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.shlub przekaż skrypt bezpośrednio do bash z podwyższonymi prawami:
sudo bash script.shWaż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 processMetoda 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 -eSkł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
| Harmonogram | Wyrażenie Crona | Przykład przypadku użycia |
|---|---|---|
| Każdego dnia o 2:00 AM | 0 2 * * * | Nocna kopia zapasowa bazy danych |
| Każdy poniedziałek o 6:00 AM | 0 6 * * 1 | Cotygodniowa 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 | @reboot | Uruchomienie usługi lub skryptu podczas rozruchu |
Przykład: Zautomatyzowana codzienna kopia zapasowa
0 2 * * * /home/user/scripts/backup.sh >> /var/log/backup.log 2>&1To 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.shlub równoważnie:
. script.shJest 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łędu | Prawdopodobna przyczyna | Rozwiązanie |
|---|---|---|
Permission denied | Plik nie ma uprawnień do wykonania | Uruchom chmod +x script.sh |
No such file or directory | Nieprawidłowa ścieżka lub brakujący plik | Sprawdź ścieżkę za pomocą ls i pwd |
bad interpreter: No such file or directory | Nieprawidłowa linia shebang (np. znaki końca linii Windows) | Uruchom dos2unix script.sh aby naprawić znaki końca linii |
command not found | Skrypt nie znajduje się w $PATH i brak prefiksu ./ | Użyj ./script.sh lub pełnej ścieżki bezwzględnej |
syntax error near unexpected token | Skrypt napisany dla bash ale uruchomiony z sh | Uż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/bashlub dla maksymalnej przenośności:
#!/usr/bin/env bash2. 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.shlub 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
| Katalog | Rekomendowane 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>&17. 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
screenlubtmuxpozwalają 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
| Metoda | Polecenie | Przypadek użycia |
|---|---|---|
| Wykonaj z uprawnieniami | chmod +x script.sh && ./script.sh | Standardowe wykonanie |
| Uruchom z bash | bash script.sh | Nie jest potrzebne uprawnienie do wykonania |
| Uruchom z sh | sh script.sh | Skrypty kompatybilne z POSIX |
| Uruchom jako root | sudo ./script.sh | Skrypty wymagające podwyższonych uprawnień |
| Uruchom w tle | ./script.sh & | Wykonanie bez blokowania |
| Uruchom trwale | nohup ./script.sh & | Przetrwaj wylogowanie SSH |
| Zaplanuj za pomocą cron | crontab -e | Powtarzające się zadania zautomatyzowane |
| Źródło skryptu | source script.sh | Zastosuj 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.
na wszystkich usługach hostingowych