Gdy pojawia się pytanie, jak uruchomić skrypt linux, najpierw warto rozdzielić trzy rzeczy: sam plik, interpreter poleceń i uprawnienia do wykonania. W praktyce większość problemów nie wynika z „zepsutego” skryptu, tylko z błędnej ścieżki, braku bitu wykonywania albo z pliku przygotowanego w innym systemie.
Najbezpieczniej zaczynać od ręcznego uruchomienia w terminalu, bo wtedy od razu widać komunikat błędu i łatwo odróżnić problem z uprawnieniami od problemu ze składnią. Dopiero później ma sens przechodzenie do automatyzacji przez cron lub systemd.
Jak uruchomić skrypt linux za pomocą terminala – podstawowe metody
W terminalu masz dwie najprostsze drogi. Pierwsza to uruchomienie skryptu przez interpreter, na przykład bash skrypt.sh albo sh skrypt.sh. Druga to bezpośrednie wykonanie pliku, czyli ./skrypt.sh. Różnica jest ważna: w pierwszym wariancie sam interpreter czyta zawartość pliku, więc plik nie musi mieć ustawionego bitu wykonywania. W drugim wariancie system traktuje plik jak program i sprawdza, czy wolno go uruchomić.
To właśnie dlatego ./ ma znaczenie. Kropka oznacza bieżący katalog, a ukośnik mówi systemowi, że nie szuka programu w zmiennej PATH, tylko w miejscu, w którym aktualnie jesteś. Bez tego prefiksu shell zwykle nie uruchomi pliku z katalogu roboczego, nawet jeśli tam leży.
Warto też rozróżnić bash i sh. Jeśli skrypt używa funkcji typowych dla Bash, bezpieczniej wywołać go przez bash skrypt.sh. sh bywa bardziej „surowy” i może nie rozumieć części składni spotykanej w nowszych skryptach.
Rola nagłówka shebang w skryptach bash
Pierwsza linia pliku, czyli shebang, wygląda zwykle tak: #!/bin/bash albo #!/usr/bin/env bash. To wskazówka dla systemu, jakiego interpretera użyć, gdy uruchamiasz skrypt bezpośrednio. Kernel odczytuje tę linię przed wykonaniem treści pliku i na jej podstawie przekazuje go do właściwej powłoki.
Jeśli shebangu zabraknie, ./skrypt.sh może zakończyć się błędem typu Exec format error albo uruchomić się w sposób nieprzewidywalny zależnie od środowiska. Przy uruchamianiu przez bash skrypt.sh ten problem jest mniejszy, bo interpreter jest wskazany ręcznie, ale przy bezpośrednim wykonaniu shebang jest praktycznie obowiązkowy.
| Metoda | Wymaga chmod +x? | Używany interpreter | Kiedy to ma sens |
|---|---|---|---|
./skrypt.sh |
Tak | Zgodny z shebang | Gdy chcesz uruchamiać plik jak program |
bash skrypt.sh |
Nie | Bash | Gdy chcesz szybko testować skrypt |
sh skrypt.sh |
Nie | sh | Gdy skrypt jest prosty i zgodny z sh |
Nadawanie uprawnień do wykonywania skryptu – komenda chmod
Nowy plik tekstowy w Linuksie nie dostaje domyślnie prawa do wykonania, bo system rozdziela odczyt, zapis i uruchamianie. To dobre zabezpieczenie: nie każdy plik, który da się otworzyć, powinien dać się wykonać. Jeśli chcesz użyć ./skrypt.sh, nadaj plikowi bit wykonywania komendą chmod +x albo chmod a+x.
Najprościej zrobić to tak: chmod +x skrypt.sh. Potem uruchamiasz plik bezpośrednio: ./skrypt.sh. Jeśli nie chcesz zmieniać uprawnień, możesz zostać przy wywołaniu przez interpreter, na przykład bash skrypt.sh. To często wygodniejsze na etapie testów, bo jest odwracalne i nie wymaga ruszania praw pliku.
Nie warto zaczynać od sudo. Jeśli skrypt należy do Twojego konta i leży w prywatnym katalogu, chmod zwykle wystarczy. sudo ma sens dopiero wtedy, gdy rzeczywiście zapisujesz plik w miejscu chronionym lub uruchamiasz usługę systemową.
Uruchamianie skryptu z dowolnej lokalizacji – ścieżki i zmienna PATH
Jeśli skrypt działa tylko wtedy, gdy jesteś w jego katalogu, to zwykle problem nie leży w samym uruchomieniu, lecz w ścieżkach względnych. Taki skrypt może na przykład szukać pliku danych w bieżącym katalogu, a po uruchomieniu z innego miejsca nie znajduje go, bo bieżący katalog zmienia się razem z terminalem. Wtedy bezpieczniej używać ścieżek bezwzględnych albo oprzeć się na katalogu, w którym leży sam skrypt.
Żeby uruchamiać skrypt z dowolnego miejsca, możesz dodać własny katalog do zmiennej PATH. Wtedy wpisujesz samą nazwę pliku, a shell sam znajduje go w wybranym folderze. To wygodne przy własnych narzędziach, ale warto zachować porządek i trzymać tam tylko rzeczy, które faktycznie mają być uruchamiane jak programy.
- Umieść skrypt w stałym katalogu, na przykład
~/binlub~/skrypty. - Otwórz plik
~/.bashrcw edytorze tekstu. - Dodaj linię:
export PATH="$HOME/bin:$PATH"albo wskaż własny katalog. - Wczytaj zmiany poleceniem
source ~/.bashrc. - Upewnij się, że skrypt ma
chmod +x, a potem wywołaj go bez pełnej ścieżki.
Na marginesie: jeśli skrypt sam odwołuje się do plików konfiguracyjnych, nie opieraj się wyłącznie na PATH. Ta zmienna pomaga shellowi znaleźć program, ale nie naprawia błędów wewnątrz skryptu. Dobra praktyka to używanie pełnych ścieżek tam, gdzie ma to znaczenie, szczególnie przy kopiach zapasowych i prostych automatyzacjach.
Jak uruchomić skrypt w tle i po zamknięciu terminala
Do krótkich zadań wystarczy znak &, który przenosi proces do tła. To jednak nie oznacza pełnej niezależności od terminala. Jeśli zamkniesz okno lub rozłączysz sesję SSH, skrypt może zostać przerwany. Dlatego do dłuższych zadań lepiej użyć nohup, który ignoruje sygnał kończący sesję, albo narzędzia do pracy z sesjami, takie jak screen czy tmux.
nohup jest dobry, gdy chcesz po prostu wystartować proces i zapomnieć o terminalu. Natomiast screen i tmux są wygodniejsze, jeśli chcesz wrócić do tej samej sesji, sprawdzić wynik albo podejrzeć postęp. W praktyce do dłuższych skryptów administracyjnych to często rozsądniejszy wybór niż samo &.
Jeśli proces ma ważne logi, od początku zapisuj wyjście do pliku, na przykład przez przekierowanie standardowego wyjścia i błędów. Dzięki temu po zamknięciu terminala nadal masz ślad działania, a diagnoza problemu nie zaczyna się od zgadywania.
Automatyzacja zadań – uruchamianie skryptu za pomocą crona
Cron przydaje się wtedy, gdy skrypt ma działać cyklicznie: tworzyć kopię zapasową, pobierać dane albo wykonywać porządki o określonej porze. Konfigurację najczęściej robi się poleceniem crontab -e, które otwiera harmonogram użytkownika w edytorze tekstu.
Wpis crona składa się z pięciu pól czasowych: minuta, godzina, dzień miesiąca, miesiąc i dzień tygodnia. Dopiero po nich podajesz pełną ścieżkę do skryptu. To ważne, bo cron uruchamia zadania w innym środowisku niż Twoja interaktywna powłoka, więc nie ma pewności, że zna Twoje aliasy, katalog roboczy czy skróty.
Przykład uruchamiania skryptu co godzinę: 0 * * * * /home/uzytkownik/skrypty/backup.sh >> /home/uzytkownik/logi/backup.log 2>&1. Z kolei zadanie codzienne o północy wygląda tak: 0 0 * * * /home/uzytkownik/skrypty/backup.sh. Jeśli chcesz odpalać skrypt raz w tygodniu, możesz użyć na przykład 0 3 * * 1, czyli w poniedziałek o 03:00.
W cronach najlepiej od razu używać pełnych ścieżek i prostego logowania. To oszczędza czas, gdy zadanie nie startuje z powodu drobiazgu, takiego jak brak dostępu do pliku albo literówka w ścieżce. Właśnie na tym etapie widać, czy skrypt był wcześniej przetestowany ręcznie.
Uruchamianie skryptu linux przy starcie systemu
Do uruchamiania przy bootowaniu nowoczesne dystrybucje zwykle wykorzystują systemd. Zamiast dopisywać coś na siłę do starych mechanizmów, lepiej utworzyć prostą usługę w katalogu /etc/systemd/system/. To daje kontrolę nad logami, kolejnością startu i ponownym uruchamianiem przy błędzie.
[Unit]
Description=Start skryptu przy starcie systemu
After=network.target
[Service]
Type=simple
ExecStart=/home/uzytkownik/skrypty/start.sh
WorkingDirectory=/home/uzytkownik/skrypty
User=uzytkownik
Restart=on-failure
[Install]
WantedBy=multi-user.targetPo zapisaniu pliku usługi włącz ją i uruchom poleceniami sudo systemctl enable start-skryptu.service oraz sudo systemctl start start-skryptu.service. sudo jest tu potrzebne, bo konfigurujesz usługę systemową, a nie zwykły plik w swoim katalogu. To właśnie moment, w którym uprawnienia administratora mają sens.
Stare rozwiązanie rc.local bywa jeszcze spotykane, ale na nowoczesnych systemach lepiej go nie traktować jako pierwszego wyboru. systemd jest po prostu czytelniejszy i łatwiejszy do diagnozy, zwłaszcza gdy skrypt ma działać stale albo wymaga połączenia z innymi usługami.
Jak uruchomić skrypt bash na systemie Windows
Jeśli pracujesz na Windowsie, a skrypt ma działać jak na Linuksie, najpewniejszym rozwiązaniem jest WSL, czyli Windows Subsystem for Linux. Daje środowisko bardzo zbliżone do prawdziwego Linuksa, więc nadaje się nie tylko do jednorazowego testu, ale też do pracy z plikami, ścieżkami i typowymi narzędziami powłoki.
Git Bash bywa wystarczający do prostych skryptów, zwłaszcza jeśli chcesz tylko sprawdzić kilka poleceń lub krótką automatykę. Trzeba jednak pamiętać, że to nadal środowisko „pośrednie”, więc nie zawsze zachowuje się identycznie jak pełny Linux. Do poważniejszego testowania skryptu bash lepiej wybrać WSL.
Do szybkich, jednorazowych prób można też użyć edytorów lub interpreterów online, ale tylko wtedy, gdy skrypt nie zależy od lokalnych plików i nie wymaga dostępu do systemu. To dobre do sprawdzenia składni, nie do uruchamiania rzeczywistych zadań administracyjnych.
Rozwiązywanie problemu z formatem końca linii CRLF vs LF
Jednym z najczęstszych problemów przy przenoszeniu skryptu między Windows a Linux jest format końca linii. Windows zapisuje linie jako CRLF, a Linux zwykle oczekuje LF. Efekt? Możesz zobaczyć błędy typu /bin/bash^M: bad interpreter albo dziwne komunikaty składniowe mimo poprawnej treści skryptu.
Najszybsza naprawa to narzędzie dos2unix: dos2unix skrypt.sh. Jeśli nie masz go zainstalowanego, możesz też ustawić w edytorze zapis z końcówkami LF. Warto to zrobić od razu, zwłaszcza gdy skrypt ma trafić z Windowsa na serwer Linux lub do WSL.
Najczęstsze błędy podczas uruchamiania skryptów i jak je naprawić
- Permission denied — plik nie ma bitu wykonywania albo nie masz prawa do katalogu. Najpierw sprawdź
chmod +x skrypt.sh, a dopiero potem rozważsudo, jeśli plik leży w chronionym miejscu. - No such file or directory — zwykle zła ścieżka, literówka, brakujący plik obok skryptu albo problem z CRLF, który psuje interpreter zapisany w shebang.
- command not found — shell nie widzi interpretera lub programu pomocniczego. Sprawdź, czy dany pakiet jest zainstalowany i czy używasz pełnej ścieżki albo poprawnego
PATH. - /bin/bash^M: bad interpreter — plik ma końce linii CRLF. Przekonwertuj go przez
dos2unixlub zapisz ponownie jako LF. - Exec format error — brakuje shebangu albo plik nie jest prawidłowym skryptem wykonywalnym. Dodaj pierwszą linię z interpreterem i uruchom go ponownie.
Jeśli chcesz szybko zawęzić przyczynę, zacznij od najprostszej próby: bash skrypt.sh. Gdy to działa, problem leży zwykle w uprawnieniach, shebangu albo ścieżce uruchomienia. Gdy nie działa, winny może być sam skrypt, brakujący program lub format pliku. Taka kolejność oszczędza czas i pozwala diagnozować bez zgadywania.
W praktyce najpewniejsza ścieżka jest prosta: najpierw uruchom skrypt ręcznie, potem nadaj mu chmod +x, następnie uporządkuj ścieżki, a dopiero na końcu przechodź do cron albo systemd. Taki porządek zmniejsza ryzyko błędów i daje realną kontrolę nad tym, co się dzieje. Jeśli chcesz, by skrypt działał stabilnie na Linuksie i na Windowsie, trzymaj się pełnych ścieżek, właściwego interpretera i zapisu LF.