[PHP] Unlink() wildcard?

[me1299]

Weet iemand hoe ik met php bijvoorbeeld alle bestanden uit een directory kan wissen die eindigen met .tmp

unlink() kan je gebruiken om een file te wissen, maar deze accepteert verder geen argumenten of filters.

[ edit]Ik heb al nagedacht of ik iets met sytem() kan doen, maar dat werkt niet echt universeel.[/edit]

[Verwijderd]

Schrijf een wrapper, die een directory uitleest, alle aan de string voldoende namen in een array zet en die met unlink() verwijdert ...

[me1299]

Verwijderd schreef op 17 november 2002 @ 01:12:
Schrijf een wrapper, die een directory uitleest, alle aan de string voldoende namen in een array zet en die met unlink() verwijdert ...

hehe goed idee.. is wel ff wat omslachtig.

Toch dom dat als ik met google zoek het met asp heel zo moeilijk niet is:

Set ts = fso.DeleteFile("D:\test\test2\test3\*.*")



Ben ik niet gewend om eerlijk te zijn

[me1299]

mocht iemand er nog wat aan hebben:

PHP:

if ($dir = @opendir("tmp")) {
  while (($file = readdir($dir)) !== false) {
    $file_to_delete = "tmp/". $file;
    @unlink($file_to_delete);
  }  
  closedir($dir);
}

Deze delete heel de tmp dir in mijn project.

[Verwijderd]

Is het geen slim plan om een functie Unlink(); te schrijven die met Wildcards werkt?
Het is zo stom dat zo'n functie er nog niet is...

Ik ga er één schrijven, als hij af is post ik de URL wel...

[Janoz]

Maak 'm dan gelijk mbv een regexp .. dan is ie ook nog een stuk mooier dan de ASP variant

[kvdveer]

Janoz schreef op 17 november 2002 @ 16:40:
Maak 'm dan gelijk mbv een regexp .. dan is ie ook nog een stuk mooier dan de ASP variant

PHP:

function UnlinkExtended($dir,$fileregexp,$recurse = false) {
  if($dir[strlen($dir)-1] != '/') 
   $dir.='/';
  
  if ($dir = @opendir("tmp")) 
  {
    while (($file = readdir($dir)) !== false) 
    {
      $file_to_delete = $dir. $file;
      if(is_dir($file_to_delete)) 
      {
        if($recurse) UnlinkExtended($dir.$file,$fileregexp,true)
      }
      else 
      {
         if(preg_match($fileregexp,$file)
            @unlink($file_to_delete);
      }
      
    }  
    closedir($dir);
}

[CyberSnooP]

kvdveer schreef op 17 November 2002 @ 16:52:

PHP:

function UnlinkExtended($dir,$fileregexp,$recurse = false)

Cool! Maar onthoud wel dat je hierbij voor elke file een regular expression moet toepassen en dat kost aardig wat tijd.

Voor zover het niet toch al een goed idee was moet je het gebruik van UnlinkExtended dus vermijden bij elke pagina-aanroep. Schrijf liever een op vaste tijdstippen draaiend onderhoudsscript (cronjob) of gebruik de oplossing alleen op pagina's die speciaal voor dat doel worden aangeroepen (een clean-up itempje in je admin bijvoorbeeld).

[kvdveer]

CyberSnooP schreef op 17 November 2002 @ 17:24:
[...]
Cool! Maar onthoud wel dat je hierbij voor elke file een regular expression moet toepassen en dat kost aardig wat tijd.

Voor zover het niet toch al een goed idee was moet je het gebruik van UnlinkExtended dus vermijden bij elke pagina-aanroep. Schrijf liever een op vaste tijdstippen draaiend onderhoudsscript (cronjob) of gebruik de oplossing alleen op pagina's die speciaal voor dat doel worden aangeroepen (een clean-up itempje in je admin bijvoorbeeld).

zowiezo is unlinken doorgaans een onderhoudstaak.
Momenteel is 'ie trouwens niet echt compatible met windows, ik gebruik een forwardslash. Hij is trouwens ook 110% untested...

[Verwijderd]

@unlink($file_to_delete);

@ is vies, gebruik een if-statement..

[kvdveer]

Verwijderd schreef op 17 November 2002 @ 18:40:
[...]

@ is vies, gebruik een if-statement..

@ is niet per definitie vies... Het is vies als je het te pas en te onpas gebruikt.

WIl je het zonder @ doen dan moet je:
1. controleren of het bestand bestaat
1a. Controleren of het geen directory is
2. Controleren of je schrijfrechten hebt
3. Controleren of het niet op een read-only filesystem staat

En zelfs dan kan het mis gaan op een samba-share bijvoorbeeld waar ook zaken als timing mee gaan spelen.

Kortom: @ heb je in dit geval ècht nodig. Je hebt er gelijk in dat er een nette afhandeling van eventuele fouten moet staan.

Je krijgt dan:

PHP:

function UnlinkExtended($dir,$fileregexp,$recurse = false) {
  if($dir[strlen($dir)-1] != '/') 
   $dir.='/';
  
  if ($dir = @opendir("tmp")) 
  {
    while (($file = readdir($dir)) !== false) 
    {
      $file_to_delete = $dir. $file;
      if(is_dir($file_to_delete)) 
      {
        if($recurse) UnlinkExtended($dir.$file,$fileregexp,true)
      }
      else 
      {
         if(preg_match($fileregexp,$file)
            if(!@unlink($file_to_delete)) trigger_error("Could not delete file");
      }
      
    }  
    closedir($dir);
}

Je blijft de @ nodig hebben, omdat unlink nou eenmaal kan falen.

[Verwijderd]

Wat een onzin. 'Error handling' vs 'doen alsof je neus bloedt'.

Misschien wil je wel een gebruiker melden dat er iets is fout gegaan. Als handige functie moet je dat dan niet verbergen, maar doorgeven naar buiten, zodat de programmeur daar kan beslissen wat er moet gebeuren met deze fout.

[kvdveer]

Verwijderd schreef op 18 November 2002 @ 02:20:
Wat een onzin. 'Error handling' vs 'doen alsof je neus bloedt'.

Misschien wil je wel een gebruiker melden dat er iets is fout gegaan. Als handige functie moet je dat dan niet verbergen, maar doorgeven naar buiten, zodat de programmeur daar kan beslissen wat er moet gebeuren met deze fout.

In library functie mag je de gebruiker NIET op de hoogte stellen dat er iets gebeurd is, het is de taak vande frontend om dat te doen. Natuurlijk moet je wel de fout opvangen en aanbieden aan de frontend. Daarvoor was dan ook mijn tweede wijziging. Nogmaals: zonder @ kan dat niet.
Als jij er van overtuigd bent dat het wel kan (zonder dat de functie zelf faalt!) laat maar zien dan.

[Verwijderd]

Maar hierbij ga jij ervan uit dat het erg is dat de functie faalt. Mijns inziens is dat niet erg, mits je in je aanroepende code een error handler hebt. En zelfs als je dat erg vindt kan je binnen je funktie een specifieke error handler aangeven met set_error_handler(). Ik vind de error handling funkties van PHP niet mooi maar ze zijn volgens mij goed bruikbaar.

Ik zeg dit overigens als iemand die PHP alleen in theorie kent, want ik werk er niet mee.