Geisterverzeichnisse

Computer: Software & Programmierung Perl & CGI
#1

hallo zusammen!
ich habe ein nerviges problem, zu dem mir nichts mehr einfällt:
ein (perl-)script, das verzeichnisse löscht, hat bei den ersten tests etwas gehakt und die betreffenden verzeichnisse nicht vollständig geleert/bzw. irgendwelche unsichtbaren zeichen hinterlassen, die ich nun nicht mehr auslesen kann.
resultat: ws_ftp(95LE unter win98se) zeigt keinerlei inhalt mehr an, weigert sich aber, die verzeichnisse zu löschen, weil sie nicht leer seien.
also habe ich versucht, mir ein script dafür zu schreiben. leider brachten die versuche via open/readdir oder auch chdir/glob nichts als internal server errors. server meines providers ist übrigens apache 1.3.27 (und error-logs habe ich leider momentan nicht im paket).
habs auch mal mit einer unix-option probiert- in dieser weise: „rmdir -Rf“ kennt apache natürlich nicht.
nun hoffe ich, dass vielleicht jemand einen tipp hat…

ratlose grüße
bernd

#2

habs auch mal mit einer unix-option probiert- in dieser weise:
„rmdir -Rf“ kennt apache natürlich nicht.
nun hoffe ich, dass vielleicht jemand einen tipp hat…

Versuch es mal mit dem perl „system“ Befehl, etwa so:
system („rmdir -Rf“);

siehe auch perldoc -f system

Klaus

#3

Sorry, muss natürlich system („rmdir -Rf /das/zu/loeschende/verzeichnis“); heissen, wobei ich mir über die Option „Rf“ nicht sicher bin :wink:
Da wären Unix Gurus gefragt.

Klaus

#4

spätes *hmpf*
moin klaus,
ich hatte den thread schon fast abgeschrieben und deinen sehr sinnvollen tipp leider etwas spät gesehen. aber auch damit bleibt mir das pech an den stiefeln- egal mit welcher syntax, das resultat ist immer wieder „internal server error“…
…da werd ich mal sehen, ob ich hier nicht irgendwo einen guru auftreiben kann :wink:

THX anyway
bernd

#5

ich hatte den thread schon fast abgeschrieben und deinen sehr
sinnvollen tipp leider etwas spät gesehen. aber auch damit
bleibt mir das pech an den stiefeln- egal mit welcher syntax,
das resultat ist immer wieder „internal server error“…

Das liigt aber wahrschenlich eher an dem fehlenden Content-Type oder den Script-Rechten. Was sagt denn das Error-Log des Indianers?

Gruß Klaus

#6

Hallo

soweit ich mich erinnnere kann man auch in ws-ftp Befehle eingeben
und ausführen lassen. Schreib da doch einfach dein rm -Rf rein.

Gruss Jan

#7

Hallo Bernd !

hallo zusammen!
ich habe ein nerviges problem, zu dem mir nichts mehr
einfällt:
ein (perl-)script, das verzeichnisse löscht, hat bei den
ersten tests etwas gehakt und die betreffenden verzeichnisse
nicht vollständig geleert/bzw. irgendwelche unsichtbaren
zeichen hinterlassen, die ich nun nicht mehr auslesen kann.
resultat: ws_ftp(95LE unter win98se) zeigt keinerlei inhalt
mehr an, weigert sich aber, die verzeichnisse zu löschen, weil
sie nicht leer seien.

Hast du dem wsftp beigebracht, auch versteckte Dateien anzuzeigen ? Leider kenne ich das Programm nicht, falls du irgendwo den Listbefehl eingeben musst, schreibe dort statt „ls -l“ ein „ls -la“ hinein.

also habe ich versucht, mir ein script dafür zu schreiben.
leider brachten die versuche via open/readdir oder auch
chdir/glob nichts als internal server errors. server meines
providers ist übrigens apache 1.3.27 (und error-logs habe ich
leider momentan nicht im paket).

Content-Type vergessen ?
use CGI::Carp ‚fatalsToBrowser‘ verwendet ?
Minimalversion:
#!/usr/bin/perl
print „Content-Type: text/plain\n\n“;
print ls -la;

Die ´ sind „Backticks“, Shift+Taste neben Backspace auf einer dt. Tastatur.
Übertragung im ASCII-Mode und chmod 755 nicht vergessen !

habs auch mal mit einer unix-option probiert- in dieser weise:
„rmdir -Rf“ kennt apache natürlich nicht.

rmdir hat diese Optionen auch nicht, und löscht nur leere Verzeichnisse.
rm -rf ist richtig, kann aber an den Berechtigungen scheitern, falls die Dateien per FTP erstellt wurden, aber per CGI gelöscht werden sollen. Andersrum geht es in der Regel auch nicht, per CGI erstellte Dateien lassen sich per ftp nicht löschen, sofern du im Script nicht gleich ein chmod 666 machst.

Alexander

#8

hallo klaus,
das mit den rechten wäre ja auch wieder schön (einfach) gewesen- habe gleich sicherheitshalber alles nochmal auf 777 gesetzt, das resultat war wieder das gleiche :frowning:
allerdings: content-types sagen mir in diesem zusammenhang gar nichts- an was dachtest du denn da?

ansonsten hier mal der schlichte code:

#!/usr/bin/perl -w

use CGI (‚param‘);
use CGI::Carp (‚fatalsToBrowser‘);
use strict;

my $input=param (‚ziel‘); #die pfadangabe

system („rm -rf $input“);

falls das hilft…

greetings
bernd

#9

hmm…
hallo alexander,

Hast du dem wsftp beigebracht, auch versteckte Dateien
anzuzeigen ?

tja: nicht wirklich- die hilfe verstehe ich in bei diesem punkt leider nicht. das sieht nochmal nach einem recherche-projekt aus…

Leider kenne ich das Programm nicht, falls du
irgendwo den Listbefehl eingeben musst, schreibe dort statt
„ls -l“ ein „ls -la“ hinein.

work in progress- s.o…

Content-Type vergessen ?
use CGI::Carp ‚fatalsToBrowser‘ verwendet ?
Minimalversion:
#!/usr/bin/perl
print „Content-Type: text/plain\n\n“;
print ls -la;

Die ´ sind „Backticks“, Shift+Taste neben Backspace auf einer
dt. Tastatur.

ich hoffe, das die rückfrage nicht allzu dumm ist: das ist für mich als unix-dau erstmal ein rätsel- wenn ich dieses script im betreffenden verzeichnis ausführe, kann mir wsftp hinterher evtl. vorhandene versteckte dateien anzeigen? (:expressionless:

Übertragung im ASCII-Mode und chmod 755 nicht vergessen !

logisch…

Berechtigungen scheitern, falls die Dateien per FTP erstellt
wurden, aber per CGI gelöscht werden sollen.

oops: tatsächlich? bin nämlich gerade dabei, mir nach und nach ein kleines redaktionstool zusammen zu schrauben, das mich von wsftp & co. unabhängig machen soll…

Andersrum geht es
in der Regel auch nicht, per CGI erstellte Dateien lassen sich
per ftp nicht löschen, sofern du im Script nicht gleich ein
chmod 666 machst.

danke für den tipp, werde mich nochmal gründlicher mit der rechtevergabe beschäftigen.

greetings
bernd

#10

Hallo Bernd,

wie ich vermutet habe: da fehlt die Ausgabe des Content-Type-Headers
(Korrektur eingeflickt s.u.):

Ein häufig vorkommendes Problem ist ein vergessener HTTP Header.
Bevor man irgendwelche Ausgaben vom Script an den Browser sendet, muss man diesem mitteilen, was ihn da erwartet.
Also, wenn die Ausgabe Text ist, dann sollte auch der entsprechende Header (text/html) gesendet werden. In diesem Fall sollte ein „Content-type: text/html\n\n“ vor jeder anderen Ausgabe gesendet werden.

ansonsten hier mal der schlichte code:

#!/usr/bin/perl -w

use CGI (‚param‘);
use CGI::Carp (‚fatalsToBrowser‘);
use strict;

print „Content-type: text/html\n\n“;

my $input=param (‚ziel‘); #die pfadangabe

my $rv = system („rm -rf $input“);

print "Verzeichnis gelöscht - Return Code: $rv
";

Gruß Klaus

#11

zu den rechten
hallo wieder,
erstmal sorry für den unsinn hier:

ich hoffe, das die rückfrage nicht allzu dumm ist: das ist für
mich als unix-dau erstmal ein rätsel- wenn ich dieses script
im betreffenden verzeichnis ausführe, kann mir wsftp hinterher
evtl. vorhandene versteckte dateien anzeigen? (:expressionless:

wenn der dau auch noch grippe hat…
…dauert es etwas länger, bis der groschen fällt.
habe dein script mal ausprobiert:

Minimalversion:
#!/usr/bin/perl
print „Content-Type: text/plain\n\n“;
print ls -la;

leider ist das resultat wie gehabt…

hierzu hätte ich allerdings noch eine frage:

Berechtigungen scheitern, falls die Dateien per FTP erstellt
wurden, aber per CGI gelöscht werden sollen.

das war hier genauso der fall: die (per ftp erstellten) dateien wurden vom script gelöscht, aber deren verzeichnisse nicht…?
(der sinn dieser einrichtung ist mir auch nicht so ganz deutlich)

beste grüße
bernd

#12

doch leider…
hallo klaus,
habe deine ergänzung übernommen und-
wieder das gleiche.
außerdem ist mir auch nicht so ganz klar, was die wiedergabe irgendwelcher meldungen im browser mit dem funktionieren des scriptes zu tun hat…

Bevor man irgendwelche Ausgaben vom Script an den Browser
sendet, muss man diesem mitteilen, was ihn da erwartet.

mir schon bekannt, nur wollte ich hier ursprünglich nichts an den browser ausgeben.
(resultat wie gesagt…)

greetings
bernd

#13

außerdem ist mir auch nicht so ganz klar, was die wiedergabe
irgendwelcher meldungen im browser mit dem funktionieren des
scriptes zu tun hat…

Apache will es halt so … (dass mit dem Content-Type) - soweit ich weiß auch wenn man nichts ausgeben will.

Trotzdem noch mal die Frage: Welche Meldung steht im Error-Log des Apache? So ist das Ganze nur ein Ratespiel für Glaskugelbesitzer …

Gruß Klaus

#14

hallo wieder,
erstmal sorry für den unsinn hier:

ich hoffe, das die rückfrage nicht allzu dumm ist: das ist für
mich als unix-dau erstmal ein rätsel- wenn ich dieses script
im betreffenden verzeichnis ausführe, kann mir wsftp hinterher
evtl. vorhandene versteckte dateien anzeigen? (:expressionless:

wenn der dau auch noch grippe hat…
…dauert es etwas länger, bis der groschen fällt.
habe dein script mal ausprobiert:

Minimalversion:
#!/usr/bin/perl
print „Content-Type: text/plain\n\n“;
print ls -la;

leider ist das resultat wie gehabt…

Evtl. geht Perl nur im cgi-bin, und du hast es in einem anderen Verzeichnis ausgeführt ? Ggfs. das gleiche mit PHP versuchen, oder nach dem ls -la das Verzeichnis angeben. Zum Anzeigen:
$f=opendir(".");while ($x=readdir($f)) echo „$x
\n“;closedir($f) ?>
Zum löschen in die while-Schleife ein unlink einbauen…

hierzu hätte ich allerdings noch eine frage:

Berechtigungen scheitern, falls die Dateien per FTP erstellt
wurden, aber per CGI gelöscht werden sollen.

das war hier genauso der fall: die (per ftp erstellten)
dateien wurden vom script gelöscht, aber deren verzeichnisse
nicht…?

Falls du die chmod 666 gesetzt hast, geht das natürlich. Sind die Verzeichnisse auf 755 statt 777, kann er die nicht löschen.

(der sinn dieser einrichtung ist mir auch nicht so ganz
deutlich)

Unter
http://www.alexander-fleischer.de/info/chmod.php
habe ich mal irgendwann was dazu geschrieben.

Alexander

#15

die kugel
tja-

Trotzdem noch mal die Frage: Welche Meldung steht im Error-Log
des Apache? So ist das Ganze nur ein Ratespiel für
Glaskugelbesitzer …

wie ich schon schrieb: dummerweise habe ich in diesem paket keinen zugriff auf solche…

*schulterzuck*
bernd

#16

wie ich schon schrieb: dummerweise habe ich in diesem paket
keinen zugriff auf solche…

Den Hinweis habe ich bisher nicht gelesen. Macht nix …
Ohne Error-log kommen wir offensichtlich nicht weiter.

Sorry, das es nichts wird …
Klaus