Ankündigung

Einklappen
Keine Ankündigung bisher.

Rückgabewert von ZipArchive::addGlob

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Rückgabewert von ZipArchive::addGlob

    Hi,
    ich erhalte von addGlob als Rückgabewerte Arrays. Im PHP-Handbuch steht dagegen nur etwas von true/false. Codeschnipsel zum testen:
    PHP-Code:
    $zip = new ZipArchive;
    $zip->open'test.zip'ZIPARCHIVE::OVERWRITE ); 
    $returnValue $zip->addGlob('*.{jpg}'GLOB_BRACE);
    $zip->close();
    var_dump($returnValue); 
    Im Erfolgsfall erhalte ich ein Array mit Dateinamen wie bei glob, wenn nichts gefunden wurde ein leeres Array.

    Ist dies schon bekannt? Hab auf die Schnelle nichts gefunden.

    LG jspit
    PHP-Klassen auf github


  • #2
    Kann ich bestätigen. Liefert offenbar in allen Versionen ein Array zurück: http://3v4l.org/7hQvP
    In PHP 5.6 läuft der Code nicht (zu faul zum Debuggen), ich habe aber kurz in der Doku und im Changelog nachgeschaut. PHP 5.6 bringt zwar mit ziplib 1.11.2 eine neue Version, bei der Funktion sollte sich aber nichts geändert haben.
    Sieht nach Bug aus.

    Kommentar


    • #3
      Bug würde ich nicht sagen, eher ein kleiner Fehler im Handbuch. Rückgabewerte wie bei glob finde ich schon o.k.
      PHP-Klassen auf github

      Kommentar


      • #4
        Zitat von jspit Beitrag anzeigen
        Bug würde ich nicht sagen, eher ein kleiner Fehler im Handbuch. Rückgabewerte wie bei glob finde ich schon o.k.
        ach das handbuch, hatte leztens was ähnliches geposted, verschiedene rückgabewerte in verschiedenen sprachen. english wars richtig deutsch (und alle sprachen die aus dem deutschen übersetzt wurden?), falsch.

        Kommentar


        • #5
          Zitat von jspit Beitrag anzeigen
          Bug würde ich nicht sagen, eher ein kleiner Fehler im Handbuch.
          Ist jetzt Begriffs-Haarspalterei. Imho ist es ein Fehler wenn der Code nicht so arbeitet wie in Spezifikation/Dokumentation festgelegt. Tut jetzt ja aber eigentlich wenig zur Sache. (Und ich weiß gar nicht ob man im PHP-Bugtracker auch Fehler in den docs melden darf.)

          Kommentar


          • #6
            Ja, darf man und sollte man wohl auch. Die Anlaufstelle ist ebenfalls: https://bugs.php.net/ Dort gibt es eine Kategorie für Doku-Fehler.

            Ich habe das zwei-, dreimal gemacht. Eine Sache wie das hier dürfte meiner (geringen ) Erfahrung nach gute Chancen haben, rasch behoben zu werden.

            Ich verlinke mal meine Einträge, weil die vielleicht als eine Art Template dienen können.

            - https://bugs.php.net/bug.php?id=63027
            - https://bugs.php.net/bug.php?id=65389

            Es ist sicher immer hilfreich (aber kein Muss!), den passenden C-Code zu einem Report rauszusuchen. Das nimmt dem Reviewer im Zweifel Arbeit ab und sorgt für größere Legitimation des Reports und dadurch bestenfalls für erfolgreichere Bearbeitung. (Die Idee dazu ist, dass die Reviewer die wenigsten Sachverhalte problemlos selbst beurteilen können dürften, weil sie in der Regel wohl nicht die Entwickler der jeweiligen Komponente sind. Aber keine Ahnung, wer da was schreibt. De facto wird es zu wenig Doku-Autoren geben. Anders kann ich mir jedenfalls nicht erklären, warum etwa so viel aus der SPL noch immer sehr rudimentär dokumentiert ist.)

            Ach ja: Letztlich ist die englische Fassung der Doku im Zweifel die einzige, auf die man sich beziehen sollte. Das ist das Original. Die anderen Sprachversionen sind im Zweifel nicht aktuell und nicht verlässlich. (Ist vermutlich klar, aber ich sage es noch mal konkret. )

            Und das ist eine elendige Arbeit selbst für kleinste Anpassungen, ja.

            Kommentar

            Lädt...
            X