Moin!

Das Packet heißt einfach: perl
Sollte aber bei der Basisinstallation schon dabei sein.

Wie jetzt genau? Das dein Perlprogramm über den Packetmanager installieren werden kann? Oder das du das Perlprogramm ohne einen vorhandenen Perlinterpreter ausühren kannst? Oder beises?

Für das erstellen von Packeten kannst du mal hier schauen:
https://help.ubuntu.com/6.10/ubuntu/packagingguide/C/index.html
Oder erstellst ein tar-Archive und Konvertierst es mit alien


Zum ausführern von Perlprogrammen ohne perlinterpreter schau die mal perlcc an

erstmal danke

ich dachte eher an beides.
Den link werd ich mir mal angucken.
perlcc... Ich glaub wir hattn schon mal eine Diskusion darüber, oder?

Ich bins nochmal.
Ich habe jetzt die richtigen Worte gefunden:

Ich will eigentlich nur, dass das Programm per Doppelklick gestartet werden kann und der Quelltext geschützt ist. Danke schon jetzt.
mfg
TByte

Unter welchen system?
Linux/Unix? Da sollte es reichen wenn du das ausführungsbit setzt (chmod +x DasScript.pl). Dazu sollte die Shebang-Zeile aber stimmen.

Unter Win müsstest du in den Ordneroptionen, da wo auch die Dateiendungen mit den zugehörigen Programmen angegeben sind eine eintrage erstellt werden der Win sagt das dateien mit der Endung *.pl mit Perl geöffnet werden sollen.


Den Quelltext zu schützen wird schwer. Es gibt da eine möglichkeine den Quelltext eines Perl-Scriptes in einen "Byte-Code" zu convertieren... aber das lässt sich wieder rückgängig machen.
Außer du nutzt so etwas wie perlcc was dein Perl-Script quasi in Maschienensprache convertiert.

Ich hätte da mal eine Idee:
Is zwar nix für ich, aber die Profis unter euch können sich ja mal an ein etwas größeres Projekt wagen:
Ein perl-Compiler!
Sollte so funktionieren:
Perl wird ja interpretiert. Nun nimmt man einen Open-Source-Interpreter wie den unter Linux und kopiert die Teile, was was macht, wenn was eingetippt wurde, in das eigene Programm. Jetzt hat man schon mal einen Interpreter. Der Per-Code wird ja dennoch zwischengespeichert, und zwar in Machienencode, und so wird der ja ausgeführt. Jetzt müsste man ja nur noch den Zwischengespeicherten Code als ausführbare Datei speichern, oder? Weil egal, ob Interpreter oder Compiler, die Sprach wird früher oder später in Maschienencode übersetzt, nur dass der Interpreter Zeile-für-Zeile übersetzt und nur ZWISCHENspeichert und nicht ABspeichert. Wenn man dies ändert, macht man aus einem Interpreter einen Compiler! Oder hab ich was falsch verstanden?
mfg
TByte

Theoretisch sollte es möglich sein, wenn der Interpreter den Quelltext in Maschienensprache wandelt, was aber meines wissens nicht der fall ist. Perl arbeitet auf "seiner untersten ebene" mit Bytecode und JIT-Compiler hat er glaube ich nicht. Aber evt. ändert sich das mit Perl 6 in der ein neuer Interpreter drin sein soll (Parrot )der einen JIT-Compiler haben soll.

Also diese Zwischencode-Speicheridee mit irgendwelchen Jittern ist ja ganz niedlich, aber leider komplett veraltet und es bringt auch nur was, wenn man einen Jitter installiert hat!
Ich meinte ja aber, dass man nix braucht, wenn man das Programm ausführen will. Eine C++-Konsolenanwendung benötigt auch nich son kram, denn Doppelklick und fertig! Und sowas müsste man für Perl einrichten. Also nix Java/C#-Erst-in-erfundene-zwischensprache-die-kein-schwein-lesen-kann-compilieren-und-dann-durch-irgendeinen-seltsamen-konsolen-interpreter-compiliertes-interpretieren-methode. Sondern wirklich ein Unabhängiges Programm! Villeicht mit Bison und Flex (Obwohl, perlcc gibt es ja schon).
Worauf ich hinaus will, ist, dass Perl zu einer richtigen Compiler-Sprache werden sollte und gleichzeitig auch seine Interpreter-Eigenschaft bewahren sollte (Interpreter als für CGI und Compiler für Programm).
Aber, mit verlaub, dieser Jitter-Kram ist wirklich das allerletzte! Nicht nur, dass man erst irgendein in wahrscheinlich C/C++ geschriebenen Interpreter installieren muss, um in einer seltsamen, extrem objektorientierten Sprache, für dessen Erlernen ein Anfänger die paar Jahre braucht kryptische Programme zum laufen zu bringen, für die man anstatt 1000 Zeilen Code in einer Prozeduralen Sprache, die auch OOP ermöglicht wahrscheinlich nur 500 bräuchte, sondern dazu kommt noch die unbequemlichkeit beim Testen der Proggis:
Tippe ein, speicher ab, compiliere, suche compiliertes, interpretiere, programm stürtzt ab, mache nochmal alles von vorn.
Interpreter sind da schon besser:
tippe ein, starte konsole, interpretiere, programm stürtzt ab, nochmal. Allerdings ist hier der Nachteil: Konsole aus, Programm aus! egal ob GUI oder nicht.
Compilierte Sprachen sind besser, vor allem weil es da einen haufen IDEs gibt, die einem die Arbeit abnehmen. Und die Programme sind eigenständig und müssen nicht durch konsolen Interpreter ausgeführt werden.
Ich hoffe man konnte meine Äusserungen verstehen
mfg
TByte

Das Vorhandensein einer IDE hat nichts damit zu tun ob ein Programm interpretiert/bytecode-basiert oder compiliert ist, man kann z.B. Eclipse sehr gut als IDE für PHP (eine rein interpretierte Sprache) einsetzen.

Bytecode ist für plattformunabhängigen Code unumgänglich und macht deswegen durchaus Sinn.

Und mal ganz ehrlich, wer sich über "kryptische Programme" aufregt, der sollte nicht ausgerechnet mit PERL arbeiten; es gibt genug Sprachen mit einer klaren, verständlicheren Syntax.

Sorry mir sagt jitter(n) jetzt nix meinst du damit die JIT-Compiler?
Wenn ja, der JIT-Compiler ist meistens ein teil der Virtuellen Maschiene, wie der Perlinterpreter im grunde auch eine ist. Der JIT-Compiler compiliert wärend der laufzeit des Programmes/Script teile in Maschienencode um die Ausführung der Progremme/Scripte zu beschleunigen.


Stimmt... aber ein Ziel solch einer Sprachen wie Perl soll sein, dass sie Platform unabhängig ist. Sprich, du schreibst dein Programm z.B. auf einen Linux-System was auf einer PowerPC-Architektur läuft, nimmst das Programm und kannst es ohne etwas am Quelltext zu verändern auf dein 64Bit Vista laufen lassen.


*Z* sollen das ja auch nicht lesen, die sollen dick werden und gut schmecken ;) Du sollst es ja nicht lesen sondern der Interpreter, für dich ist die andere Syntax da. Das ganze wandelt man in Bytecode um weil es die Ausführungsgeschwindigkeit erhöt. Da das auswerten von zwei, drei ASCII Zeichen weniger taktzyklen der CPU braucht als ein Wort mit 5 Zeichen, und je weniger Taktzyklen desto schneller das Programm ;)

Mit Jitter meine ich JIT-Compiler
---



Ja, aber überleg mal:
Der Aufwand, für jedes System einen neuen Interpreter/Jitter zu programmieren, is doch viel zu groß! Und im übrigen:
Wenn man nich System-Tiefe-Eingriffe vornimmt, was man eh nicht mit Interpretern oder ähnlichem machen kann, kann man den Code einer compilersprache einfach auf dem zweiten System neu compilieren und fertig! Und als Interpreter müsste man tausende male wieder in die Konsole...
Was ich meine, ist (am besten als Beispiel):
Man soll ein Programm schreiben, welches auf ein CD-ROM Laufwerk zugreift.
Es stimmt schon, Interpreter Code kann man auf jedem System ohne veränderungen kopieren, aber kann man denn auch wirklich mit Java auf Laufwerke zugreifen (OS-API kann man ja nich nutzen, soll ja plattformunabhängig sein, oder?)
Mit einer Compiler-Sprache wie C/C++ kann man ganz leicht, einfach nur mehrere Code-Zeilen ändern (Im falle der Laufwerke einfach nur neue Funktion und die API-Bibliothek ändern) und schwupp - Fertig! Und das ohne kryptischen Konsolen und Fenster (Falls überhaupt GUI), die sich mit dem Schließen der Konsole auch schließen!
mfg
TByte

Der aufwand für jedes System einen eigenen Interpreter zu Programmieren ist im endeffekt kleiner als wenn der ganze Quelltext deines Programmes jedesmal geändert werden muss. Beim Interpreter machst du das nur ein mal, bei deinen Programmen musst du das dann für alle Programme machen.


Ja das kannst du machen bei sehr einfachen Programmen. Sobald du aber z.B. ein Fenster malen willst oder auf Netzwerkgeräte zugreifen möchtest, dann wirst du das Problem haben das die API aufrufe von z.B. Linux & Windows sich unterscheiden. Durch Verwendung von z.B. #ifdef WIN32 könntest du eine "Platformunabhängigkeit" bekommen. Und/Oder du nutzt ein Framework wie z.B. QT oder GTK welches für verschiedene Systeme gibt, dann ist dein Quelltext Quasi auch "Platformunabhängig"


Ja und evt. auch noch die halbe Methode/Funktion in der der API-Aufruf steht, weil der API-Aufruf X auf System A z.B. ein integer wert zurück gibt und auf System B einen Boolschen wert, oder halt die Signatur der API-Methode anders aussieht.


Du hast weiter oben geschrieben Perl soll eine "Compiler-Sprache" werden und seine Interpreter eigenschaften bewahren. Welche Interpreter eigenschaften meinst du genau?

Wenn du deine Perl-Programme Compilieren möchtest dann nutz doch sowas wie perlcc. Das macht genau das was du möchtest es Compiliert dein Perl-Script so das du es einfach anklicken kannst ohne in der Konsole/Eingabeaufforderung per.exel Script.pl einzugeben.

Oder, wie schon erwähnt, setzte das Ausführungsbit (bei Unix-Systemen) oder Verknüpfe die Dateiendung mit dem Perlinterpreter, dann kannst/solltest du das Perlscript durch einfaches anklicken auch starten können.

Das Problem ist ja, ich finde perlcc bei mir nirgends! Weder im Path, noch bei perl/bin/perlcc.exe! Und im Internet hab ich auch noch keinen download gefunden...

Die Verknüpfung mit dem Perl-Interpreter an sich ist ja eine schöne Idee, aber ich wollte das Programm auf eine andere Windows Plattform übertragen, auf dem kein Perl-Interprter installiert ist. Also bleibt nur noch perlcc, welches ich aber nicht finden kann.
mfg
TByte

Neben perlcc geibt es auch noch andere Tools, wie z.B. perl2exe(ist shareware) oder PAR. Diese Tools Compilieren dein Script aber nicht, sonden Packen es zusammen mit den Perlinterpreter in eine einzelene ausführbare Datei, so kannst du das Script auch auf system laufen lassen wo kein Perl installiert ist.

Die hab ich auch auf der suche entdeckt...
aber wie gesagt, perl2exe ist kostenpflichtig, und unter PAR hab ich nur irgendwelche dokus gefunde, keine downloads. :-(
mfg
TByte

Hab mir mal das PAR ding angetan und downgeloadet. leider leider habe ich nix gefunden, was irgendwie für Windows zu gebrauchen wäre. dann bin ich dem Link zu pp gefolgt, habe aber auch dort nix brauchbares finden können. Wie muss ich denn was machen? Also die dokus hab ich glesen, aber ich glaub die waren nur für linux.
Kennt jemdan einen Link zu PAR für Windows? Google brachte auch nix.
mfg
TByte

Du wirst auch keine Binarys von pp für Windows finden, weil pp eine PerlModule (url=http://search.cpan.org/src/SMUELLER/PAR-Packer-0.982/lib/pp.pm]Source[/url]) ist.

Du musst dir das Package PAR installieren, dass kannst du mit dem ppm machen welcher bei ActivePerl mit dabei ist, ich vermute mal du nutzt ActivePerl. Ansonsten musst du dir von z.B. hier:
http://ppm.activestate.com/PPMPackages/zips/
dir die entsprechenden Perl-Module besorgen uns sie selbst installieren.

Joa ne, hab ActivePerl, funtzt auch supi, bin zufrieden damit.
---
OK, hab das jetzt installiert. Und jetzt die Doku durchlesen und den Beipspielcode, der da gezeigt ist, in die Konsole tippen?
mfg
TByte

Supi, vielen dank für deine Bemühungen
mfg
TByte

Nochmal zu den Interpretern:
Wenn eine Interpretersprache es nicht zulässt, dass man für sie eine Compiler-Sprachen-Bibliothek (C/C++) entwickelt, dann ist diese relativ nutzlos, da man eben nicht die Vorteile von Systemen nutzen kann! Wenn man z.B. in Java eine Anwendung für Windows entwickeln will, die besondere Windows Features nutzt, dann muss man auf die API verzichten, weil eben die Sprache unabhängig sein soll. Und ausserdem wurde kein Programm, was ich jemals für ein Desktop-OS gesehene habe, in Java entwickelt...
Und ausserdem ist das OOP-Konzept von C#/Java einfach nur übertrieben. Und deshalb:
Für den Anfänger, wer Java/C# enpfiehlt, ist echt verrückt. Da eignet sich ja C/C++ besser! Und rein syntaktisch gesehen ist die C/C++/C#/Java und der Rest, der an diese Syntax angelehnt ist, ist viel viel viel LOGISCHER als irgendwelche BASIC, PASCAL und PERL dinger...
mfg
TByte