GitHub Probleme Anleitung für normale User

[Henry]

Hallo,

Vielleicht liegts an mir, wahrscheinlich sogar, aber ich komme einfach nicht mit GitHub zurecht. Nicht etwa als Anwender sondern als jemand der nur ab und zu ein Script davon testen möchte.

Genauer, früher (ja früher war auch vieles, nicht alles, besser) fand man ein Script im Netz konnte es downloaden und probieren. Für ganz große Enthusiasten war oft sourceforge ein gute Anlaufstelle. Mittlerweile aber hosten aber immer mehr auf GitHub und seltsamerweise bekomme ich selten davon was zum laufen. Laien, und in dem Fall betrachte ich auch mich dazugehörig, werden erschreckt/erschlagen von Fachbegriffen, unverständlichen Codes und zum Download von Dateien gezwungen, die gar nicht zum eigentlichen Script gehören. Ich verstehe zwar die Intention der Leute die dort hosten, wahrscheinlich ist die vorgegebene Routine und Strukturierung für dieses Clientel hilfreich, aber es schafft eine immer größere Kluft zu den "Laien" und letztendlich damit auch das Interesse allgemein. Ich verstehe immer noch nicht für was die Dateien composer, json, .gitattributes, etc. eigentlich da sind, müssen die wirklich drin sein oder betrifft das nur die Entwickler? Dazu kommt auch, das ich eher der Typ "never change a running system" bin und für Änderungen die behutsam kommen, offen bin. GitHub ist da eher schon etwas Radikales für mich.

Nun habe ich mal Anleitungen gesucht, quasi "GitHub as User for Dummies", was ich aber finde sind nur Anleitungen für Entwickler und die auch nicht leicht zu verstehen. Daher, gibt es sowas vielleicht doch, wäre auch bestimmt ein gutes Blogthema hier.

Beispiel:
Gerade habe ich das mal runtergeladen. Müsste doch eigentlich problemlos klappen. Bin genau nach Vorlage vorgegangen:

include 'PDFMerger.php';

$pdf = new PDFMerger; // or use $pdf = new \PDFMerger; for Laravel

$pdf->addPDF('samplepdfs/one.pdf', '1, 3, 4');
$pdf->addPDF('samplepdfs/two.pdf', '1-2');
$pdf->addPDF('samplepdfs/three.pdf', 'all');


$pdf->merge('file', 'samplepdfs/TEST2.pdf'); // generate the file

$pdf->merge('download', 'samplepdfs/test.pdf'); // force download

// REPLACE 'file' WITH 'browser', 'download', 'string', or 'file' for output options 

Aber wieder einmal mehr etwas aus GitHub, was bei mir nicht funktionieren will:

Fatal error:
Uncaught Error: Class 'PDFMerger' not found in *********\PDFMerger-master\test.php:8 Stack trace: #0 {main} thrown in.…

Wieso wird die Klasse nicht gefunden, ist doch da. Muss ich bei GitHub-Files vielleicht noch was anderes beachten.

Gruss
Henry

[MudGuard]

Hi,

liegt die Klasse denn in einem Verzeichnis, das in Deinem PHP-Include-Path eingetragen ist?

Muss ich bei GitHub-Files vielleicht noch was anderes beachten.

Github hat damit m.E. überhaupt nix zu tun.

cu,
Andreas a/k/a MudGuard

[Henry]

Hallo MudGuard,

liegt die Klasse denn in einem Verzeichnis, das in Deinem PHP-Include-Path eingetragen ist?

Die Sache mit dem include-path ist auch sowas was ich isher nie richtig verstanden habe oder um genau zu sein scripte so zu schreiben die abolute Pfade nicht benötigen oder eben mir beholfen wie zb.

$path = dirname(__FILE__);

include $path.'/PDFMerger.php';

Der eigentliche Includepfad ist bei mir:

\xampp\php\PEAR 

Aber so weit ich das immer verstanden habe ist der nur nötig, wenn ein Script nicht gefunden wird, damit PHP dann in diesem Pfad sucht? Aber wie auch immer, es geht auch die oben genannte Variante nicht.

Muss ich bei GitHub-Files vielleicht noch was anderes beachten.

Github hat damit m.E. überhaupt nix zu tun.

Mag sein, doch seltsam ist eben, dass ich früher vielleicht ein Quote hatte von gefundenen Scripten die nicht laufen bei ca. 10%, bei GitHub allerdings ca. 90%. Dabei, durch die Communityeinbindung, sollte das unmöglich sein, also mache ich ja irgendwas verkehrt.

Gruss
Henry

[dedlfix]

Tach!

Muss ich bei GitHub-Files vielleicht noch was anderes beachten.

Das ist kein Github-Problem, sondern hat mit der derzeit beliebten Art zu tun, Abhängigkeiten einzubinden, statt alles selbst mitzubringen. Das Tool, mit dem du dich beschäftigen solltest ist in dem Fall der Composer. Der sorgt dafür, dass alle Abhängigkeiten besorgt und so installiert werden, dass sie nutzbar werden.

dedlfix.

[Henry]

Hallo dedlfix,

Das ist kein Github-Problem, sondern hat mit der derzeit beliebten Art zu tun, Abhängigkeiten einzubinden, statt alles selbst mitzubringen.

Absolut erschreckend. Das empfinde ich als Riesenrückschritt, komme ich unten nochmal drauf zurück.

Das Tool, mit dem du dich beschäftigen solltest ist in dem Fall der Composer. Der sorgt dafür, dass alle Abhängigkeiten besorgt und so installiert werden, dass sie nutzbar werden.

Kein Wunder, dass immer weniger Leute sich für leichte Programmiersachen interessieren. Wenn ich diese Seite sehe, dann habe ich die Wahl zwischen Pest und Cholera, wenn ich denn überhaupt ein wenig verstehe was die von mir wollen. Entweder, wenn ich Windows habe lade ich mir eine exe runter, was ich persönlich eh ungern tue (nicht mal xampp ist bei mir fest installiert), oder aber direkt kommandozeilenorientiert, worauf es letztendlich sowieso hinausläuft.

Man stelle sich vor ein Neuling oder auch ein alter Hase wie ich, der bisher alles eigentlich ganz gut fand wie es ist, sieht dann so ein Video:

https://www.youtube.com/watch?v=yHPwCZAaMak

Da vergeht die Lust.

Mal eine kleine Chronologie, die mich zwar betrifft aber bestimtm auch stellvertretend für viele ist. Bevor das Internet sich etaiblierte, gab es Programmierer, die kannten sich mit Befehlszeilen aus und entwarfen mehr oder weniger schöne Programme. Für Leute wie mich ein Buch mit sieben Siegeln und wenig Motivation dem nachzueifern. Dann kam das Internet und HTML.

Auf einmal konnten ganz normale Leute mit wenigen Befehlen, ja ich weiß sind Auszeichnungen aber für mich waren es Befehle, weil schreib was passiert was, Sachen zaubern. Da wuchs das Interesse mehr zu können. Es bot sich Javascript an und schon war sogar Interaktivität da. Das Interesse wuchs.

Jetzt wollte man aber noch mehr, Gästebücher, Loginbereiche, usw... da gabs leider nur CGI, was auch zu sehr angelegt war an alte Programmierstile, zu kompliziert. Dann kam das wunderbare PHP, für viele überhaupt der Auslöser sich damit mit der Materie zu beschäftigen. Für viele Programmierer der alten Schule ein Graus, ja nahezu ein Sakrileg. Und schon teilte sich diese Gruppe, also die es ganz ablehnten und bei ihren alten Schuhen blieben und die, die es nutzten aber ständig Verbesserungen, in deren Augen, suchten.

Im Lauf der Jahre passierte daher leider folgendes, durch den Einfluß der Urzeit-Programmierer und deren Ansichten, wurde wieder alles komplizierter. Aus einfachen Scripten wurde OOP, aus einfaches Mysql wurde mysqli und PDO, usw… Klar alles professioneller aber schwerer zu verstehen und der Spass bleibt mehr und mehr auf der Strecke.

Noch schlimmer, dass man oft gar keine Wahl hat, alte Funktionen/Möglichkeiten werden ausrangiert neue müssen genutzt werden. Wo mich das extrem gestört hatte war bei SQLITE. Am Anfang war das für mich ein Superding, leicht zu behandeln dann auch noch wie eine Textdatei auf dem Webspace liegen zu haben, einfach saugeil und oft schneller als der Flugzeugträger Mysql. Nun hatte ich mir allergrösste Mühe gegeben die meisten Scripte anzupassen von Mysql auf Sqlite udn lief jahrelang prächtig, nur eben nicht mehr nach den Neuerungen und den neuen Versionen von SQLITE. Da hatte ich dann die Wahl entweder wieder alles neue dazu lernen und wenn möglich auf PDO umstellen, doch da blieb die Angst im Hinterkopf, wann ist das dann alles wieder hinfällig, so ließ ich es sein. Irgendwie habe ich immer das Gefühl es muss immer komplizierter werden, obwohl doch vieles auch "einfach" funktioniert.

Anscheinend ein Kreislauf an dessen Ende dann wieder eine Gruppe von Experten sitzt und Neulingen alles so kompliziert erscheint, und oft auch ist, dass sie sich nicht mal damit beschäftigen möchten. Und das alles, nachdem in den Jahren zwischen 1999 und 2010 alles so wunderbar einfach war und dennoch sich fast jede grössere Anwendung so schreiben ließ. Schade.

Gruss
Henry

[Henry]

Hallo Henry,

Hallo dedlfix,

Das ist kein Github-Problem, sondern hat mit der derzeit beliebten Art zu tun, Abhängigkeiten einzubinden, statt alles selbst mitzubringen.

Absolut erschreckend. Das empfinde ich als Riesenrückschritt, komme ich unten nochmal drauf zurück.

Das Tool, mit dem du dich beschäftigen solltest ist in dem Fall der Composer. Der sorgt dafür, dass alle Abhängigkeiten besorgt und so installiert werden, dass sie nutzbar werden.

Kein Wunder, dass immer weniger Leute sich für leichte Programmiersachen interessieren. Wenn ich diese Seite sehe, dann habe ich die Wahl zwischen Pest und Cholera, wenn ich denn überhaupt ein wenig verstehe was die von mir wollen. Entweder, wenn ich Windows habe lade ich mir eine exe runter, was ich persönlich eh ungern tue (nicht mal xampp ist bei mir fest installiert), oder aber direkt kommandozeilenorientiert, worauf es letztendlich sowieso hinausläuft.

Man stelle sich vor ein Neuling oder auch ein alter Hase wie ich, der bisher alles eigentlich ganz gut fand wie es ist, sieht dann so ein Video:

https://www.youtube.com/watch?v=yHPwCZAaMak

Da vergeht die Lust.

Mal eine kleine Chronologie, die mich zwar betrifft aber bestimtm auch stellvertretend für viele ist. Bevor das Internet sich etaiblierte, gab es Programmierer, die kannten sich mit Befehlszeilen aus und entwarfen mehr oder weniger schöne Programme. Für Leute wie mich ein Buch mit sieben Siegeln und wenig Motivation dem nachzueifern. Dann kam das Internet und HTML.

Auf einmal konnten ganz normale Leute mit wenigen Befehlen, ja ich weiß sind Auszeichnungen aber für mich waren es Befehle, weil schreib was passiert was, Sachen zaubern. Da wuchs das Interesse mehr zu können. Es bot sich Javascript an und schon war sogar Interaktivität da. Das Interesse wuchs.

Jetzt wollte man aber noch mehr, Gästebücher, Loginbereiche, usw... da gabs leider nur CGI, was auch zu sehr angelegt war an alte Programmierstile, zu kompliziert. Dann kam das wunderbare PHP, für viele überhaupt der Auslöser sich damit mit der Materie zu beschäftigen. Für viele Programmierer der alten Schule ein Graus, ja nahezu ein Sakrileg. Und schon teilte sich diese Gruppe, also die es ganz ablehnten und bei ihren alten Schuhen blieben und die, die es nutzten aber ständig Verbesserungen, in deren Augen, suchten.

Im Lauf der Jahre passierte daher leider folgendes, durch den Einfluß der Urzeit-Programmierer und deren Ansichten, wurde wieder alles komplizierter. Aus einfachen Scripten wurde OOP, aus einfaches Mysql wurde mysqli und PDO, usw… Klar alles professioneller aber schwerer zu verstehen und der Spass bleibt mehr und mehr auf der Strecke.

Noch schlimmer, dass man oft gar keine Wahl hat, alte Funktionen/Möglichkeiten werden ausrangiert neue müssen genutzt werden. Wo mich das extrem gestört hatte war bei SQLITE. Am Anfang war das für mich ein Superding, leicht zu behandeln dann auch noch wie eine Textdatei auf dem Webspace liegen zu haben, einfach saugeil und oft schneller als der Flugzeugträger Mysql. Nun hatte ich mir allergrösste Mühe gegeben die meisten Scripte anzupassen von Mysql auf Sqlite udn lief jahrelang prächtig, nur eben nicht mehr nach den Neuerungen und den neuen Versionen von SQLITE. Da hatte ich dann die Wahl entweder wieder alles neue dazu lernen und wenn möglich auf PDO umstellen, doch da blieb die Angst im Hinterkopf, wann ist das dann alles wieder hinfällig, so ließ ich es sein. Irgendwie habe ich immer das Gefühl es muss immer komplizierter werden, obwohl doch vieles auch "einfach" funktioniert.

Anscheinend ein Kreislauf an dessen Ende dann wieder eine Gruppe von Experten sitzt und Neulingen alles so kompliziert erscheint, und oft auch ist, dass sie sich nicht mal damit beschäftigen möchten. Und das alles, nachdem in den Jahren zwischen 1999 und 2010 alles so wunderbar einfach war und dennoch sich fast jede grössere Anwendung so schreiben ließ. Schade.

*Nachtrag. Was ich noch vergessen habe, diese Composer Sache, ich habe nie C++ oder sowas gelernt, eben weil das noch irgendwelche Compiler und andere Abhängigkeiten bestanden, und jetzt fängt man hier auch noch damit an? Nicht gut.

Gruss
Henry

[Auge]

Hallo

*Nachtrag. Was ich noch vergessen habe, diese Composer Sache, ich habe nie C++ oder sowas gelernt, eben weil das noch irgendwelche Compiler und andere Abhängigkeiten bestanden, und jetzt fängt man hier auch noch damit an? Nicht gut.

Bitte mach dich erst kundig, bevor du meckerst. Composer hat nichts mit Compilern zu tun und mit C nicht mehr, als dass dies der Anfangsbuchstabe des Wortes Composer ist.

Composer ist ein Distributions-Tool für PHP-Skripte. So, wie es zum Beispiel APT für Debian-basierte Linux-Distributionen ist. Es erkennt Abhängigkeiten, wenn sie definiert sind und ermöglicht es, diese mit- beziehungsweise nachzuinstallieren.

Wenn deine Neugier denn soweit gereicht hätte, dich über Composer zu informieren und dann auch noch soweit, in die composer.json des Projekts PDFMerger hineinzuschauen, hättest du sehen können, dass dort außer der Mindestanforderung PHP 5.2 keine weiteren Abhängigkeiten angegeben sind.

Tschö, Auge

[Henry]

Hallo Auge,

Bitte mach dich erst kundig, bevor du meckerst. Composer hat nichts mit Compilern zu tun und mit C nicht mehr, als dass dies der Anfangsbuchstabe des Wortes Composer ist.

Ich darf also erst meckern, wenn ich alles verstehe? Was ist das denn für eine Logik? Mein Meckern fängt ja schon damit an, dass es offensichtlich nicht so leicht zu verstehen ist. Ich poste dann noch ein Video, dass mehr abschreckt als erklärt, denke mal wer dieses Video versteht, der braucht es eigentlich gar nicht, weil er eh schon weiß wie es geht. Was Composer != Compiler betrifft ist mir schon klar, da ich aber auch Abhängigkeiten geschrieben habe, und das ist eine Ähnlichkeit.

Composer ist ein Distributions-Tool für PHP-Skripte. So, wie es zum Beispiel APT für Debian-basierte Linux-Distributionen ist. Es erkennt Abhängigkeiten, wenn sie definiert sind und ermöglicht es, diese mit- beziehungsweise nachzuinstallieren.

Das ist es wieder, das Fachchinesisch "APT für Debian-basierte Linux-Distributionen". Ich kann mir noch halbwegs zusammenreimen was damit gemeint ist, ein Neuling, blättert jetzt weiter.

Wenn deine Neugier denn soweit gereicht hätte, dich über Composer zu informieren und dann auch noch soweit, in die composer.json des Projekts PDFMerger hineinzuschauen, hättest du sehen können, dass dort außer der Mindestanforderung PHP 5.2 keine weiteren Abhängigkeiten angegeben sind.

Jawoll, so ist das. Du erwartest allen Ernstes, dass ich mich mit diesen json-Dateien auskennen soll, dann auch noch die Zusammenhänge verstehen soll und dann am Ende noch begreifen soll warum das Script dann immer noch nicht läuft, wenn ich doch alle Dateien beisammen habe? Tut mir leid, das klingt doch schon arg nach aus dem Elfenbeinturm heraus.

Schön wäre ja mal, wenn mir einer erklären könnte, wie ich dieses Script ohne Composer oder sonstwas zum Laufen bringen kann oder ob das Script schlicht fehlerhaft ist.

Gruss
Henry

[Auge]

Hallo

Bitte mach dich erst kundig, bevor du meckerst. Composer hat nichts mit Compilern zu tun und mit C nicht mehr, als dass dies der Anfangsbuchstabe des Wortes Composer ist.

Ich darf also erst meckern, wenn ich alles verstehe? Was ist das denn für eine Logik?

Herrgott nochmal, habe ich irgendwo geschrieben, dass du erst „alles“ verstehen musst, bevor du dich äußern darfst? Nein. Ein sich erkundigen fände ich dann aber schon äußerst hilfreich. Wir sind hier nicht in der Kneipe am Stammtisch, sondern in einem Fachforum für Webentwicklung und du bist für mich zu lange dabei ^[1], als dass mir ein Meckern mit zur Schau gestellter Unkenntnis reichen würde.

Mein Meckern fängt ja schon damit an, dass es offensichtlich nicht so leicht zu verstehen ist. Ich poste dann noch ein Video, dass mehr abschreckt als erklärt, denke mal wer dieses Video versteht, der braucht es eigentlich gar nicht, weil er eh schon weiß wie es geht.

Keine Ahnung, was das Video aussagt, ich schaue es mir nicht an. Aber du willst mir bitte nicht erzählen, dass die Einleitung des Wikipedia-Artikels zu Composer zu fachchinesich ist.

„Composer ist ein anwendungsorientierter Paketmanager für die Programmiersprache PHP. Das Programm steht unter der MIT-Lizenz.

Composer wird über die Kommandozeile ausgeführt und installiert Abhängigkeiten (zum Beispiel: Bibliotheken) eines PHP-Programmes. Verfügbare PHP-Anwendungen können über die Plattform Packagist gesucht werden.“

Hervorhebungen von mir.

In die Wikipedia zu schauen, wäre ein einfacher Schritt gewesen.

Was Composer != Compiler betrifft ist mir schon klar, da ich aber auch Abhängigkeiten geschrieben habe, und das ist eine Ähnlichkeit.

Was hat denn nun Compiler wieder mit Abhängigkeiten zu tun?

Composer ist ein Distributions-Tool für PHP-Skripte. So, wie es zum Beispiel APT für Debian-basierte Linux-Distributionen ist. Es erkennt Abhängigkeiten, wenn sie definiert sind und ermöglicht es, diese mit- beziehungsweise nachzuinstallieren.

Das ist es wieder, das Fachchinesisch "APT für Debian-basierte Linux-Distributionen". Ich kann mir noch halbwegs zusammenreimen was damit gemeint ist, ein Neuling, blättert jetzt weiter.

Ich habe das hier nicht für einen Neuling geschrieben, sondern für dich. So what?

Jawoll, so ist das. Du erwartest allen Ernstes, dass ich mich mit diesen json-Dateien auskennen soll

Nein, ich erwarte, dass du da wenigstens mal reingeschaut hast. Die nämliche Datei hat aktuell (Stand 2019-09-13 08:18) satte 558 Zeichen in 28 Zeilen. Die Datei ist nicht unübersichtlich und hat auch keine tief verschachtelte Struktur. Sie ist mMn tatsächlich leicht lesbar und wenn man weiß, dass Composer das Paketverwaltungssystem ist, das es ist, versteht man den Inhalt aus sich selbst heraus. Allerspätestens dann, wenn man auch mal in eine andere composer.json eines anderen Projekts geschaut hat und einen Vergleich hat.

Programmieren wirst du ja unter anderem auch durch das Studium fremder Quelltexte erlernt haben, oder? Warum verschießt du dich dem an dieser Stelle?

dann auch noch die Zusammenhänge verstehen soll und dann am Ende noch begreifen soll warum das Script dann immer noch nicht läuft, wenn ich doch alle Dateien beisammen habe?

Ich glaube natürlich nicht, dass man aus dem Studium dieser einen Datei heraus alles versteht. Eines jedoch würdest du verstehen, wenn du mal aus deinem Bunker heraus kämst. Für PDFMerger besteht keine Abhängigkeit von einem anderen Programm oder von einer anderen Bibliothek, womit das als mögliche Fehlerursache ausfällt. Es muss also etwas anderes sein.

Mögliche Fehlerursachen auszuschließen ist eine legtime und im Allgemeinen erfolgversprechende Strategie bei der Fehlersuche. Schade, dass du dich ihr mit deiner zur Schau gestellten Verbohrtheit selbst verschließt. 😟

Tschö, Auge

---

1. Auf jeden Fall bist du um einiges länger dabei, als dein Registrierungsdatum aussagt. ↩︎

[Gunnar Bittersmann]

@@Auge

… dass die Einleitung des Wikipedia-Artikels zu Composer zu fachchinesich ist.

Link gefixt.

War vorher: [die Einleitung des Wikipedia-Artikels zu Composer](https://de.wikipedia.org/wiki/Composer_(Paketverwaltung\))

@Christian Kruse: Wo kommt der Backslash her? Ist schon das dritte Mal in kürzester Zeit.

(Nachtrag: Ticket Bug 119 erstellt.)

LLAP 🖖

[Matthias Apsel]

Hallo Auge,

Composer ist ein Distributions-Tool für PHP-Skripte.

Das ist zum Beispiel eine Information, die in dieser Deutlichkeit auch nicht überall zu finden ist.

Wenn deine Neugier denn soweit gereicht hätte, dich über Composer zu informieren und dann auch noch soweit, in die composer.json des Projekts PDFMerger hineinzuschauen, hättest du sehen können, dass dort außer der Mindestanforderung PHP 5.2 keine weiteren Abhängigkeiten angegeben sind.

Dazu hätte man wissen müssen, dass es sinnvoll sein könnte, genau dies zu tun.

Bis demnächst
Matthias

[Auge]

Hallo

Composer ist ein Distributions-Tool für PHP-Skripte.

Das ist zum Beispiel eine Information, die in dieser Deutlichkeit auch nicht überall zu finden ist.

Wie ich eins weiter zitiert habe, tut es zumindest die Wikipedia ^[1]. Für mich wäre sie auch die Stelle, bei der ich meine Recherche begänne.

„Composer ist ein anwendungsorientierter Paketmanager für die Programmiersprache PHP. Das Programm steht unter der MIT-Lizenz.

Composer wird über die Kommandozeile ausgeführt und installiert Abhängigkeiten (zum Beispiel: Bibliotheken) eines PHP-Programmes. Verfügbare PHP-Anwendungen können über die Plattform Packagist gesucht werden.“

Wenn deine Neugier denn soweit gereicht hätte, dich über Composer zu informieren und dann auch noch soweit, in die composer.json des Projekts PDFMerger hineinzuschauen, hättest du sehen können, dass dort außer der Mindestanforderung PHP 5.2 keine weiteren Abhängigkeiten angegeben sind.

Dazu hätte man wissen müssen, dass es sinnvoll sein könnte, genau dies zu tun.

Natürlich weiß man das nicht „von selbst“. Deshalb habe ich ja an die Neugier appelliert. Die hätte mich einfach dort reinschauen lassen.

Tschö, Auge

---

1. Ich verlinke den Wikipedia-Eintrag hier wegen des „Backslash-Problems“ nicht. Der Link dorthin findet sich, von Gunnar gangbar gemacht, in meinem verlinkten Posting. ↩︎

[Gunnar Bittersmann]

@@Auge

Natürlich weiß man das nicht „von selbst“. Deshalb habe ich ja an die Neugier appelliert.

Man™ will nicht immer „neugierig“ sein (müssen). Manchmal will man™ einfach, dass Dinge ganz einfach funktionieren. Früher™ ging’s ja auch. Da bin ich ganz bei Henry.

LLAP 🖖

[Der Martin]

Hallo,

Natürlich weiß man das nicht „von selbst“. Deshalb habe ich ja an die Neugier appelliert.

Man™ will nicht immer „neugierig“ sein (müssen). Manchmal will man™ einfach, dass Dinge ganz einfach funktionieren. Früher™ ging’s ja auch. Da bin ich ganz bei Henry.

ja, ich auch. Information ist nicht nur eine Holschuld, sondern in gewissem Umfang auch eine Bringschuld. Und Neugier ist zwar irgendwie etwas Normales, aber bei jedem unterschiedlich stark ausgeprägt. Oft noch je nach Thema unterschiedlich.
Sich auf die angeborene Neugier zu verlassen, geht garantiert irgendwann schief.

Ciao,
 Martin

[Auge]

Hallo

Natürlich weiß man das nicht „von selbst“. Deshalb habe ich ja an die Neugier appelliert.

Man™ will nicht immer „neugierig“ sein (müssen). Manchmal will man™ einfach, dass Dinge ganz einfach funktionieren.

Ich will hier keineswegs einer erhöhten Komplexität um der erhöhten Komplexität willen das Wort reden. Wenn der Entwickler von WasAuchImmer sich aber dafür entschieden hat, Tool XYZ einzusetzen, muss ich mich halt damit beschäftigen, wenn ich WasAuchImmer einsetzen will. Oder ich lass' es halt.

Früher™ ging’s ja auch. Da bin ich ganz bei Henry.

Weil früher ja auch alles per se „ging“. Sicher doch. Nicht.

Tschö, Auge

[Henry]

Hallo Auge,

Wenn der Entwickler von WasAuchImmer sich aber dafür entschieden hat, Tool XYZ einzusetzen, muss ich mich halt damit beschäftigen, wenn ich WasAuchImmer einsetzen will. Oder ich lass' es halt.

Dieser Gedankengang ist nur teilweise richtig. Müsste ergänzt werden mit "es sei denn, es gibt einen alternativen Weg". So war es zb. bei PortableApps, viele Programme wurden gerne auch in einer, vom Entwickler nicht vogesehenen, protablen Version gewünscht. PortableApps machte dies möglich. Mittlerweile hat sich der Markt sogar so stark an den Userwunsch gewöhnt, dass sehr sehr viele Programme von Haus aus schon mit portablen Versionen kommmen.

Weil früher ja auch alles per se „ging“. Sicher doch. Nicht.

Nicht alles, aber vieles besser.

Gruss
Henry

[Auge]

Hallo

Wenn der Entwickler von WasAuchImmer sich aber dafür entschieden hat, Tool XYZ einzusetzen, muss ich mich halt damit beschäftigen, wenn ich WasAuchImmer einsetzen will. Oder ich lass' es halt.

Dieser Gedankengang ist nur teilweise richtig. Müsste ergänzt werden mit "es sei denn, es gibt einen alternativen Weg". So war es zb. bei PortableApps, viele Programme wurden gerne auch in einer, vom Entwickler nicht vogesehenen, protablen Version gewünscht. PortableApps machte dies möglich. Mittlerweile hat sich der Markt sogar so stark an den Userwunsch gewöhnt, dass sehr sehr viele Programme von Haus aus schon mit portablen Versionen kommmen.

Wo ist der Widerspruch? Wenn der Hersteller auf den Wunsch seiner Kunden hin eine portable App bereitstellt, dann hat er sich eben dazu entschieden. Viele andere tun das nicht. Und ob das nun „sehr viele“ Programme im Sinne von sehr vielen Programmen sind, wage ich auch zu bezweifeln. PortableApps sind meiner Meinung nach Nischenprodukte. Für einzelne Einsatzzwecke sind sie durchaus sinnvoll, werden aber auch kaum außerhalb dieser Nischen benutzt. Wozu auch?

Tschö, Auge

[Der Martin]

Moin,

PortableApps sind meiner Meinung nach Nischenprodukte.

sehe ich nicht so; viele Nutzer haben nur die Vorzüge noch nicht erkannt.

Für einzelne Einsatzzwecke sind sie durchaus sinnvoll, werden aber auch kaum außerhalb dieser Nischen benutzt. Wozu auch?

Unter Windows würde ich Portable Apps tendenziell sogar bevorzugen, solange es nicht um Mainstream-Software geht (wie z.B. Firefox oder so).

So halte ich das System "sauber", gehe der übliches Adipositas von Windows ein bisschen aus dem Weg und vermeide auch Konflikte zwischen verschiedenen Anwendungen. Portable Apps speichern außerdem ihre Einstellungen innerhalb des Programmverzeichnisses, so dass sie mitsamt der persönlichen Einstellungen leicht auf einen anderen PC migriert werden können.

Ganz zu schweigen von Situationen, in denen man nicht die nötige Berechtigung zum Installieren von Software hat. Portable geht immer.

Ich sehe also eine Reihe von Vorteilen, aber keinen Nachteil. Gibt's welche?

Ciao,
 Martin

[Auge]

Hallo

PortableApps sind meiner Meinung nach Nischenprodukte.

sehe ich nicht so; viele Nutzer haben nur die Vorzüge noch nicht erkannt.

Tja, das ist so wie überall. Für mich sind PortableApps für den Einsatz vom USB-Stick aus gedacht. So benutzt, sind sie aber zumindest beim Start schnarchlaaaangsaam. Wenn sie auf dem Rechner selbst liegen, natürlich nicht. Aber portabel sind sie dann auch nicht.

Für einzelne Einsatzzwecke sind sie durchaus sinnvoll, werden aber auch kaum außerhalb dieser Nischen benutzt. Wozu auch?

Unter Windows würde ich Portable Apps tendenziell sogar bevorzugen, solange es nicht um Mainstream-Software geht (wie z.B. Firefox oder so).

Warum nun gerade Firefox nicht? Den gibt es doch als PortableApp.

So halte ich das System "sauber", gehe der übliches Adipositas von Windows ein bisschen aus dem Weg und vermeide auch Konflikte zwischen verschiedenen Anwendungen.

Wieso hältst du so Windows sauber? Entweder du installierst ein Programm normal, dann liegt die Konfiguration in einer oder mehreren Dateien (zum Beispiel als INI) oder in der Registry, oder du installierst das Programm portabel, dann liegt die Konfiguration in einer oder mehreren Dateien. Irgendwo muss die Konfiguration sein und wo sie liegt, ist jenseits der Frage, ob das Programm nur für einen oder für alle Benutzer installiert wird, grundsätzlich Bockwurscht.

Portable Apps speichern außerdem ihre Einstellungen innerhalb des Programmverzeichnisses, so dass sie mitsamt der persönlichen Einstellungen leicht auf einen anderen PC migriert werden können.

Ganz zu schweigen von Situationen, in denen man nicht die nötige Berechtigung zum Installieren von Software hat. Portable geht immer.

Das sind mMn die einzigen zwei nennenswerten Vorteile.

Wobei sich natürlich die Frage stellt, ob es sinnvoll ist, die Restriktionen bezüglich der Softwareinstallation zu umgehen statt das programm offiziel zu installieren. Das kann im Einzelfall schließlich auch arbeitsrechliche Implikationen haben.

Tschö, Auge

[Der Martin]

Moin,

sehe ich nicht so; viele Nutzer haben nur die Vorzüge noch nicht erkannt.

Tja, das ist so wie überall. Für mich sind PortableApps für den Einsatz vom USB-Stick aus gedacht. So benutzt, sind sie aber zumindest beim Start schnarchlaaaangsaam.

das stimmt, aber das ist ja nur einer von mehreren Nutzungs-Aspekten.

Wenn sie auf dem Rechner selbst liegen, natürlich nicht. Aber portabel sind sie dann auch nicht.

Doch. Ich verstehe portabel hier im Sinne von: Leicht auf einen anderen PC portierbar. Einfach kopieren und gut.

Unter Windows würde ich Portable Apps tendenziell sogar bevorzugen, solange es nicht um Mainstream-Software geht (wie z.B. Firefox oder so).

Warum nun gerade Firefox nicht? Den gibt es doch als PortableApp.

Ja. Aber das ist ein Standardprogramm, das auf vielen PCs "sowieso verfügbar" ist, so dass für mich in diesem Fall keine Nachfrage nach einer Portable-Version entsteht.

Typische Kandidaten für Portables sind eher Programme, die nicht unbedingt zu einer typischen PC-Umgebung gehören - z.B. Inkscape, XNView oder ein LibreOffice.

So halte ich das System "sauber", gehe der übliches Adipositas von Windows ein bisschen aus dem Weg und vermeide auch Konflikte zwischen verschiedenen Anwendungen.

Wieso hältst du so Windows sauber?

Weil ein Portable-Programm nicht in die Windows-Konfiguration eingreift. Viele Programme tun das aber bei der herkömmlichen Installation. Zum Beispiel, indem sie ihre selbst mitgebrachten DLLs ins Systemverzeichnis kippen, Einstellungen bestimmter Dienste verändern oder auch nur den Desktop des Nutzers mit unnötigen Icons zumüllen.

Entweder du installierst ein Programm normal, dann liegt die Konfiguration in einer oder mehreren Dateien (zum Beispiel als INI) oder in der Registry, oder du installierst das Programm portabel, dann liegt die Konfiguration in einer oder mehreren Dateien.

Es geht mir aber nicht nur um die Konfiguration, sondern wie erwähnt auch um die Programmdateien selbst. Und davon abgesehen: Die Registry zum Ablegen von Programmkonfigurationen zu verwenden, hielt ich noch nie für eine gute Idee. Aber das ist ein ganz anderes Thema.

Irgendwo muss die Konfiguration sein und wo sie liegt, ist jenseits der Frage, ob das Programm nur für einen oder für alle Benutzer installiert wird, grundsätzlich Bockwurscht.

Hauptsache, sie ist nicht irgendwo in den Tiefen von Windows selbst vertüddelt, etwa in der Registry oder so. Ich möchte jedes Programm einschließlich seiner Konfiguration so gut wie möglich "gekapselt" haben, also klar erkennen können, welche Dateien zu welcher Software gehören.

Das ist übrigens ein Aspekt, der mit bei Unixoiden auch nicht gefällt: Da landet alles mögliche in /usr/bin und Co. Trennung von verschiedenen installierten Paketen, wenigstens durch eigene Verzeichnisse? Fahlanzeige. Akzeptabel ist das für mich nur, weil die Paketverwaltung sehr sauber und konsequent funktioniert und jederzeit den Überblick behält.

Wobei sich natürlich die Frage stellt, ob es sinnvoll ist, die Restriktionen bezüglich der Softwareinstallation zu umgehen statt das programm offiziel zu installieren. Das kann im Einzelfall schließlich auch arbeitsrechliche Implikationen haben.

Ja. Darüber sollte man dann vorher erkundigen.

Ciao,
 Martin

[Auge]

Hallo

Unter Windows würde ich Portable Apps tendenziell sogar bevorzugen, solange es nicht um Mainstream-Software geht (wie z.B. Firefox oder so).

Warum nun gerade Firefox nicht? Den gibt es doch als PortableApp.

Ja. Aber das ist ein Standardprogramm, das auf vielen PCs "sowieso verfügbar" ist, so dass für mich in diesem Fall keine Nachfrage nach einer Portable-Version entsteht.

Typische Kandidaten für Portables sind eher Programme, die nicht unbedingt zu einer typischen PC-Umgebung gehören - z.B. Inkscape, XNView oder ein LibreOffice.

Für mich sind das keine Kandidaten, aber das sieht eh jeder anders. Aber ich kann mit portableApps sowieso nichts mehr anfangen, seit ich von Windows weg bin. Ich werde ganz bestimmt kein Set an solchen Apps pflegen, wenn ich sie selbst nicht benutze. Für die portablen Apps, die es für Linux auch gibt (oder einmal gab? ich finde die Seite nicht), sehe ich ebenso keinen Einsatzzweck.

Wie machst du das? Du arbeitest doch auch mit Linux (Mint, wenn ich nicht irre?)?

Wieso hältst du so Windows sauber?

Weil ein Portable-Programm nicht in die Windows-Konfiguration eingreift. Viele Programme tun das aber bei der herkömmlichen Installation. Zum Beispiel, indem sie ihre selbst mitgebrachten DLLs ins Systemverzeichnis kippen, Einstellungen bestimmter Dienste verändern oder auch nur den Desktop des Nutzers mit unnötigen Icons zumüllen.

Dass die Programmbestandteile alle in und unterhalb eines Verzeichnisses bleiben, ist klar. Aber wenn ein Programm „Einstellungen bestimmter Dienste“ verändert, ist das entweder zum Betrieb des Programms notwendig oder ich will das Programm per se nicht benutzen. Dabei wäre es mir herzlich egal, ob es ein portables Programm ist, oder nicht.

Zum Punkt „unnötige Icons auf dem Desktop“, auch portable Apps können bei der Installation Icons auf dem Desktop anlegen und auch nicht-portable Apps können danach fragen, ob sie das tun dürfen oder nicht. So what? Der einzige Unterschied an der Stelle ist der Umzug auf einen anderen Rechner, bei dem du die Verknüpfung händisch anlegst, wenn du sie denn haben willst.

Irgendwo muss die Konfiguration sein und wo sie liegt, ist jenseits der Frage, ob das Programm nur für einen oder für alle Benutzer installiert wird, grundsätzlich Bockwurscht.

Hauptsache, sie ist nicht irgendwo in den Tiefen von Windows selbst vertüddelt, etwa in der Registry oder so. Ich möchte jedes Programm einschließlich seiner Konfiguration so gut wie möglich "gekapselt" haben, also klar erkennen können, welche Dateien zu welcher Software gehören.

Das ist aber eine „Krankheit“ von Menschen, die sich „zu viel“ mit ihren Rechengeräten beschäftigt haben. 😉 Niemand sonst interessiert sich dafür.

Tschö, Auge

[Der Martin]

Hi,

Aber ich kann mit portableApps sowieso nichts mehr anfangen, seit ich von Windows weg bin. Ich werde ganz bestimmt kein Set an solchen Apps pflegen, wenn ich sie selbst nicht benutze.

ich benutze sie aber durchaus - nur eben nicht zuhause am eigenen PC. Dafür aber am Arbeitsplatz, gelegentlich bei meinen Eltern zuhause, gelegentlich auch bei jemand anderem, wo ich mal zu Besuch bin und den PC nutzen darf.

Wie machst du das? Du arbeitest doch auch mit Linux (Mint, wenn ich nicht irre?)?

Ja, richtig. Da ist aber der Transfer von PC zu PC kein Thema, weil der "Partner" fehlt. Insofern sehe ich da für mich auch keinen echten Bedarf an portabler Software. Die Ordnung und Abgrenzung, die sie bringen könnten, wäre zwar nice to have, aber wie ich schon sagte, vertraue ich dem Paketmanagement ausreichend, um auch ein Durcheinander zu akzeptieren, das ich selbst nicht mehr überblicken könnte.

Und ja, es gibt auch unter Linux zahlreiche Programme, die als Archiv zum Download angeboten werden und einfach nur entpackt werden müssen. Das wäre wohl eine gute Entsprechung zu den Portable Apps.

Dass die Programmbestandteile alle in und unterhalb eines Verzeichnisses bleiben, ist klar.

Nö, das ist für Windows alles andere als klar. Da ist es leider gängige Praxis, dass der Installer einige der zum Programm gehörenden DLLs in %windir%\system32 ablädt. Als ich selbst noch aktiv Windows benutzt und/oder administriert habe, habe ich solche Kackhäufchen nach abgeschlossener Installation sorgfältig ins Programmverzeichnis verschoben, wo sie hingehören.

Aber wenn ein Programm „Einstellungen bestimmter Dienste“ verändert, ist das entweder zum Betrieb des Programms notwendig oder ich will das Programm per se nicht benutzen.

Das weißt du aber vorher nicht. Ebensowenig, welche Bloatware das eigentlich gewünschte Programm noch unbemerkt mitinstalliert, ohne danach zu fragen.

Zum Punkt „unnötige Icons auf dem Desktop“, auch portable Apps können bei der Installation Icons auf dem Desktop anlegen ...

Nein. Portable Apps haben zwar oft auch einen Installer (ich frage mich, wozu?), aber nach der Erstinstallation auf einem beliebigen PC werden sie nur noch als 1:1-Kopie des gewählten Installationsverzeichnisses weitergereicht. Also könnte man anstatt eines exe-Installers ebensogut die "installierte" Portable App als zip-Archiv anbieten^[1].

und auch nicht-portable Apps können danach fragen, ob sie das tun dürfen oder nicht.

Ja. Viele fragen aber gar nicht, sondern machen einfach. Schließlich hast du zu Beginn der Installation per UAC zugestimmt, dass die Software "Veränderungen an der Konfiguration des PCs vornehmen" darf. Welche Veränderungen das sind, was darin alles eingeschlossen ist, verrät dir meist niemand. Da musst du dem Herausgeber blind vertrauen.

Hauptsache, sie ist nicht irgendwo in den Tiefen von Windows selbst vertüddelt, etwa in der Registry oder so. Ich möchte jedes Programm einschließlich seiner Konfiguration so gut wie möglich "gekapselt" haben, also klar erkennen können, welche Dateien zu welcher Software gehören.

Das ist aber eine „Krankheit“ von Menschen, die sich „zu viel“ mit ihren Rechengeräten beschäftigt haben. 😉 Niemand sonst interessiert sich dafür.

Doch - jeder, der einen oder mehrere Windows-PCs betreut und zur Hilfe gerufen wird (oder virtuelle Prügel kriegt), wenn etwas nicht richtig läuft. Lieber investiere ich eine halbe Stunde mehr bei der Einrichtung eines Programms, als dass ich ein paar Tage später mehrere Stunden für die Fehlersuche brauche, wenn das neu installierte Programm sich unerwartet mit einer anderen Software beißt.

So long,
 Martin

---

1. Genaugenommen ist der sogenannte Installer von Portables meist auch nur ein selbstentpackendes Archiv. ↩︎

[Auge]

Hallo

Wie machst du das? Du arbeitest doch auch mit Linux (Mint, wenn ich nicht irre?)?

Ja, richtig. Da ist aber der Transfer von PC zu PC kein Thema, weil der "Partner" fehlt. Insofern sehe ich da für mich auch keinen echten Bedarf an portabler Software.

Auch ein Grund, darüber nicht mehr nachdenken zu müssen und zu wollen.

Dass die Programmbestandteile alle in und unterhalb eines Verzeichnisses bleiben, ist klar.

Nö, das ist für Windows alles andere als klar.

Ähm, das bezog sich auf portable Apps. Tschuldigung, dass ich das missverständlich formuliert habe. Dabei habe ich erst vorgestern auf der NextCloudConf einem Vortrag über Dokumentation von Software gelauscht, in dem es unter anderem darum ging, dass Projektbeteiligte in Texten oft von offensichtlichem ausgehen, das sich allerdings niemand anderem als ihnen selbst erschließt. 😟

[edit]
Der Vortragende, Markus Feilner, hat es „Assumed Obviousness“ genannt. Dies ist das PDF der Folien, der Vortrag selbst ist noch nicht online.
[/edit]

Der nötigen Klarstellung wegen noch einmal: „Dass die Programmbestandteile in portablen Apps alle in und unterhalb eines Verzeichnisses bleiben, ist klar.“

Hauptsache, sie ist nicht irgendwo in den Tiefen von Windows selbst vertüddelt, etwa in der Registry oder so. Ich möchte jedes Programm einschließlich seiner Konfiguration so gut wie möglich "gekapselt" haben, also klar erkennen können, welche Dateien zu welcher Software gehören.

Das ist aber eine „Krankheit“ von Menschen, die sich „zu viel“ mit ihren Rechengeräten beschäftigt haben. 😉 Niemand sonst interessiert sich dafür.

Doch - jeder, der einen oder mehrere Windows-PCs betreut und zur Hilfe gerufen wird (oder virtuelle Prügel kriegt), wenn etwas nicht richtig läuft.

Das ist doch genau das, was ich gesagt habe. Eine „Krankheit“ von Menschen, die sich „zu viel“ mit ihren Rechengeräten oder denen Anderer beschäftigen. 😉

Tschö, Auge

[Henry]

Hallo Auge,

Tja, das ist so wie überall. Für mich sind PortableApps für den Einsatz vom USB-Stick aus gedacht.

Ja aber eben für dich.

So benutzt, sind sie aber zumindest beim Start schnarchlaaaangsaam.

Hängt vom jeweiligen Programm ab, viele aber eben seit usb 3.0 eben nicht.

Wenn sie auf dem Rechner selbst liegen, natürlich nicht. Aber portabel sind sie dann auch nicht.

au contraire, und wie sie das sind. Mal eben eine ganzes Verzeichnis mit unzähligen Programmen auf anderen Rechner übertragen, ein Kinderspiel, das ist das Schöne daran.

Gruss
Henry

[Auge]

Hallo

Tja, das ist so wie überall. Für mich sind PortableApps für den Einsatz vom USB-Stick aus gedacht.

Ja aber eben für dich.

Ja, natürlich mit dieser Einschränkung. Ich sehe allerdings auch wenig Sinn darin, ein Programm portabel auf einem Rechner zu installieren, wenn ich sowieso nur diesen einen Rechner benutze. Ja, wie du und auch @Der Martin beschreibt, kann man ein Programmverzeichnis einfach auf einen anderen Rechner mitnehmen. Aber mal ehrlich, wie oft macht man das?

So benutzt, sind sie aber zumindest beim Start schnarchlaaaangsaam.

Hängt vom jeweiligen Programm ab, viele aber eben seit usb 3.0 eben nicht.

Den Vorteil gibt's aber auch nur dann, wenn man einen USB-3-Stick an einem USB-3-Anschluss benutzt. Mit den meist benutzten USB-2-Sticks ist dieser Vorteil dahin und der Programmstart aufgrund der niedrigen Lesegeschwindigkeit doch „schnarchlaaaangsaam“ ^[1].

Wenn sie auf dem Rechner selbst liegen, natürlich nicht. Aber portabel sind sie dann auch nicht.

au contraire, und wie sie das sind. Mal eben eine ganzes Verzeichnis mit unzähligen Programmen auf anderen Rechner übertragen, ein Kinderspiel, das ist das Schöne daran.

Sicher, das ist auch eine alltägliche Aufgabe. Oder doch nicht?

Um das zu erreichen, reichte auch eine Funktion, die Konfiguration(en) sichern und zurückspielen und die Programme „ganz normal“ installieren zu können.

Tschö, Auge

---

1. Ich weiß, ich weiß, dass ist Jammern auf hohem Niveau. Mein erster Stick an meinem ersten Rechner mit USB konnte, wenn ich mich recht erinnere, USB 1.1. Da bräuchte ich noch viiieeeeel mehr As ^[2]. ↩︎

2. „As“ als Plural von „A“. ↩︎

[Henry]

Hallo Auge,

Hallo

Wenn der Entwickler von WasAuchImmer sich aber dafür entschieden hat, Tool XYZ einzusetzen, muss ich mich halt damit beschäftigen, wenn ich WasAuchImmer einsetzen will. Oder ich lass' es halt.

Dieser Gedankengang ist nur teilweise richtig. Müsste ergänzt werden mit "es sei denn, es gibt einen alternativen Weg". So war es zb. bei PortableApps, viele Programme wurden gerne auch in einer, vom Entwickler nicht vogesehenen, protablen Version gewünscht. PortableApps machte dies möglich. Mittlerweile hat sich der Markt sogar so stark an den Userwunsch gewöhnt, dass sehr sehr viele Programme von Haus aus schon mit portablen Versionen kommmen.

Wo ist der Widerspruch? Wenn der Hersteller auf den Wunsch seiner Kunden hin eine portable App bereitstellt, dann hat er sich eben dazu entschieden. Viele andere tun das nicht.

Wo der Widerspruch ist? Du sagst (siehe oben). Also umgekehrt. Der Entwickler hat sich eben entschieden das eben nicht portable bereits zu stellen. Eben nur gekoppelt ans OS. Laut deiner Aussage muss man das dann so hinnehmen oder eben gar nicht. Falsch, da kam PortableApps, also eine Alternative, die solange sehr populär war bist viele (ja und ich meine sehr viele) Entwickler dieser Nachfrage schuldend auch von Haus aus portable Versionen brachten.

Und ob das nun „sehr viele“ Programme im Sinne von sehr vielen Programmen sind, wage ich auch zu bezweifeln.

Deine Zweifel sind unbegründet.

PortableApps sind meiner Meinung nach Nischenprodukte. Für einzelne Einsatzzwecke sind sie durchaus sinnvoll, werden aber auch kaum außerhalb dieser Nischen benutzt. Wozu auch?

Kommt drauf an was du jetzt meinst, PortableApps oder portable Programme an sich. Ersteres war solange interessant (mehr als 830 Mio. Downloads sind da nicht deiner Meinung), wie eben die Entwickler keine usbtauglichen/portablen Versionen angeboten haben, da das aber mittlerweile sehr viele tun bleibt zweiteres nach wie vor mehr als interessant und alles andere als ein Nischenprodukt.

Eines der besten portablen Sachen auf dem Markt ist für mich ist zb. die portable Version von Xampp. Aber gibt natürlich tausende andere portable Programme, was wohl zeigt, dass es eine Nachfrage danach gibt.

Gruss
Henry

[Auge]

Hallo

Wenn der Entwickler von WasAuchImmer sich aber dafür entschieden hat, Tool XYZ einzusetzen, muss ich mich halt damit beschäftigen, wenn ich WasAuchImmer einsetzen will. Oder ich lass' es halt.

Dieser Gedankengang ist nur teilweise richtig. Müsste ergänzt werden mit "es sei denn, es gibt einen alternativen Weg". So war es zb. bei PortableApps, viele Programme wurden gerne auch in einer, vom Entwickler nicht vogesehenen, protablen Version gewünscht. PortableApps machte dies möglich. Mittlerweile hat sich der Markt sogar so stark an den Userwunsch gewöhnt, dass sehr sehr viele Programme von Haus aus schon mit portablen Versionen kommmen.

Wo ist der Widerspruch? Wenn der Hersteller auf den Wunsch seiner Kunden hin eine portable App bereitstellt, dann hat er sich eben dazu entschieden. Viele andere tun das nicht.

Wo der Widerspruch ist? Du sagst (siehe oben). Also umgekehrt.

Dreh mir die Worte nicht im Mund herum!

Der Entwickler entscheidet, was er macht. Punkt. Er entscheidet auch, ob er (auf Nachfrage oder aus eigenem Antrieb) andere Formate seines Programms (zum Beispiel eine portable Version) bereitstellt. Und dann ist es immer noch seine Entscheidung.

Der Entwickler hat sich eben entschieden das eben nicht portable bereits zu stellen. Eben nur gekoppelt ans OS. Laut deiner Aussage muss man das dann so hinnehmen oder eben gar nicht. Falsch, da kam PortableApps, also eine Alternative, die solange sehr populär war bist viele (ja und ich meine sehr viele) Entwickler dieser Nachfrage schuldend auch von Haus aus portable Versionen brachten.

Ist doch schön, dass sich Entwickler dazu entschieden haben, egal, ob aus eigenem Antrieb oder deswegen, weil der Wunsch von außen an sie herangetragen wurde. Aber schlussendlich waren es die Entwickler, die sich dazu entschieden haben, es zu tun (oder eben nicht).

Dass ich schrieb, der Entwickler entscheidet, heißt übrigens nicht, dass ich der Meinung bin, man könne und solle ihm keine Vorschläge für ein anderes Vorgehen machen. Am Ende muss man aber doch mit der Entscheidung leben. Bei Open Source kann man in den meisten Fällen eine Änderung selbst durchführen (lassen), aber das muss man dann eben auch ohne den eigentlichen Entwickler tun, wenn der nicht gewillt ist, es zu tun.

Und ob das nun „sehr viele“ Programme im Sinne von sehr vielen Programmen sind, wage ich auch zu bezweifeln. Deine Zweifel sind unbegründet.

PortableApps sind meiner Meinung nach Nischenprodukte. Für einzelne Einsatzzwecke sind sie durchaus sinnvoll, werden aber auch kaum außerhalb dieser Nischen benutzt. Wozu auch?

Kommt drauf an was du jetzt meinst, PortableApps oder portable Programme an sich. Ersteres war solange interessant (mehr als 830 Mio. Downloads sind da nicht deiner Meinung), wie eben die Entwickler keine usbtauglichen/portablen Versionen angeboten haben, da das aber mittlerweile sehr viele tun bleibt zweiteres nach wie vor mehr als interessant und alles andere als ein Nischenprodukt.

Welchen Marktanteil an Downloads von Programmpaketen werden diese 830 Mio. Downloads wohl darstellen? 1% oder vielleicht 2%? Selbst wenn es doppelt so viele sein sollten, findet das immer noch in einer Nische statt.

Eines der besten portablen Sachen auf dem Markt ist für mich ist zb. die portable Version von Xampp. Aber gibt natürlich tausende andere portable Programme, was wohl zeigt, dass es eine Nachfrage danach gibt.

Ich sage nicht, es gäbe keine Nachfrage. Nein, ich sage, dass diese Nachfrage im Vergleich zu allen Menschen, die irgendwelche Programme herunterladen, um sie zu installieren, nicht von einer erheblichen Anzahl von Menschen kommt. Es gibt für den sinnvollen Einsatz von portablen Programmen ein ganz bestimmtes, eng umgrenztes Spielfeld, eine Nische.

Tschö, Auge

[Henry]

Hallo Auge,

Dreh mir die Worte nicht im Mund herum!

Schwer möglich, wenn ich dich zitiere.

Der Entwickler entscheidet, was er macht. Punkt. Er entscheidet auch, ob er (auf Nachfrage oder aus eigenem Antrieb) andere Formate seines Programms (zum Beispiel eine portable Version) bereitstellt. Und dann ist es immer noch seine Entscheidung.

Willst du oder kannst du das nicht verstehen. Es ist seine Entscheidung das so zu wollen, hindert aber nicht den User daran das anders, als vom Entwickler gewünscht, zu nutzen.

Ich sage nicht, es gäbe keine Nachfrage. Nein, ich sage, dass diese Nachfrage im Vergleich zu allen Menschen, die irgendwelche Programme herunterladen, um sie zu installieren, nicht von einer erheblichen Anzahl von Menschen kommt. Es gibt für den sinnvollen Einsatz von portablen Programmen ein ganz bestimmtes, eng umgrenztes Spielfeld, eine Nische.

Um es mit deinen eigenen Worten zu sagen, du solltest auch mal aus deinem Bunker rauskommen. Weder deine noch meine Meinung bestimmen das Rad der Zeit, aber Fakten sollte man zumindest anerkennen.

Gruss
Henry

[Auge]

Hallo

Dreh mir die Worte nicht im Mund herum!

Schwer möglich, wenn ich dich zitiere.

Wenn du es sinnentstellend tust, schon.

Der Entwickler entscheidet, was er macht. Punkt. Er entscheidet auch, ob er (auf Nachfrage oder aus eigenem Antrieb) andere Formate seines Programms (zum Beispiel eine portable Version) bereitstellt. Und dann ist es immer noch seine Entscheidung.

Willst du oder kannst du das nicht verstehen. Es ist seine Entscheidung das so zu wollen, hindert aber nicht den User daran das anders, als vom Entwickler gewünscht, zu nutzen.

Wie willst du das tun, wenn es nicht geht, weil es nicht geht? Wenn der Entwickler keine portable Version eines Programms bereitstellt und sie niemand anderes baut (wenn es rechtlich möglioch ist), gibt es sie einfach nicht.

Wenn der Entwickler eines PHP-Skripts sein Skript nur über einen bestimmten Mechanismus bereitstellt, ist das eben so. Was du tun kannst, ist selbst forschen, ob es anders geht, den Entwickler nach einem anderen Installationsweg fragen, oder ein anderes Skript nutzen.

Tschö, Auge

[Der Martin]

Hallo Henry,

Mittlerweile hat sich der Markt sogar so stark an den Userwunsch gewöhnt, dass sehr sehr viele Programme von Haus aus schon mit portablen Versionen kommmen.

ja richtig - und viele Programme waren "schon immer" portable, ohne dass das explizit so genannt wurde.

Firefox zum Beispiel war bis zur Version 3.x per se portable^[1] (obwohl er mit einem Installer kam). Sogar portabler, als die Mozilla-Entwickler gedacht hatten: Es hieß, ab Version 3 laufe der Firefox nicht mehr auf Windows 98, sondern brauche mindestens 2000 oder XP. Der Installer verweigerte auf einem Windows 98 tatsächlich die Arbeit. Hatte man den FF aber auf einem Windows 2000 installiert, konnte man das komplette Firefox-Verzeichnis auf einen anderen Rechner kopieren. Lief. Auch unter Windows 98. :-)

Auch VLC war in frühen Versionen grundsätzlich portable.

Weil früher ja auch alles per se „ging“. Sicher doch. Nicht.

Nicht alles, aber vieles besser.

[X] D'accord.

Ciao,
 Martin

---

1. Die Firefox-Versionen vor 3.0 wurden sogar als zip-Archiv zum Download angeboten. Einfach in ein beliebiges Verzeichnis entpacken, und rennt. ↩︎

[Henry]

Hallo dedlfix,

Das Tool, mit dem du dich beschäftigen solltest ist in dem Fall der Composer.

Eine Frage noch. Wenn ich dazu Composer benötige, warum gibt es denn ein Fork davon, der ausdrücklich darauf hin weist, dass er dies nur macht um composer-kompatibel zu sein. Gehts vielleicht doch ohne?

Gruss
Henry

[Felix Riesterer]

Lieber Henry,

man hat als Programmierer nur zwei Möglichkeiten:

1. Man geht mit der Zeit und lernt stetig dazu, u.a. auch Konzepte, die das Leben in gewissen Bereichen definitiv leichter machen.
2. Man bleibt auf seinem Stand stehen und muss nach einer gewissen Zeit einfach aufgeben, weil man den Anschluss so sehr verloren hat, dass man mit seiner Arbeitsweise definitiv nicht mehr weiter kommt.

werden erschreckt/erschlagen von Fachbegriffen, unverständlichen Codes und zum Download von Dateien gezwungen, die gar nicht zum eigentlichen Script gehören.

Diese Wahrnehmung kann ich nachvollziehen. Und trotzdem bleiben nur obige zwei Möglichkeiten übrig. Meine Empfehlung: Lerne so viel dazu, wie nötig ist, um wieder weiter zu kommen. Du benötigst hier zwei Erkenntnisse, nämlich dass das Werkzeug composer dazu da ist, die benötigten Bestandteile bei Bedarf zu ergänzen (und bei Verfügbarkeit mit einer neueren Version auszutauschen), weil diese Idee bei paketbasierten Betriebssystemen sich seit Jahren sehr gut bewährt. Und als zweites benötigst Du die Erkenntnis, dass das Werkzeug git mit bestimmten Dateien und Verzeichnissen arbeitet, die es zusätzlich in einem Projekt anlegt und verwaltet, die Du aber getrost ignorieren und sogar problemlos löschen kannst, wenn Du git nicht nutzt.

Liebe Grüße

Felix Riesterer

[Henry]

Hallo Felix,

Lieber Henry,

man hat als Programmierer nur zwei Möglichkeiten:

1. Man geht mit der Zeit und lernt stetig dazu, u.a. auch Konzepte, die das Leben in gewissen Bereichen definitiv leichter machen.
2. Man bleibt auf seinem Stand stehen und muss nach einer gewissen Zeit einfach aufgeben, weil man den Anschluss so sehr verloren hat, dass man mit seiner Arbeitsweise definitiv nicht mehr weiter kommt.

Da magst du zwar recht haben, aber wenn mit der Zeit gehen bedeutet, dass Webprogrammierung am Ende auf kommandozeilenorientierte und kryptische Art und Weise gehandhabt wird, dann bin ich lieber raus. Das alle das mitmachen würden, hat schon bei Linux nicht funktioniert, obwohl viele gerne Windows ciao gesagt hätten. Gut vielleicht nicht ganz vergleichbar, weil es gab ja Alternativen wie Windows oder Mac. Aber vielleicht gibts ja auch irgendwann dann wieder eine Alternative für diese Art der Entwicklung, PHP hat ja auch wunderbar Perl/CGI abgelöst.

Gruss
Henry

[Email]

PHP hat ja auch wunderbar Perl/CGI abgelöst.

Das ist so nicht richtig. Wenn es die CGI Schnittstelle nicht geben würde, gäbe es auch keine Webanwendungen in PHP. Und was Git betrifft: Da gibt es Clients für Linux und Windows. MFG

[Henry]

Hallo,

Ich möchte mich nur noch mal vergewissern alles verstanden zu haben, was der Thread so gebracht hat. Hilft vielleicht auch anderen.

• Die meisten Programme bei GitHub, benötigen ein externes Programm (Composer) um diese dann zum Laufen zu bringen.

• Composer selbst ist praktisch eine Software die nachschaut, was alles noch nicht in dem Paket dabei ist und es bei Bedarf dann runterläd und installiert.

• Composer muss letztendlich, auch wenn es als .exe runtergeladen wurde, mit Kommandozeile bedient werden.

• Composer ist kein Script innerhalb der PHP Anwendung und auch nicht portabel. Es muss also auf dem jweiligen Rechner installiert sein. Das bedeutet, wer seine Xampp oder was auch immer portabel betreibt, kann auf dieselbe Weise Composer nicht nutzen.

• Da Composer die Möglichkeit haben muss, Sachen nachzuladen, ist eine Internetverbindung wohl Pflicht.

• Die GitHub Files werden immer mit Nebendateien geliefert, die problemlos gelöscht werden können. (Bin mir da noch nicht sicher welche genau das sind)

Ist das alles so weit richtig?

Eine andere Frage hätte ich noch. Wenn das so in etwa richtig ist, bedeutet das ja dann auch, wenn Composer mit seiner Arbeit fertig ist, liegt das Script vollständig und funktionstüchtig vor. Dann müsste doch ein Service möglich sein, der diese ganzen GitHub-Dateien oder wo eben sonst noch Composer zum Tragen kommt, der dem User diese Prozedur abnimmt. Also vergleichbar, wie die Youtubedownloader oder Online-PDF Konverter, etc. Man gibt dann die GitHub-Adresse ein oder läd das Script rauf und heraus kommt die bereinigte und durch Online-Composer ergänzte Standarddatei. Wäre so ein Service machbar oder spricht was dagegen?

Gruss
Henry

[1unitedpower]

• Die meisten Programme bei GitHub, benötigen ein externes Programm (Composer) um diese dann zum Laufen zu bringen.

Nein, aber viele PHP-Anwendungen und Bibliotheken bieten eine Installation über Composer inzwischen an. Du kannst sie aber auch ohne Composer installieren. Mit GitHub hat das überhaupt nichts zu tun.

• Composer selbst ist praktisch eine Software die nachschaut, was alles noch nicht in dem Paket dabei ist und es bei Bedarf dann runterläd und installiert.

Das trifft den Kern der Sache.

• Composer muss letztendlich, auch wenn es als .exe runtergeladen wurde, mit Kommandozeile bedient werden.

Nein, Composer hat u.a. ein CL-Interface, aber das ist bei weitem nicht die einzige Möglichkeit es zu bedienen. Es ist zum Beispiel auch gängig Composer in CI/CD-Pipelines zu integrieren.

• Composer ist kein Script innerhalb der PHP Anwendung und auch nicht portabel. Es muss also auf dem jweiligen Rechner installiert sein. Das bedeutet, wer seine Xampp oder was auch immer portabel betreibt, kann auf dieselbe Weise Composer nicht nutzen.

Composer ist ein PHP-Programm, es läuft überall da, wo auch PHP läuft, auch in Xampp.

• Da Composer die Möglichkeit haben muss, Sachen nachzuladen, ist eine Internetverbindung wohl Pflicht.

Nein, Composer verfügt über einen lokalen Cache und kann auch in Intranets oder rein lokal betrieben werden. Ein häufiger Anwendungsfall dafür sind firmen-interne GitLab- oder Satis-Server.

• Die GitHub Files werden immer mit Nebendateien geliefert, die problemlos gelöscht werden können. (Bin mir da noch nicht sicher welche genau das sind)

Nein, wie schon gesagt sind GitHub und Composer zwei verschiedene Paar Schuhe. Wenn Composer ein Paket über Git installiert, dann bevorzugt es in der Regel ein Git-Archiv und nicht das gesamte Source-Repository. Man kann über die .gitattributes-Datei einstellen, welche Dateien für ein Deployment nicht relevant sind, Composer würde sie dann nicht herunterladen.

Eine andere Frage hätte ich noch. Wenn das so in etwa richtig ist, bedeutet das ja dann auch, wenn Composer mit seiner Arbeit fertig ist, liegt das Script vollständig und funktionstüchtig vor. Dann müsste doch ein Service möglich sein, der diese ganzen GitHub-Dateien oder wo eben sonst noch Composer zum Tragen kommt, der dem User diese Prozedur abnimmt. Also vergleichbar, wie die Youtubedownloader oder Online-PDF Konverter, etc. Man gibt dann die GitHub-Adresse ein oder läd das Script rauf und heraus kommt die bereinigte und durch Online-Composer ergänzte Standarddatei. Wäre so ein Service machbar oder spricht was dagegen?

Genau diesen Service bietet dir Composer.

[dedlfix]

Tach!

• Composer ist kein Script innerhalb der PHP Anwendung und auch nicht portabel. Es muss also auf dem jweiligen Rechner installiert sein. Das bedeutet, wer seine Xampp oder was auch immer portabel betreibt, kann auf dieselbe Weise Composer nicht nutzen.

Composer ist ein PHP-Programm, es läuft überall da, wo auch PHP läuft, auch in Xampp.

Und man benötigt es nur während der Entwicklung. Wenn man das fertige Produkt auf den Produktivserver bringt, braucht es dort den Composer nicht mehr. Nur die Dinge, die er hinzugefügt hat, muss man mitkopieren, sprich das vendor-Verzeichnis.

dedlfix.

[Felix Riesterer]

Lieber Henry,

ergänzend zu @1unitedpower und @dedlfix:

• Die GitHub Files werden immer mit Nebendateien geliefert, die problemlos gelöscht werden können. (Bin mir da noch nicht sicher welche genau das sind)

GitHub Files ist eine etwas schräge Betrachtungsweise der Sache an sich. GitHub ist eine Plattform, die einen Dienst namens Git bereitstellt, der ein Versionierungssystem und Kollaborationswerkzeuge bietet. Um diese Funktionalitäten umsetzen zu können, müssen zusätzliche Daten verwaltet werden. Das tut Git (nicht zu verwechseln mit GitHub) in diesen von Dir so benannten GitHub Files. Wenn Du nicht mit Git arbeitest, haben sie für Dich keine Bedeutung und können getrost ignoriert und gelöscht werden.

Liebe Grüße

Felix Riesterer

[TS]

Hello,

habe das Thema mal in meine ToDo-Liste aufgenommen. Ich finde, dass man das Thema fast genauso in diesem Frage-Antwort-Stil behandeln sollte. Noch ein paar PAPs dazu malen, dann sollte es verständlich werden.

Bin nur leider gerade mal wieder im KHs und habe nur das Tablet dabei. Aber hier gibt's WLAN, leider mit Splashpage. Das macht immer wieder Probleme mit HSTS.

Bei der Gelegenheit fand ich einen besorgniserregenden Artikel aus 2015 zum Thema wieder. Das ist mMn immer noch gültig. Würde ich daher auch gerne nochmal aufgreifen hier im Forum unter dem Thema "Tracking". Wer weiß mehr darüber?

Glück Auf
Tom vom Berg

[Matthias Apsel]

Hallo TS,

habe das Thema mal in meine ToDo-Liste aufgenommen. Ich finde, dass man das Thema fast genauso in diesem Frage-Antwort-Stil behandeln sollte. Noch ein paar PAPs dazu malen, dann sollte es verständlich werden.

Für die Lektüre: https://riptutorial.com/de/git/ (Allerdings geht es da nicht um den Composer)

Bin nur leider gerade mal wieder im KHs

Gute Besserung!

Bis demnächst
Matthias

[TS]

Hello,

habe das Thema mal in meine ToDo-Liste aufgenommen. Ich finde, dass man das Thema fast genauso in diesem Frage-Antwort-Stil behandeln sollte. Noch ein paar PAPs dazu malen, dann sollte es verständlich werden.

Für die Lektüre: https://riptutorial.com/de/git/ (Allerdings geht es da nicht um den Composer)

Danke für den Tipp.

Glück Auf
Tom vom Berg

[derdicki]

Hallihallo!

Beispiel:
Gerade habe ich das mal runtergeladen. Müsste doch eigentlich problemlos klappen. Bin genau nach Vorlage vorgegangen:

include 'PDFMerger.php';

$pdf = new PDFMerger; // or use $pdf = new \PDFMerger; for Laravel

$pdf->addPDF('samplepdfs/one.pdf', '1, 3, 4');
$pdf->addPDF('samplepdfs/two.pdf', '1-2');
$pdf->addPDF('samplepdfs/three.pdf', 'all');


$pdf->merge('file', 'samplepdfs/TEST2.pdf'); // generate the file

$pdf->merge('download', 'samplepdfs/test.pdf'); // force download

// REPLACE 'file' WITH 'browser', 'download', 'string', or 'file' for output options 

Aber wieder einmal mehr etwas aus GitHub, was bei mir nicht funktionieren will:

Fatal error:
Uncaught Error: Class 'PDFMerger' not found in *********\PDFMerger-master\test.php:8 Stack trace: #0 {main} thrown in.…

Wieso wird die Klasse nicht gefunden, ist doch da. Muss ich bei GitHub-Files vielleicht noch was anderes beachten.

In diesem konkreten Fall liegt das Problem ganz einfach in dem heruntergeladenen Skript selber:

Die Klasse wird nicht gefunden, weil da Etwas in den Sources vom PDFMerger schief gelaufen ist: In der Datei PDFMerger.php ist ganz oben, direkt nach den Kommentaren, die Deklaration

namespace PDFMerger;

Das bedeutet, dass die Klasse, die im sample benötigt wird, nicht PDFMerger , sondern PDFMerger\PDFMerger heisst.

Deswegen wird sie nicht gefunden.

Abhilfe:

Ich habe testweise einfach mal die entsprechende Zeile in der sample.php geändert in

$pdf = new PDFMerger\PDFMerger;

Das hat erstmal insofern funktioniert, als dass der von Dir erwähnte Fatal Error nicht mehr passiert. Dafür gibt es andere Probleme im weiteren Verlauf, wenn nämlich die Klasse selber eine Exception wirft: Die wird nämlich auch nicht gefunden.

Man könnte nun den kompletten Quelltext der Klasse überarbeiten (was wahrscheinlich der sauberste Weg wäre), aber die einfachste Lösung, das Ding zum Laufen zu bekommen, ist, die namespace- Deklaration in PDFMerger.php einfach rauszulöschen.

Danach kann man dann weiter machen, indem man dem Skript dann PDF-Dateien gibt, die auch existieren. Die in sample.php angegebenen gibt es nämlich nicht.

Aber das sollte eigentlich dann kein Problem mehr sein.

Beste Grüsse, Tobias Hahner

[Henry]

Hallo derdicki,

Danke für deine Mühe, aber...

Die Klasse wird nicht gefunden, weil da Etwas in den Sources vom PDFMerger schief gelaufen ist: In der Datei PDFMerger.php ist ganz oben, direkt nach den Kommentaren, die Deklaration

namespace PDFMerger;

Das bedeutet, dass die Klasse, die im sample benötigt wird, nicht PDFMerger , sondern PDFMerger\PDFMerger heisst.

Warum das so ist, verstehe ich nicht, habs aber probiert und ja gefunden wird die Klasse anscheinend, solange namespace PDFMerger noch aktiv ist. Aber wie du schin schreibst, kommen dann andere Fehler...

Deswegen wird sie nicht gefunden.

Abhilfe:

Ich habe testweise einfach mal die entsprechende Zeile in der sample.php geändert in

$pdf = new PDFMerger\PDFMerger;

Das hat erstmal insofern funktioniert, als dass der von Dir erwähnte Fatal Error nicht mehr passiert. Dafür gibt es andere Probleme im weiteren Verlauf, wenn nämlich die Klasse selber eine Exception wirft: Die wird nämlich auch nicht gefunden.

Man könnte nun den kompletten Quelltext der Klasse überarbeiten (was wahrscheinlich der sauberste Weg wäre), aber die einfachste Lösung, das Ding zum Laufen zu bekommen, ist, die namespace- Deklaration in PDFMerger.php einfach rauszulöschen.

Bin nicht sicher ob du jetzt meinst einfach auskommentieren:
#namespace PDFMerger;

Da kommen dann halt:

• Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"?

• Deprecated: The each() function is deprecated. This message will be suppressed on further calls in…

• Warning: fopen(): remote host file access not supported, file:/…

• Warning: fopen(file://*****.pdf): failed to open stream: no suitable wrapper could be found in ********\PDFMerger-master\tcpdf\include\tcpdf_static.php on line 1854 TCPDF ERROR: Unable to create output file: ****.pdf

Danach kann man dann weiter machen, indem man dem Skript dann PDF-Dateien gibt, die auch existieren. Die in sample.php angegebenen gibt es nämlich nicht.

Daher habe ich auch sample nur als Vorlage genommen, meine Pdf sind vorhanden.

Aber das sollte eigentlich dann kein Problem mehr sein.

Tja, eben leider doch, bekomme es nicht hin.

Gruss
Henry

[Auge]

Hallo

… die einfachste Lösung, das Ding zum Laufen zu bekommen, ist, die namespace- Deklaration in PDFMerger.php einfach rauszulöschen.

Bin nicht sicher ob du jetzt meinst einfach auskommentieren:
#namespace PDFMerger;

Ich würde das nicht anders interpretieren.

Da kommen dann halt:

…

• Deprecated: The each() function is deprecated. This message will be suppressed on further calls in…

Wie die Meldung sagt, wird die Funktion each in einer der nächsten PHP-Versionen entfernt werden. Je nach Anwendungsfall kommen unterschiedliche Lösungen als Ersatz infrage. Beispiel:

# deprecated use of each()
while (list($key, $val) = each($settings)) {
# replacement with foreach()
foreach ($settings as $key => $val) {

• Warning: fopen(): remote host file access not supported, file:/…

Das Pseudoprotokoll file:/// wird nicht unterstützt. Greife auf die Dateien ohne das Pseudoprotokoll zu ($fh = fopen('../pfad/zur/datei.txt', 'r');).

• Warning: fopen(file://*****.pdf): failed to open stream: no suitable wrapper could be found in ********\PDFMerger-master\tcpdf\include\tcpdf_static.php on line 1854 TCPDF ERROR: Unable to create output file: ****.pdf

Folgefehler des vorherigen Fehlers.

Tschö, Auge

[derdicki]

Hallihallo!

Bin nicht sicher ob du jetzt meinst einfach auskommentieren:
#namespace PDFMerger;

Ich würde das nicht anders interpretieren.

Kann man machen. (Wobei ich das Rautezeichen noch nie für Kommentare in PHP auf dem Schirm hatte. Aber wenn es geht...) Ich habe die Zeile tatsächlich einfach stumpf komplett gelöscht. Weg. Raus. Kann man sich hinterher immer noch drum kümmern, wenn man mal will...

• Deprecated: The each() function is deprecated. This message will be suppressed on further calls in…

Ich hab das Skript jetzt interessehalber nochmal angeschaut und angeworfen, aber diese Fehlermeldung kam bei mir nicht. In welcher Zeile welcher Datei soll sie denn auftreten?

• Warning: fopen(): remote host file access not supported, file:/…

Das Pseudoprotokoll file:/// wird nicht unterstützt. Greife auf die Dateien ohne das Pseudoprotokoll zu ($fh = fopen('../pfad/zur/datei.txt', 'r');).

• Warning: fopen(file://*****.pdf): failed to open stream: no suitable wrapper could be found in ********\PDFMerger-master\tcpdf\include\tcpdf_static.php on line 1854 TCPDF ERROR: Unable to create output file: ****.pdf

Folgefehler des vorherigen Fehlers.

Der sich in diesem konkreten Fall super einfach vermeiden lässt: ein Blick auf die entsprechende Stelle im Quelltext^[1] zeigte mir, dass dieses "file://" nur als Fallback zum Dateinamen hinzuaddiert wird, wenn die Funktion einen lokalen Dateinamen mit einem :// darin übergeben bekommt. Mir kam der "dumme" Gedanke, in der sample.php einfach mal einen ordentlichen Dateinamen zu übergeben:

->merge('file', dirname(__FILE__).'/samplepdfs/TEST2.pdf');

Und siehe da: es funktioniert. Keine Möchtegern-Rettungsfunktion funkt mehr dazwischen, mein gemergtes PDF wurde anstandslos erzeugt.

Die Anzeige im Browser blieb zwar leer, aber das ist bei einem so rudimentären sample ja auch in Ordnung.

Beste Grüsse, Tobias Hahner

---

1. Ist eigentlich immer eine gute Idee. Durch gucken kann man Nichts kaputt machen, höchstens lernen (bei Quelltexten) ↩︎

[Auge]

Hallo

Bin nicht sicher ob du jetzt meinst einfach auskommentieren:
#namespace PDFMerger;

Ich würde das nicht anders interpretieren.

Kann man machen. (Wobei ich das Rautezeichen noch nie für Kommentare in PHP auf dem Schirm hatte. Aber wenn es geht...)

Das „#“ als Kommentarzeichen in PHP gibt's wohl, weil in der Anfangszeit von PHP Perl der große Konkurrent war und die Programmierer, die von Perl kamen, dieses Zeichen gewohnt waren. So lautet jedenfalls die Geschichte, die mir erzählt wurde.

• Deprecated: The each() function is deprecated. This message will be suppressed on further calls in…

Ich hab das Skript jetzt interessehalber nochmal angeschaut und angeworfen, aber diese Fehlermeldung kam bei mir nicht. In welcher Zeile welcher Datei soll sie denn auftreten?

Keine Ahnung, das sollte @Henry sagen können. Er hat ja die volle Meldung inklusive Zeilennummer bekommen. Wahrscheinlich kommt es auch auf die PHP-Version an, ob man die Meldung zu Gesicht bekommt oder nicht. In PHP 7.2 habe ich sie in anderen Skripten jedenfalls auch schon gesichtet.

Tschö, Auge