Forum PHP.pl

Sprawa wygląda tak:
Codziennie o 2:00 na serwerach Windows odpala się skrypt, który wysyła do aplikacji php za pomocą wget-a logi z serwera. Wygląda to w skrócie tak:
wget --no-cache -O wgetlog.html --post-file=jakis_log.txt

Aplikacja służy do rejestrowania logów w bazie. Początek aplikacji wygląda tak:

[PHP] pobierz, plaintext 
$LINIE = file('php://input');
[PHP] pobierz, plaintext 

Później log jest szatkowany i obslugiwany. Chciałbym aby plik który przyjdzie do php://input był odkładany w katalogu z aplikacją (w celu jego późniejszego wysłania). Teraz wygląda to tak:

[PHP] pobierz, plaintext 
	$nazwa_pliku = "../logi/" .strtolower($serwer). "_eventlog_" .date("Y-m-d"). ".txt";
	if ($plik = fopen($nazwa_pliku, "w")) {
		if (is_writeable($nazwa_pliku)) {
			for ($zapisane = 0; $zapisane < sizeof($LINIE); $zapisane++) {
				fwrite($plik, $LINIE[$zapisane]); 
			}
		}
	}
	fclose($plik);	
[PHP] pobierz, plaintext 

To działa, ale wiem że ta metoda jest licha. Czy są jakieś funkcje które bezpośrednio zapiszą to co jest w php://input do pliku tekstowego? Znalazłem funkcję move_uploaded_file() ale jakoś to nie działa za bardzo. Przeryłem manulal php i moje wątpliwości nie zostały rozwiane. Ma ktoś jakiś pomysł?

Ten post edytował lorak110786 26.11.2009, 20:18:13

file_get_contents + file_put_contents

Nie wiem, czy o to chodziło ponieważ nie rozumiem pytania.

Niezupełnie. Chodzi mi o to czy da się jakoś zebrać plik ze strumienia php://include i od razu zapisać go w niezmienionej postaci na serwerze na którym jest aplikacja, bez używania funkcji fopen() i fwrite()

Takie zapisywanie w niezmienionej postaci polega właśnie na ręcznym zapisaniu treści we wskazanym miejscu. Powinno to być logiczne - żeby system Ci to zapisał, musisz mu powiedzieć:

1. Że ma zapisać.
2. Gdzie ma zapisać.
3. Co ma zapisać.

Czyli de facto zrobić fopen() + fwrite() lub ew. file_put_contents(). Jaka jeszcze miałaby być inna metoda, i co ważniejsze - po co? Standardowe wejście, jak sama nazwa wskazuje, jest strumieniem wejściowym, czyli przeznaczonym do odczytania przez aplikację. Od strony systemu operacyjnego jest to normalny deskryptor otwartego pliku, identyczny jak ten, który się robi przy otwieraniu pliku do odczytu, tyle że "tworzony" przez system operacyjny i skojarzony np. z wyjściem innej aplikacji, mówiąc obrazowo. Skoro jest to dokładnie to samo, nie może być traktowane w jakiś wyjątkowo specjalny sposób, gdyż inaczej wszystkie deskryptory: pliki, gniazda sieciowe itd. powinny mieć możliwość zrzucania czytanej zawartości do innego pliku, tylko tu rodzi się pytanie: po diabła ma się tym zajmować system operacyjny, skoro programista może sam to sobie zaimplementować bez problemu, gdy mu jest potrzebne?

Rozumiem, że tu nic nie znalazłeś