Raz utworzyłem jakiś prosty plik sh (skrypt shella) pod linuxem, który utworzył kilka jakiś plików, które miał obrobić jakiś skrypt napisany w PHP. Załóżmy, że plik sh miał taką zawartość:
#!bin/bash
ls -l >1.txt
ls -l >2.txt
..coś tam jeszcze
No a skrypt w PHP miał za zadanie odczytać pliki 1.txt i 2.txt. Ale za "cholerę" ich nie chciał czytać. Błędów skrypcie na 100% nie było, pliki te były w tym samym katalogu co skrypt. Mało tego, wszedłem na serwer FTP i nie mogłem skasować tych plików za pomocą Total Commandera (mogłem skasować tylko za pomocą jakiegoś WebFTP'a). Postanowiłem utworzyć plik tar.gz, wrzucić go na dysk. No i winrar, który nie raz mi rozpakowywał pliki tar.gz tym razem odmówił posłuszeństwa! Nie mówił, że archiwum jest uszkodzone, ładnie widział jakie pliki wchodzą w skład archiwum, ale nie chciał ich rozpakować!
Zastanawiasz się, co było przyczyną problemu? Odpowiedź jest zaskakująca: plik sh napisałem pod Windowsem w programie EditPad. Pod windowsem koniec wiersza oznacza się symbolami CR LF (kod ASCII 13 i kod ASCII 10). Pod linuxem natomiast koniec wiersza oznacza się tylko symbolem LF (kod ASCII 10). Shell uznał, że nie tworzę pliku o nazwie 1.txt tylko 1.txtCR (CR to kod ASCII 13). Skrypt w PHP odwoływał się do pliku 1.txt a nie 1.txtCR, więc nie dziwne, że wystąpił błąd. A TotalCommander i WinRAR to programy windowsowe, pod windowsem pliki w nazwie nie mogą mieć kodu ASCII 13 i po prostu dla tych programów plik miał tak nietypową nazwę, że nie mogły go "obsłużyć".
Rozwiązanie problemu było proste: musiałem zadbać, aby pliki sh które tworzę miały koniec wiersza LF a nie tak jak to pod windowsem bywa CR LF. EditPad ma opcję zapisywania plików tekstowych w formacie Linuxowym, wystarczy z menu Convert wybrać opcję To Linux i od teraz już zawsze ten plik będzie miał entery zapisywane w postaci kodu ASCII 10 (LF). Jak ponownie otworzysz ten plik w programie EditPad to on sam zorientuje się, że koniec wiersza to kod ASCII 10 i nie trzeba już będzie pamiętać o konwersji.
#!bin/bash
ls -l >1.txt
ls -l >2.txt
..coś tam jeszcze
No a skrypt w PHP miał za zadanie odczytać pliki 1.txt i 2.txt. Ale za "cholerę" ich nie chciał czytać. Błędów skrypcie na 100% nie było, pliki te były w tym samym katalogu co skrypt. Mało tego, wszedłem na serwer FTP i nie mogłem skasować tych plików za pomocą Total Commandera (mogłem skasować tylko za pomocą jakiegoś WebFTP'a). Postanowiłem utworzyć plik tar.gz, wrzucić go na dysk. No i winrar, który nie raz mi rozpakowywał pliki tar.gz tym razem odmówił posłuszeństwa! Nie mówił, że archiwum jest uszkodzone, ładnie widział jakie pliki wchodzą w skład archiwum, ale nie chciał ich rozpakować!
Zastanawiasz się, co było przyczyną problemu? Odpowiedź jest zaskakująca: plik sh napisałem pod Windowsem w programie EditPad. Pod windowsem koniec wiersza oznacza się symbolami CR LF (kod ASCII 13 i kod ASCII 10). Pod linuxem natomiast koniec wiersza oznacza się tylko symbolem LF (kod ASCII 10). Shell uznał, że nie tworzę pliku o nazwie 1.txt tylko 1.txtCR (CR to kod ASCII 13). Skrypt w PHP odwoływał się do pliku 1.txt a nie 1.txtCR, więc nie dziwne, że wystąpił błąd. A TotalCommander i WinRAR to programy windowsowe, pod windowsem pliki w nazwie nie mogą mieć kodu ASCII 13 i po prostu dla tych programów plik miał tak nietypową nazwę, że nie mogły go "obsłużyć".
Rozwiązanie problemu było proste: musiałem zadbać, aby pliki sh które tworzę miały koniec wiersza LF a nie tak jak to pod windowsem bywa CR LF. EditPad ma opcję zapisywania plików tekstowych w formacie Linuxowym, wystarczy z menu Convert wybrać opcję To Linux i od teraz już zawsze ten plik będzie miał entery zapisywane w postaci kodu ASCII 10 (LF). Jak ponownie otworzysz ten plik w programie EditPad to on sam zorientuje się, że koniec wiersza to kod ASCII 10 i nie trzeba już będzie pamiętać o konwersji.
Licencja: Creative Commons
