On Son, 11 Mai 2003 at 07:18 (+0200), Bernd Brodesser wrote:

* Erich Lindner schrieb am 10.Mai.2003:

...

ich hab ein C-Programm, das wiederum Perl-Code generiert. Nun moechte ich diesen Code an den Perl-Interpreter pipen.

"programm | /usr/bin/perl -"

allerdings sollte das auszufuehrende Perl-Programm die "STDIN" von dem C-Programm vererbt bekommen. Da die Pipe zwischen dem C-Programm und dem Perl-Interpreter und nicht zum eigentlichen Perl-Programm aufgebaut wird, kann dieses jedoch nicht auf die STDIN des C-Programms zugreifen.

Ich habe auch die Moglichkeit mittels "popen()" im C-Programm selbst eine Pipe zum Perl-Interpreter aufzubauen. Gibt es dann eine Moeglichkeit, zB: als Argument dem Perlprogramm die STDIN aus dem C-Programm heraus mitzuteilen, und wenn, kann dann das Perl-Programm darauf zugreifen, obwohl das C-Programm sich nach dem Abladen des Codes beendet ?

Du kannst eine Named Pipe erzeugen, oder Du kannst weitere Directiven erzeugen. Ob das alles so Sinnig ist, weiß ich allerdings nicht.

Erich, ehrlich gesagt weiss ich auch nicht, was Du da bauen willst. Die Kommunikation per Pipe, so wie Du sie beschreibst (programm | perl -) verknüpft ja auch nicht stdin des C-Progrmms mit stdin von Perl, sondern _stdout_! Korrigier mich, wenn ich falsch liege, aber für mich sieht es so aus, dass Du offenbar das C-Programm nur als Wrapper um einen dynamisch generierten Perl-Code herum haben willst. Dann wäre IMHO der einzige Weg, dass Du wie von Bernd vorgeschlagen eine Named Pipe nutzt und diese im Perl-Code anstelle von stdin nutzt. Das Ganze würde ich dann aber nicht per Pipe verknüpfen, sondern den Perl-Interpreter per fork () starten und per dup () mit der Ausgabe des C-Programms versorgen. Wenn Du mal genauer schilderst, was Du vorhast, lässt sich vielleicht ein einfacherer Weg finden. Jan

Hallo, [XMailed & f'up to suse-programming@suse.com] On Mon, 12 May 2003, Erich Lindner wrote:

Jan Trippler wrote:

...

Wenn Du mal genauer schilderst, was Du vorhast, lässt sich vielleicht ein einfacherer Weg finden. [..] Prinzipell geht es um einen Schutzmechanismus, um Perl-Code wirksam zu schuetzen, damit dieser nicht eingesehen werden kann. [..] Also hab ich mir ein C-Programm geschrieben, mit dessen Hilfe ich verschluesselte Perl-Programme ausfuehren kann. Das heist, ich habe immer ein Programm-Paar: "Programm" -> das C-Programm "Programm.dat" -> der verschluesselte Perl-Code

Du willst dir Filter::* anschauen ;) Du koenntest dann z.B. das "entschluesseln" in perl oder C als filter implementieren... [..]

Nun der Schoenheitsfehler: Wenn das C-Programm als CGI-Programm aufgerufen wird, und Furmulardaten mit der standardmaesigen Sendemethode "GET" uebermittelt werden klappt noch alles. Bei groesseren Formularen wird aber fuer gewoehnlich die Sendemethode "POST" benutzt, wobei die Formulardaten dann dem CGI-Programm auf "STDIN" uebermittelt werden. Nun ist das C-Programm aber nicht das eigentliche CGI-Programm, sondern der auszufuehrende Perl-Code.

Du wirst IMO nicht darum herumkommen, eine Datei zu verwenden, entweder fuer den perl-code oder fuer die Daten, oder ein Filter:: Modul zu implementieren... Oh, halt, du kannst wohl auch vielleicht noch mit Dateidescriptoren tricksen oder den code via -e als Argument an perl uebergeben. Ich denke, ein Filter::-Modul ist fuer dich am ehesten geeignet, siehe dazu perldoc Filter::decrypt: ==== DESCRIPTION This is a sample decrypting source filter. Although this is a fully functional source filter and it does implement a very simple decrypt algorithm, it is not intended to be used as it is supplied. Consider it to be a template which you can combine with a proper decryption algorithm to develop your own decryption filter. ==== Achso, grad seh ich: Filter::CBC bringt wohl schon Filter fuer Blowfish, Idea, Rijndael (AES), Twofish, DES, u.a. mit... -dnh -- Das kommt davon, wenn man bei dem regenwetter keine Mütze aufzieht. Dann weicht bei vielen das Gehirn auf. [WoKo in dag°]

Hallo, On Mon, 12 May 2003, Jan Trippler wrote:

On Mon, 12 Mai 2003 at 19:05 (+0200), Erich Lindner wrote: [C-Wrapper um verschlüsseltes Perl-Script] [..] Ich sehe 2 Varianten: - Öffne im Perl-Script nicht stdin, sondern eine named Pipe. Öffne im C-Programm die gleiche named Pipe und schicke stdin in diese Pipe.

Sollte gehen. ======== $ mknod -m 600 PERLFIFO p $ cat ./perlfifo.c #include #define FIFO "PERLFIFO" #define PERLCODE "print \"BEGIN\\n\";\n"\ "open(F,\"<./PERLFIFO\") or die $!;\n"\ "while(<F>) { print; }\n"\ "close(F);\n"\ "print \"END\\n\";\n" int main(void) { FILE * perl; fprintf(stdout, "%s\n", PERLCODE); fflush(stdout); fclose(stdout); if( (perl = fopen(FIFO, "w")) != NULL ) { fprintf(perl, "test\n"); } fflush(perl); fclose(perl); return 0; } $ gcc -Wall -W -ansi -pedantic -o perlfifo perlfifo.c $ ./perlfifo | perl BEGIN test END $ ======== Und ja, wie's scheint ist die Reihenfolge wichtig: Erst den perl-code nach stdout (zu perl) schreiben und stdout schliessen, _dann_ die named pipe zum perlcode oeffnen, schreiben und schliessen...

- die perverse Methode: Hänge alles, was das C-Programm per stdin gekriegt hat, als __DATA__ Sektion an das Perlscript an, das kannst Du dann über <DATA> lesen (dieser Kanal ist offen).

Wueso is das pervers? Ist doch schick ;) Zumindest solange das perlscript eh immer generiert wird sprich nix dagegen, da jeweils auch noch die Daten in __DATA__ anzuhaengen ;) ======== $ cat perldata.c #include #define PERLCODE "print \"BEGIN\\n\";\n"\ "while(<DATA>) { print; }\n"\ "print \"END\\n\";\n"\ "__DATA__\n"\ "test" int main(void) { fprintf(stdout, "%s\n", PERLCODE); /* fflush(stdout); fclose(stdout); */ return 0; } $ gcc -Wall -W -ansi -pedantic -o perldata perldata.c $ ./perldata | perl BEGIN test END ======== Achso, ich wuerde wohl die Variante mit den FIFO vorziehen, das ist wohl flexibler... ;) Und dann gibt's da natuerlich die schon nebenan erwaehnte Version mit Filter::* ;) -dnh -- [...] Natuerlich aus LaTeX. Alle richtigen Maenner verwenden LaTeX. Peter 'g' Bouillon in <6apv1b$jga@hades.rz.uni-sb.de>