ich möchte ein Verzeichnis löschen:


rmdir('C:/xampp/htdocs/test/1');

Wenn das Verzeichnis leer ist, klappt es . Wenn es voll ist kommt die
Fehlermeldung:

Warning: rmdir(C:/xampp/htdocs/test/1) [function.rmdir]: Directory not empty
in C:\xampp\htdocs\test\verzeichnis_del.php on line 3

Wie kann ich diese Fehlermeldung abfangen und statt desen eine eigene
Fehlemeldung ausgeben w.z.b.

Das Verzeichnis ist nicht leer, bitte erst die einzelnen Daten löschen!


Melanie

In article <fe20r7$9q7$01$1 [at] news.t-online.com> "Melanie
Gross"<megroxx2 [at] gmx.de> wrote:
> Wie kann ich diese Fehlermeldung abfangen und statt desen eine
> eigene Fehlemeldung ausgeben

Indem du vorher nachschaust, ob es leer ist, und dann entsprechend
aufden Status reagierst.


Gruß,
Habbo


--

I'm trying a new usenet client for Mac, Nemo OS X.
You can download it at http://www.malcom-mac.com/nemo

Melanie Gross schrieb:

> rmdir('C:/xampp/htdocs/test/1');
>
> Wenn das Verzeichnis leer ist, klappt es . Wenn es voll ist kommt die
> Fehlermeldung:
>
> Warning: rmdir(C:/xampp/htdocs/test/1) [function.rmdir]: Directory not empty
> in C:\xampp\htdocs\test\verzeichnis_del.php on line 3
>
> Wie kann ich diese Fehlermeldung abfangen und statt desen eine eigene
> Fehlemeldung ausgeben w.z.b.

Fehlermeldungen von Funktionen unterdrückt man durch den [at] -Operator, und
rmdir() liefert einen Rückgabewert:

if (! [at] rmdir(...)) ...

Genaueres steht im Handbuch.

Gruß. Claus

Claus Reibenstein wrote:

> Fehlermeldungen von Funktionen unterdrückt man durch den [at] -Operator, und
> rmdir() liefert einen Rückgabewert:
>
> if (! [at] rmdir(...)) ...

Gib doch nicht solche Tips Claus! Es gibt immer einen besseren Weg als
sture Fehlerunterdrückung, der bereits im anderen Posting geschildert
wurde. Für den OP ist jetzt klar das [at] der bessere Weg ist da einfacher
zu handlen. Das das nicht so ist weist Du ja eigentlich selbst.
(solltest Du zumindest)

MfG, Ulf

--
_,
_(_p> Ulf [Kado] Kadner
\<_)
^^

Ulf Kadner schrieb:
> Gib doch nicht solche Tips Claus! Es gibt immer einen besseren Weg als
> sture Fehlerunterdrückung, der bereits im anderen Posting geschildert
> wurde. Für den OP ist jetzt klar das [at] der bessere Weg ist da einfacher
> zu handlen. Das das nicht so ist weist Du ja eigentlich selbst.
> (solltest Du zumindest)

[at] (unterdrücken) = Quick & Dirty
vorher überprüfen = sauber

Bisher, und darauf bestehe ich auch weiterhin, habe ich noch nie nen [at]
gebraucht und man kommt auch sehr gut ohne aus. Es gibt ja für jeden
Fehlerfall im PHP auch eine Möglichkeit diesen vorher zu überprüfen.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Ulf Kadner schrieb:

> Claus Reibenstein wrote:
>
>> Fehlermeldungen von Funktionen unterdrückt man durch den [at] -Operator, und
>> rmdir() liefert einen Rückgabewert:
>>
>> if (! [at] rmdir(...)) ...
>
> Gib doch nicht solche Tips Claus! Es gibt immer einen besseren Weg als
> sture Fehlerunterdrückung, der bereits im anderen Posting geschildert
> wurde. Für den OP ist jetzt klar das [at] der bessere Weg ist da einfacher
> zu handlen. Das das nicht so ist weist Du ja eigentlich selbst.
> (solltest Du zumindest)

Aus dem Original-Posting: "Wie kann ich diese Fehlermeldung abfangen".
Die Frage zielte nicht darauf, den Fehler zu vermeiden.

Wenn sich ein Verzeichnis nicht löschen lässt, dann das viele Ursachen
haben. Die willst Du vorher alle prüfen? Viel Spaß.

Gruß. Claus

Christoph Herrmann schrieb:

> [at] (unterdrücken) = Quick & Dirty
> vorher überprüfen = sauber

Dann überprüfe doch mal vorher, ob sich ein Verzeichnis löschen lässt.
Mal schauen, welche Fälle Du dabei alle übersiehst.

Vorher überprüfen _und_ [at] benutzen, _das_ ist sauber.

> Bisher, und darauf bestehe ich auch weiterhin, habe ich noch nie nen [at]
> gebraucht und man kommt auch sehr gut ohne aus. Es gibt ja für jeden
> Fehlerfall im PHP auch eine Möglichkeit diesen vorher zu überprüfen.

Erstens gibt es nicht für _jeden_ Fehlerfall eine Möglichkeit, diesen
vorher zu erkennen. Ein Fehler kann auch von Umständen verursacht
werden, die außerhalb der Programmkontrolle liegen.

Zweitens ist es bisweilen sehr aufwendig, alle möglichen Fehlerfälle zu
berücksichtigen.

Drittens sind die systemeigenen Fehlermeldungen prímär für die
Programmentwicklung bestimmt und verraten bisweilen sensible Details,
die in einer Produktivumgebung niemals das Licht der Userwelt erreichen
sollten.

Außerdem zielte die Frage des Ursprungspostings darauf ab, die
Fehlermeldung abzufangen, und nicht, den Fehler zu vermeiden.

Gruß. Claus

Claus Reibenstein schrieb:
> Dann überprüfe doch mal vorher, ob sich ein Verzeichnis löschen lässt.
> Mal schauen, welche Fälle Du dabei alle übersiehst.
>
> Vorher überprüfen _und_ [at] benutzen, _das_ ist sauber.

bin ich anderer Meinung. Lieber versuchen alle Fehlerfälle zu überprüfen
und richtig per Exception oder ähnliches abzufangen und vielleicht einen
vergessen (den man nachträglich hinzufügen kann) als diese einfach zu
unterdrücken. Was bringt dir denn die Meldung, dass es nicht ging, wenn
danach keiner weiß warum.

Das [at] heißt einfach "es ist mir egal was da passiert ist, ich will keine
Fehlermeldungen" und das ist _immer_ Quick & Dirty. Ob das nun gut oder
schlecht ist, muss jeder für sich entscheiden. Sicher mag für manche
diese Möglichkeit reichen, was aber noch lange nicht bedeutet, dass
diese sauber ist.

Ich bin nicht generell gegen diese Möglichkeit, allerdings sollte man
sich bewusst sein was man tut und dass es auch saubere Möglichkeiten
gibt, die halt aber etwas aufwendiger sind.

> Erstens gibt es nicht für _jeden_ Fehlerfall eine Möglichkeit, diesen
> vorher zu erkennen. Ein Fehler kann auch von Umständen verursacht
> werden, die außerhalb der Programmkontrolle liegen.

Mir ist noch nichts unter die Augen getreten, was nicht abzufangen wäre.

> Zweitens ist es bisweilen sehr aufwendig, alle möglichen Fehlerfälle zu
> berücksichtigen.

Ja und? Wenn man es gleich richtig macht, muss man die Arbeit nur einmal
machen (Stichwort Klasse oder Funktion daraus machen, die entsprechend
Fehlerfälle abdeckt und per Exception reagiert).

> Drittens sind die systemeigenen Fehlermeldungen prímär für die
> Programmentwicklung bestimmt und verraten bisweilen sensible Details,
> die in einer Produktivumgebung niemals das Licht der Userwelt erreichen
> sollten.

Birnen sind auch das gleiche wie Äpfeln. Was hat das Fehlerunterdrücken
mit dem zu tun ob die Fehlermeldungen am Benutzer landen?

Sauber heißt für mich in dem Falle in der Entwicklung die Fehler
anzeigen und im Produktivsystem diese per display_errors /
set_error_handler für den Benutzer unsichtbar machen und loggen um Sie
später nachvollziehen und beheben zu können.

> Außerdem zielte die Frage des Ursprungspostings darauf ab, die
> Fehlermeldung abzufangen, und nicht, den Fehler zu vermeiden.

Also, Abfangen im Sinne von vorher überprüfen. Unterdrücken ist bestimmt
nicht das selbe wie abfangen.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Claus Reibenstein schrieb:

> Erstens gibt es nicht für _jeden_ Fehlerfall eine Möglichkeit, dies=
en
> vorher zu erkennen. Ein Fehler kann auch von Umständen verursacht
> werden, die außerhalb der Programmkontrolle liegen.

Genau *deshalb* ist [at] generell zu vermeiden.

> Zweitens ist es bisweilen sehr aufwendig, alle möglichen Fehlerfäll=
e zu
> berücksichtigen.

Eben.

> Drittens sind die systemeigenen Fehlermeldungen pr=EDmär für die
> Programmentwicklung bestimmt und verraten bisweilen sensible Details,
> die in einer Produktivumgebung niemals das Licht der Userwelt erreichen=

> sollten.

Dafür steht display_errors auf Produktivmaschinen auf off.

MfG
Niels

--
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Christoph Herrmann schrieb:

> Das [at] heißt einfach "es ist mir egal was da passiert ist, ich will ke=
ine
> Fehlermeldungen" und das ist _immer_ Quick & Dirty.

*Fast* immer, ja. Es gibt begrenzte Fälle (Zuweisungen), an denen genau=

bekannt ist, welche Meldungen unterdrückt werden, weil niemals andere
auftauchen. Dort kann das [at] die Eleganz und Lesbarkeit steigern.
Beispiel:

$words =3D explode( ' ', $text );
$cnt =3D array();
foreach ( $words as $word ) {
[at] $cnt[$word]++;
}

MfG
Niels

--
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Niels Braczek schrieb:
> *Fast* immer, ja. Es gibt begrenzte Fälle (Zuweisungen), an denen genau
> bekannt ist, welche Meldungen unterdrückt werden, weil niemals andere
> auftauchen. Dort kann das [at] die Eleganz und Lesbarkeit steigern.
> Beispiel:
>
> $words = explode( ' ', $text );
> $cnt = array();
> foreach ( $words as $word ) {
> [at] $cnt[$word]++;
> }

$words = explode( ' ', $text );
$cnt = array();
foreach ( $words as $word ) {
if(isset($cnt[$word]) == false) {
$cnt[$word] = 0;
}
$cnt[$word]++;
}

wenn die Meldung genau bekannt ist, kann man diese auch abprüfen. Nur
weil PHP unsauberes Vorgehen an dieser Stelle erlauben würde heißt es
nicht, dass es auch sinnvoll ist es so zu machen. Klar kommt es auf das
selbe heraus, aber es soll keiner sagen, dass hier das Unterdrücken der
Fehlermeldung ein sauberer weg ist.

Was lesbarer ist, ist relativ. Ich wüsste nicht, was an der Lösung
schlechter zu lesen wäre.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann schrieb:
> Niels Braczek schrieb:

>> *Fast* immer, ja. Es gibt begrenzte Fälle (Zuweisungen), an denen ge=
nau
>> bekannt ist, welche Meldungen unterdrückt werden, weil niemals ander=
e
>> auftauchen. Dort kann das [at] die Eleganz und Lesbarkeit steigern.
>> Beispiel:
>>
>> $words =3D explode( ' ', $text );
>> $cnt =3D array();
>> foreach ( $words as $word ) {
>> [at] $cnt[$word]++;
>> }
>
> $words =3D explode( ' ', $text );
> $cnt =3D array();
> foreach ( $words as $word ) {
> if(isset($cnt[$word]) =3D=3D false) {
> $cnt[$word] =3D 0;
> }
> $cnt[$word]++;
> }

> wenn die Meldung genau bekannt ist, kann man diese auch abprüfen. Nur=

> weil PHP unsauberes Vorgehen an dieser Stelle erlauben würde heißt =
es
> nicht, dass es auch sinnvoll ist es so zu machen. Klar kommt es auf das=

> selbe heraus, aber es soll keiner sagen, dass hier das Unterdrücken d=
er
> Fehlermeldung ein sauberer weg ist.

Sag' ich aber. In *diesem* Falle sehe ich darin sehr wohl eine saubere
Lösung. YMMV.

MfG
Niels

--
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Melanie Gross schrieb:
> ich möchte ein Verzeichnis löschen:
>
>
> rmdir('C:/xampp/htdocs/test/1');

Viel schneller und komfortabler ist es, das Betriebssystem zu bitten, so
etwas zu erledigen:

exec ('rd /s /q C:/xampp/htdocs/test/1 2>&1');

Nach diesem Befehl existiert Verzeichnis '1' nicht mehr. Obacht: Du wirst es
auch nicht im Papierkorb finden. Das '2>&1' fängt die Fehlermeldung ab, wenn
das Verzeichnis '1' noch gar nicht existiert.

viele grüße
ralph

Ralph 'rkhb' Bauer schrieb:
> exec ('rd /s /q C:/xampp/htdocs/test/1 2>&1');

Korrektur:

exec ('rd /s /q C:\\xampp\\htdocs\\test\\1 2>&1');

Auf den doppelten Backslash achten!

viele grüße
ralph

Claus Reibenstein wrote:

> Aus dem Original-Posting: "Wie kann ich diese Fehlermeldung abfangen".
> Die Frage zielte nicht darauf, den Fehler zu vermeiden.

Da Du weist das hier Leute fragen die zu 90% nicht viel Ahnung von PHP
haben ist es immer gut bei solch Kritischen Sachen was zu evtl.
Problemen und Alternativen dazu zu schreiben. Schließlich willst Du doch
auch das der Fragende nicht erst sinnfrei überall nen [at] davor schmeißt.
(Ja das passiert offensichtlich zur Genüge wenn man sich mal so die
Scripte in freier Wildbahn so anschaut) Was ihn letzendlich mit hoher
Wahrscheinlichkeit irgendwann wieder in der Gruppe aufschlagen läßt.

> Wenn sich ein Verzeichnis nicht löschen lässt, dann das viele Ursachen
> haben. Die willst Du vorher alle prüfen?

Die meist anzutreffenden können problemlos geprüft werden. Wenn man das
alles sinnvoll in ein Objekt oder ne Funktion verpackt schreibt man
sowas einmal und dann nie wieder. Wo ist also ein Problem?

MfG, Ulf

--
_,
_(_p> Ulf [Kado] Kadner
\<_)
^^

Christoph Herrmann wrote:

> [at] (unterdrücken) = Quick & Dirty
> vorher überprüfen = sauber

Es gibt schon nen paar einzelne Fälle wo man die Verwendung von [at] als zu
bevorzugende Technik einsetzen sollte aber die Paar Spezialfälle machen
halt das oft grob fahrlässig genutzte [at] nicht unbedingt nutzenwert.

> Bisher, und darauf bestehe ich auch weiterhin, habe ich noch nie nen [at]
> gebraucht und man kommt auch sehr gut ohne aus.

Wenn man bedenkt das Ausnahmen, die im Context eines eigenen
error_handlers ausgelöst werden in Quellcontext des Problems ebenfalls
bereitstehen könnte man auch fast die meinung vertreten das das [at] ganz
überflüssig in PHP5 ist. Aber dazu gehört halt wirklich recht viel Code
in den oder die Errorhandler. Das ist mir dann doch zuviel Aufwand. Da
nutze ich lieber bei manchen Dingen [at] arbeite mit $php_errormsg
(track_errors=On) oder wenns offensichlich ist mit eigenen Meldungen und
je nach Notwendigkeit aktivierten display_errors.

MfG, Ulf

--
_,
_(_p> Ulf [Kado] Kadner
\<_)
^^

Ralph 'rkhb' Bauer schrieb:

> Melanie Gross schrieb:
>
>> rmdir('C:/xampp/htdocs/test/1');
>
> Viel schneller und komfortabler ist es, das Betriebssystem zu bitten, so
> etwas zu erledigen:
>
> exec ('rd /s /q C:/xampp/htdocs/test/1 2>&1');

Sorry, aber ein externes Programm zu starten, nur um ein leeres
Verzeichnis zu löschen, obwohl es dafür direkt eine Funktion in PHP
gibt, ist schlicht Quatsch. Und dann auch noch zu behaupten, das sei
schneller, ist einfach nur lächerlich.

Der Start eines externen Programms ist eine ziemlich zeitintensive
Angelegenheit, besonders im Vergleich zum Aufruf einer lokalen Funktion,
die exakt das gleiche macht wie dieses Programm.

Außerdem ist Dein Befehl falsch. Er löscht nicht nur leere Verzeichnisse.

> Das '2>&1' fängt die Fehlermeldung ab

"'2>&1' fängt" gar nichts "ab", sondern leitet lediglich die
Standard-Fehlerausgabe auf die Standard-Ausgabe um.

Gruß. Claus

Ralph 'rkhb' Bauer schrieb:

> exec ('rd /s /q C:/xampp/htdocs/test/1 2>&1');

Noch etwas: Dies ist nicht portabel. Unter Linux wird ein Script, das
solche Aufrufe enthält, nicht mehr funktionieren. Schon deshalb sollte
man so etwas nur dann machen, wenn es unbedingt erforderlich ist.

Gruß. Claus

On Thu, 4 Oct 2007 08:32:03 +0200, Jan Habbo Brüning wrote:

> In article <fe20r7$9q7$01$1 [at] news.t-online.com> "Melanie
> Gross"<megroxx2 [at] gmx.de> wrote:
>> Wie kann ich diese Fehlermeldung abfangen und statt desen eine
>> eigene Fehlemeldung ausgeben
>
> Indem du vorher nachschaust, ob es leer ist, und dann entsprechend
> aufden Status reagierst.

Und was ist mit race conditions?

Gruß,
Matthias

Claus Reibenstein schrieb:
> Ralph 'rkhb' Bauer schrieb:
>
>> Melanie Gross schrieb:
>>
>>> rmdir('C:/xampp/htdocs/test/1');
>>
>> Viel schneller und komfortabler ist es, das Betriebssystem zu bitten, so
>> etwas zu erledigen:
>>
>> exec ('rd /s /q C:/xampp/htdocs/test/1 2>&1');
>
> Sorry, aber ein externes Programm zu starten, nur um ein leeres
> Verzeichnis zu löschen, obwohl es dafür direkt eine Funktion in PHP
> gibt, ist schlicht Quatsch. Und dann auch noch zu behaupten, das sei
> schneller, ist einfach nur lächerlich.

Habe ich Dir irgend etwas angetan, um diese Gossensprache zu verdienen?

ad 1) Der Sonderfall "leeres Verzeichnis" ist immer wieder der Stolperstein
bei rmdir. Normalerweise löscht man ein volles Verzeichnis oder noch
komplizierter: einen unbekannt tief verschachtelten Verzeichnisbaum - und
will sich überhaupt nicht darum kümmern, was darin ist.

ad 2) Ich habe hier ein CLI-Skript, das einen Verzeichnisbaum mit etwa 6000
Dateien zu löschen hat. Was meinst Du, was schneller ist?

> Der Start eines externen Programms ist eine ziemlich zeitintensive
> Angelegenheit, besonders im Vergleich zum Aufruf einer lokalen Funktion,
> die exakt das gleiche macht wie dieses Programm.

Wie Du später richtig erkannt hast, stimmt das nicht. Mein Shell-Befehl
steigt bei nicht-leerem Verzeichnis nicht aus. Der Zeitaufwand lässt sich
nachprüfen:

<?php
mkdir ('V1');
mkdir ('V2');

$start = microtime(true);
exec ('rd /s /q V2 2>&1');
printf ("%s - Dauer: %f Sekunden\n",'rd',microtime(true)-$start);

$start = microtime(true);
rmdir ('V1');
printf ("%s - Dauer: %f Sekunden\n",'rmdir',microtime(true)-$start);
?>

Ich bekomme auf meiner alten Kiste dabei folgende Ausgabe:

rd - Dauer: 0.061937 Sekunden
rmdir - Dauer: 0.000488 Sekunden

Da mir 60 Millisekunden nicht allzu zeitintensiv erscheinen, habe ich eine
Auslagerung von cmd.exe auf ein virtuelles Laufwerk nicht ausprobiert.
Lassen wir aber 500 leere Dateien in dem Verzeichnis sein:

<?php
$a = 500;
mkdir ('V1');
for ($i=0; $i<$a;$i++) touch ('V1/T'.$i);
mkdir ('V2');
for ($i=0; $i<$a;$i++) touch ('V2/T'.$i);

$start = microtime(true);
exec ('rd /s /q V1 2>&1');
printf ("%s - Dauer: %f Sekunden\n",'rd',microtime(true)-$start);

$start = microtime(true);
foreach (glob("V2/*") as $fn) unlink ($fn);
rmdir ('V2');
printf ("%s - Dauer: %f Sekunden\n",'rmdir',microtime(true)-$start);
?>

FAT32:

rd - Dauer: 0.089497 Sekunden
rmdir - Dauer: 0.199794 Sekunden

NTFS:

rd - Dauer: 0.175523 Sekunden
rmdir - Dauer: 0.195713 Sekunden

Und richtig übel wird es, wenn man mit Rekursion arbeiten muss:

<?php
$a = 100;
mkdir ('V1');mkdir ('V1/S1');mkdir ('V1/S2');
mkdir ('V2');mkdir ('V2/S1');mkdir ('V2/S2');
for ($i=0; $i<$a;$i++)
{ touch ('V1/T'.$i); touch ('V1/S1/T'.$i); touch ('V1/S2/T'.$i);
touch ('V2/T'.$i); touch ('V2/S1/T'.$i); touch ('V2/S2/T'.$i);
}

function removedir( $dir )
{ $d = dir( $dir );
while (false!==($f=$d->read()))
{ if ($f=='.' || $f == '..') continue;
$f = $dir . '/' . $f;
if (is_dir($f)) removedir($f);
else unlink($f);
}
$d->close();
rmdir( $dir );
}

$start = microtime(true);
exec ('rd /s /q V1 2>&1');
printf ("%s - Dauer: %f Sekunden\n",'rd',microtime(true)-$start);

$start = microtime(true);
removedir ('V2');
printf ("%s - Dauer: %f Sekunden\n",'rmdir',microtime(true)-$start);
?>

FAT32:

rd - Dauer: 0.063888 Sekunden
rmdir - Dauer: 0.213716 Sekunden

NTFS:

rd - Dauer: 0.092460 Sekunden
rmdir - Dauer: 0.250855 Sekunden

> Außerdem ist Dein Befehl falsch. Er löscht nicht nur leere Verzeichnisse.

Das habe ich nicht behauptet. Das Problem in diesem Thread sind aber nicht
leere, sondern nicht-leere Verzeichnisse. Nachdem man sich anderer Stelle
zur Genüge um die Unterdrückung der Fehlermeldung gestritten hat, dachte
ich, ich beleuchte das Problem mal von einer anderen Seite. Letztendlich
will man nämlich das Verzeichnis mit allem Drum und Dran entfernen, egal
welche Zombies sich darin noch herumtreiben, bzw. gerade wegen der Zombies,
die sich darin herumtreiben.

>> Das '2>&1' fängt die Fehlermeldung ab
>
> "'2>&1' fängt" gar nichts "ab", sondern leitet lediglich die
> Standard-Fehlerausgabe auf die Standard-Ausgabe um.

Da die Standardausgabe bei 'exec' aber nicht ausgegeben wird, sondern in den
optionalen zweiten Parameter zur Weiterverarbeitung gegeben wird, kann man
schon von einem "Abfangen" reden. Es hatte schon einen Sinn, warum ich nicht
nach NUL umgeleitet habe.

Und zu Deinem zweiten Posting:

Wer redet denn plötzlich von Portabilität? Wenn ich im Ausgangsposting einen
absoluten Windows-Pfad sehe, dann gehe ich davon aus, dass die Sache lokal
bei diesem System bleibt. Und ein Lehrbuch, auf was man alles achten soll,
wenn man vielleicht auf Windows für Linux entwickelt, wollte ich nicht
schreiben.

viele grüße
ralph

Ralph 'rkhb' Bauer schrieb:

> Claus Reibenstein schrieb:
>
>> Ralph 'rkhb' Bauer schrieb:
>>
>>> Melanie Gross schrieb:
>>>
>>>> rmdir('C:/xampp/htdocs/test/1');
>>>
>>> Viel schneller und komfortabler ist es, das Betriebssystem zu bitten, so
>>> etwas zu erledigen:
>>>
>>> exec ('rd /s /q C:/xampp/htdocs/test/1 2>&1');
>>
>> Sorry, aber ein externes Programm zu starten, nur um ein leeres
>> Verzeichnis zu löschen, obwohl es dafür direkt eine Funktion in PHP
>> gibt, ist schlicht Quatsch. Und dann auch noch zu behaupten, das sei
>> schneller, ist einfach nur lächerlich.
>
> Habe ich Dir irgend etwas angetan, um diese Gossensprache zu verdienen?

Wie meinen?

> ad 1) Der Sonderfall "leeres Verzeichnis" ist immer wieder der Stolperstein
> bei rmdir. Normalerweise löscht man ein volles Verzeichnis oder noch
> komplizierter: einen unbekannt tief verschachtelten Verzeichnisbaum - und
> will sich überhaupt nicht darum kümmern, was darin ist.

Mag sein, dass Du "normalerweise" volle Verzeichnisse löschst, ohne Dich
um den Inhalt zu kümmern. Ich lösche "normalerweise" Dateien oder leere
Verzeichnisse.

Im Ursprungsposting ging es darum, den Fehler beim Löschen nicht-leerer
Verzeichnisse abzufangen und eine eigene Fehlermeldung auszugeben. Nicht
mehr und nicht weniger. Insbesondere ging es _nicht_ darum, solche
Verzeichnisse samt Inhalt zu löschen.

> ad 2) Ich habe hier ein CLI-Skript, das einen Verzeichnisbaum mit etwa 6000
> Dateien zu löschen hat. Was meinst Du, was schneller ist?

Das hat nichts mit der ursprünglichen Frage zu tun. Lies die
Aufgabenstellung!

>> Der Start eines externen Programms ist eine ziemlich zeitintensive
>> Angelegenheit, besonders im Vergleich zum Aufruf einer lokalen Funktion,
>> die exakt das gleiche macht wie dieses Programm.
>
> Wie Du später richtig erkannt hast, stimmt das nicht.

Wie meinen?

> $start = microtime(true);
> exec ('rd /s /q V2 2>&1');
> printf ("%s - Dauer: %f Sekunden\n",'rd',microtime(true)-$start);
>
> $start = microtime(true);
> rmdir ('V1');
> printf ("%s - Dauer: %f Sekunden\n",'rmdir',microtime(true)-$start);
>
> Ich bekomme auf meiner alten Kiste dabei folgende Ausgabe:
>
> rd - Dauer: 0.061937 Sekunden
> rmdir - Dauer: 0.000488 Sekunden

q.e.d.

> Da mir 60 Millisekunden nicht allzu zeitintensiv erscheinen

Wie bitte? 60 ms gegenüber 0,5 ms bezeichnest Du als "nicht allzu
zeitintensiv"? Wenn ich derart fahrlässing mit den chronisch knappen
Ressourcen der Server meiner Auftraggeber umgehen würde ...

>> Außerdem ist Dein Befehl falsch. Er löscht nicht nur leere Verzeichnisse.
>
> Das habe ich nicht behauptet.

Das habe ich auch nicht behauptet. Deine "Lösung" passt nur nicht zur
ursprünglichen Frage. Lies die Aufgabenstellung!

> Das Problem in diesem Thread sind aber nicht
> leere, sondern nicht-leere Verzeichnisse.

Und was soll mit denen geschehen? Lies die Aufgabenstellung!

> Und zu Deinem zweiten Posting:

Warum antwortest Du hier und nicht dort?

> Wer redet denn plötzlich von Portabilität?

Ich als gestandener Software-Entwickler mit 30 Jahren Berufserfahrung.

Gruß. Claus

Claus Reibenstein wrote:

>> Habe ich Dir irgend etwas angetan, um diese Gossensprache zu verdienen?
>
> Wie meinen?

Er meint das Du an Deiner Ausdrucksweise arbeiten solltest. Hat er doch
recht. Gemessen an der Qualität Deiner Antworten müßtest Du eigentlich
nur gaaanz leise antworten.

> Mag sein, dass Du "normalerweise" volle Verzeichnisse löschst, ohne Dich
> um den Inhalt zu kümmern. Ich lösche "normalerweise" Dateien oder leere
> Verzeichnisse.

Schau doch einfach mal über Deinen horizont. Wenn du ernsthaft behaupten
willst das ein Löschen eines nicht Leeren Verzeichnisses bei Dir noch
nie notwendig war dann frage ich mich was Du 30 Jahre lang programmiert
hast.

> Im Ursprungsposting ging es darum, den Fehler beim Löschen nicht-leerer
> Verzeichnisse abzufangen und eine eigene Fehlermeldung auszugeben. Nicht
> mehr und nicht weniger. Insbesondere ging es _nicht_ darum, solche
> Verzeichnisse samt Inhalt zu löschen.

ACK

> Ich als gestandener Software-Entwickler mit 30 Jahren Berufserfahrung.

:-)

MfG, Ulf

--
_,
_(_p> Ulf [Kado] Kadner
\<_)
^^

Ulf Kadner schrieb:
> Schau doch einfach mal über Deinen horizont. Wenn du ernsthaft behaupten
> willst das ein Löschen eines nicht Leeren Verzeichnisses bei Dir noch
> nie notwendig war dann frage ich mich was Du 30 Jahre lang programmiert
> hast.

ich denke er meint, dass er vorher dann die Dateien aus dem Verzeichnis
löscht. Solang man dies nicht dauernd machen muss (wegen Performance)
ist dies auch ohne Prob per Rekursion mit den PHP Funktionen möglich.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Ulf Kadner schrieb:

> Claus Reibenstein wrote:
>
>> Mag sein, dass Du "normalerweise" volle Verzeichnisse löschst, ohne Dich
>> um den Inhalt zu kümmern. Ich lösche "normalerweise" Dateien oder leere
>> Verzeichnisse.
>
> Schau doch einfach mal über Deinen horizont.

Das ist schwierig. Mein Horizont ist ziemlich weit ...

> Wenn du ernsthaft behaupten
> willst das ein Löschen eines nicht Leeren Verzeichnisses bei Dir noch
> nie notwendig war

Ich weiß nicht, woraus Du dies schließt.

Ralphs Behauptung war, "Normalerweise" lösche "man" (!) nicht-leere
Verzeichnisse . Meine Antwort war, dass _ich_ "normalerweise" etwas
Anderes tue. Ich habe _nicht_ geschrieben, dass ich _niemals_
nicht-leere Verzeichnisse lösche. Ich habe lediglich festgestellt, dass
dies bei mir _nicht_ der Normalfall ist.

Gruß. Claus

Claus Reibenstein wrote:

> Ulf Kadner schrieb:
>> Schau doch einfach mal über Deinen horizont.
>
> Das ist schwierig. Mein Horizont ist ziemlich weit ...

Konnte ich mir schon denken.

>> Wenn du ernsthaft behaupten
>> willst das ein Löschen eines nicht Leeren Verzeichnisses bei Dir noch
>> nie notwendig war
>
> Ich weiß nicht, woraus Du dies schließt.
>
> Ralphs Behauptung war, "Normalerweise" lösche "man" (!) nicht-leere
> Verzeichnisse . Meine Antwort war, dass _ich_ "normalerweise" etwas
> Anderes tue. Ich habe _nicht_ geschrieben, dass ich _niemals_
> nicht-leere Verzeichnisse lösche. Ich habe lediglich festgestellt, dass
> dies bei mir _nicht_ der Normalfall ist.

Aber ich habs so verstanden. Dann entschuldige meine Aussage.

MfG, Ulf

--
_,
_(_p> Ulf [Kado] Kadner
\<_)
^^