IPC::Open2, Windows: Eingabe-Umleitung tut nicht

Hallo,

ich habe ein Konsolen-Programm, das seine Eingaben von der
Standardeingabe holt und auf der Standardausgabe ausgibt - und zwar lt.
Dokumentation, ohne irgendwo zu puffern. So weit, so gut.

Dieses Programm soll aus einem Perl-Skript heraus aufgerufen werden,
seine Eingabe von dort beziehen und seine Ausgabe dorthin zur weiteren
Verarbeitung schicken. Mit einem Python-Skript als aufrufendem Programm
funktioniert das tadellos, aber für einen bestimmten Anwendungsfall muss
es Perl sein.

Google und die Perl-Dokumentation teilen mir mit, hier sei IPC::Open2
(oder IPC::Open3) geeignet. Nachdem meine ersten Versuche nur Hänger
lieferten, versuche ich erst mal, ein selbstgeschriebenes Mini-Skript
aufzurufen, aber damit klappt es auch nicht (die Details zu "klappt
nicht" kommen schon noch).

Das aufrufende Programm:

#!/usr/bin/perl -w
# open2_test.pl

use strict;
use IPC::Open2;

my (@result);
# Pfadangabe für Windows
my $prog = 'G:\LinWin\Perl\stdio_test.pl';
# Pfadangabe für Linux
# my $prog = '/media/hda6/LinWin/Perl/stdio_test.pl';
my $pid = open2(\*READER, \*WRITER, $prog) or die $!;
print WRITER ("Dies ist ein Test\nUnd noch einer\n");
close(WRITER);
@result = ;
close(READER);
waitpid($pid, 0);
print "Ergebnis: *@result*\n";

Und das aufgerufene Mini-Skript:

#!/usr/bin/perl -w
# stdio_test.pl

use strict;

my(@input);
$| = 1; # Ausgabe Puffer abschalten
@input = <>;
# Zum Testen: Empfangene Eingabe in Datei schreiben
# open(AUS, ">G:\\LinWin\\Perl\\iotest.txt");
open(AUS, ">/media/hda6/LinWin/Perl/iotest.txt");
print AUS ("*@input*\n");
close(AUS);
print("Eingabe war *@input*\n");

Ergebnis: unter Linux genau das, was ich erwartet habe: stdio_test.pl
schreibt in die Datei:

*Dies ist ein Test
Und noch einer
*

Und open2_test.pl gibt aus:

Ergebnis: *Eingabe war *Dies ist ein Test
Und noch einer
*
*

Wunderhübsch. Nützt mir nur leider nichts, weil das eigentlich zu
steuernde Programm nur unter Windows läuft. Und dort schreibt
stdio_test.pl in die Datei: "**\n", und entsprechend gibt open2_test.pl
aus: "Eingabe war **\n". Bisschen wenig.

Offensichtlich kommt also die Eingabe nicht ins aufgerufene Programm.
Für WRITER die Pufferung abzustellen, habe ich schon versucht:
select(WRITER);
$| = 1;
select(STDOUT);
Kein sichtbarer Effekt.

Was mache ich falsch (außer Windows zu benutzen - geht im konkreten Fall
aber nicht anders, siehe oben)? ActivePerl 5.8, Windows XP Professional.

Danke für jeden Hinweis,
Hertha

Re: IPC::Open2, Windows: Eingabe-Umleitung tut nicht

Hertha Steck wrote:

> Was mache ich falsch (außer Windows zu benutzen - geht im konkreten Fall
> aber nicht anders, siehe oben)? ActivePerl 5.8, Windows XP Professional.

Aus perlipc:

The open2() and open3() functions are unlikely to work
anywhere except on a Unix system or some other one purporting to be
POSIX compliant.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: IPC::Open2, Windows: Eingabe-Umleitung tut nicht

Hertha Steck schrieb:
> Hallo,
>
> ich habe ein Konsolen-Programm, das seine Eingaben von der
> Standardeingabe holt und auf der Standardausgabe ausgibt - und zwar lt.
> Dokumentation, ohne irgendwo zu puffern. So weit, so gut.
>
> Dieses Programm soll aus einem Perl-Skript heraus aufgerufen werden,
> seine Eingabe von dort beziehen und seine Ausgabe dorthin zur weiteren
> Verarbeitung schicken. Mit einem Python-Skript als aufrufendem Programm
> funktioniert das tadellos, aber für einen bestimmten Anwendungsfall muss
> es Perl sein.
>
> Google und die Perl-Dokumentation teilen mir mit, hier sei IPC::Open2
> (oder IPC::Open3) geeignet. Nachdem meine ersten Versuche nur Hänger
> lieferten, versuche ich erst mal, ein selbstgeschriebenes Mini-Skript
> aufzurufen, aber damit klappt es auch nicht (die Details zu "klappt
> nicht" kommen schon noch).
>
> Das aufrufende Programm:
>
> #!/usr/bin/perl -w
> # open2_test.pl
>
> use strict;
> use IPC::Open2;
>
> my (@result);
> # Pfadangabe für Windows
> my $prog = 'G:\LinWin\Perl\stdio_test.pl';
> # Pfadangabe für Linux
> # my $prog = '/media/hda6/LinWin/Perl/stdio_test.pl';
> my $pid = open2(\*READER, \*WRITER, $prog) or die $!;
> print WRITER ("Dies ist ein Test\nUnd noch einer\n");
> close(WRITER);
> @result = ;
> close(READER);
> waitpid($pid, 0);
> print "Ergebnis: *@result*\n";
>
> Und das aufgerufene Mini-Skript:
>
> #!/usr/bin/perl -w
> # stdio_test.pl
>
> use strict;
>
> my(@input);
> $| = 1; # Ausgabe Puffer abschalten
> @input = <>;
> # Zum Testen: Empfangene Eingabe in Datei schreiben
> # open(AUS, ">G:\\LinWin\\Perl\\iotest.txt");
> open(AUS, ">/media/hda6/LinWin/Perl/iotest.txt");
> print AUS ("*@input*\n");
> close(AUS);
> print("Eingabe war *@input*\n");
>
> Ergebnis: unter Linux genau das, was ich erwartet habe: stdio_test.pl
> schreibt in die Datei:
>
> *Dies ist ein Test
> Und noch einer
> *
>
> Und open2_test.pl gibt aus:
>
> Ergebnis: *Eingabe war *Dies ist ein Test
> Und noch einer
> *
> *
>
> Wunderhübsch. Nützt mir nur leider nichts, weil das eigentlich zu
> steuernde Programm nur unter Windows läuft. Und dort schreibt
> stdio_test.pl in die Datei: "**\n", und entsprechend gibt open2_test.pl
> aus: "Eingabe war **\n". Bisschen wenig.
>
> Offensichtlich kommt also die Eingabe nicht ins aufgerufene Programm.
> Für WRITER die Pufferung abzustellen, habe ich schon versucht:
> select(WRITER);
> $| = 1;
> select(STDOUT);
> Kein sichtbarer Effekt.
>
> Was mache ich falsch (außer Windows zu benutzen - geht im konkreten Fall
> aber nicht anders, siehe oben)? ActivePerl 5.8, Windows XP Professional.

Die Eingabe kommt an. U. a. solltes Du
my $prog = 'perl G:\LinWin\Perl\stdio_test.pl';
benutzen, da "#!/usr/bin/perl -w" unter Win32 nicht das macht, was Du
erwartest. Außerdem halte ich @foo = <> für den Test ungünstig.
Folgendes funktioniert ohne Probleme unter Win32:

# a.pl #######################################
use strict;
use IPC::Open2;

my $pid = open2(*R, *W, 'perl b.pl') or die $!;

print W "Dies ist ein Test\nUnd noch einer\n";
close W;

while ( ) {
s/\s+$//;
print "Ergebnis: *$_*\n";
}
close R;

# b.pl ########################################
use strict;
$| = 1;

print "Eingabe war: $_" while <>;


Gruß,
Peter

Re: IPC::Open2, Windows: Eingabe-Umleitung tut nicht

Frank Seitz schrieb:
> Hertha Steck wrote:
>
>> Was mache ich falsch (außer Windows zu benutzen - geht im konkreten Fall
>> aber nicht anders, siehe oben)? ActivePerl 5.8, Windows XP Professional.
>
> Aus perlipc:
>
> The open2() and open3() functions are unlikely to work
> anywhere except on a Unix system or some other one purporting to be
> POSIX compliant.
>
Vielleicht wäre eine Pipe die Lösung?

Win32::Pipe

Gruß, Bianka

Re: IPC::Open2, Windows: Eingabe-Umleitung tut nicht

Frank Seitz schrieb:
> Hertha Steck wrote:
>
>> Was mache ich falsch (außer Windows zu benutzen - geht im konkreten Fall
>> aber nicht anders, siehe oben)? ActivePerl 5.8, Windows XP Professional.
>
> Aus perlipc:
>
> The open2() and open3() functions are unlikely to work
> anywhere except on a Unix system or some other one purporting to be
> POSIX compliant.
>
Bezieht sich das auf IPC::Open2 und IPC::Open3? An diesem Punkt bin ich
aus der Dokumentation nicht schlau geworden.

Gruß,
Hertha

Re: IPC::Open2, Windows: Eingabe-Umleitung tut nicht

Bianka Martinovic schrieb:
> Frank Seitz schrieb:
>> Hertha Steck wrote:
>>
>>> Was mache ich falsch (außer Windows zu benutzen - geht im konkreten
>>> Fall aber nicht anders, siehe oben)? ActivePerl 5.8, Windows XP
>>> Professional.
>>
>> Aus perlipc:
>>
>> The open2() and open3() functions are unlikely to work
>> anywhere except on a Unix system or some other one purporting to be
>> POSIX compliant.
>>
> Vielleicht wäre eine Pipe die Lösung?
>
> Win32::Pipe
>
Das ist für Named Pipes zuständig - da muss aber der Server mitspielen,
und das tut er nicht.

Kennt sich jemand mit Win32::Job aus? Der Beschreibung nach könnte das
evtl. was für mich sein, aber mir wird nicht klar, wie der Modul benutzt
wird.

Dank und Gruß,
Hertha

Re: IPC::Open2, Windows: Eingabe-Umleitung tut nicht

On 2007-06-22 19:30, Hertha Steck wrote:
> Frank Seitz schrieb:
>> Hertha Steck wrote:
>>> Was mache ich falsch (außer Windows zu benutzen - geht im konkreten Fall
>>> aber nicht anders, siehe oben)? ActivePerl 5.8, Windows XP Professional.
>>
>> Aus perlipc:
>>
>> The open2() and open3() functions are unlikely to work
>> anywhere except on a Unix system or some other one purporting to be
>> POSIX compliant.
>>
> Bezieht sich das auf IPC::Open2 und IPC::Open3?

Nachdem der nächste Absatz lautet:

Here’s an example of using open2():

use FileHandle;
use IPC::Open2;
$pid = open2(*Reader, *Writer, "cat -u -n" );

und mir sonst kein open2 und open3 bekannt sind außer eben die in
IPC::Open2 bzw. IPC::Open3 definierten Funktionen, würde ich das schwer
annehmen.

Allerdings findet Google etwas, das behauptet Doku von ActiveState Perl
zu sein, und in dem steht, dass IPC::Open2 unter Windows unterstützt wird:

http://www.xav.com/perl/lib/IPC/Open2.html

Auf http://aspn.activestate.com/ ist hingegen nur die normale
perldoc-Seite zu finden.

hp


--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"

Re: IPC::Open2, Windows: Eingabe-Umleitung tut nicht

Peter Arnhold schrieb:
> Hertha Steck schrieb:
>> Hallo,
>>
>> ich habe ein Konsolen-Programm, das seine Eingaben von der
>> Standardeingabe holt und auf der Standardausgabe ausgibt - und zwar lt.
>> Dokumentation, ohne irgendwo zu puffern. So weit, so gut.
>>
>> Dieses Programm soll aus einem Perl-Skript heraus aufgerufen werden,
>> seine Eingabe von dort beziehen und seine Ausgabe dorthin zur weiteren
>> Verarbeitung schicken. Mit einem Python-Skript als aufrufendem Programm
>> funktioniert das tadellos, aber für einen bestimmten Anwendungsfall muss
>> es Perl sein.
>>
>>
>> Wunderhübsch. Nützt mir nur leider nichts, weil das eigentlich zu
>> steuernde Programm nur unter Windows läuft. Und dort schreibt
>> stdio_test.pl in die Datei: "**\n", und entsprechend gibt open2_test.pl
>> aus: "Eingabe war **\n". Bisschen wenig.
>>
>> Offensichtlich kommt also die Eingabe nicht ins aufgerufene Programm.
>>
>> Was mache ich falsch (außer Windows zu benutzen - geht im konkreten Fall
>> aber nicht anders, siehe oben)? ActivePerl 5.8, Windows XP Professional.
>
> Die Eingabe kommt an. U. a. solltes Du
> my $prog = 'perl G:\LinWin\Perl\stdio_test.pl';
> benutzen, da "#!/usr/bin/perl -w" unter Win32 nicht das macht, was Du
> erwartest. Außerdem halte ich @foo = <> für den Test ungünstig.

Dass die Shebang-Zeile unter Windows nicht wirkt, ist mir schon klar.
Ich dachte, es reicht, dass .pl eine registrierte Datei-Endung ist; Du
hast aber recht, das reicht nicht. Allerdings verstehe ich dann eins
nicht: das aufgerufene Skript schreibt ja seine Protokolldatei (es
schreibt halt nur nicht die Eingabe aus dem aufrufenden Skript nicht
hinein, sondern nur seine umgebenden zwei Sternchen), also wird es doch
aufgerufen?!?

> Folgendes funktioniert ohne Probleme unter Win32:
>
> # a.pl #######################################
> use strict;
> use IPC::Open2;
>
> my $pid = open2(*R, *W, 'perl b.pl') or die $!;
>
> print W "Dies ist ein Test\nUnd noch einer\n";
> close W;
>
> while ( ) {
> s/\s+$//;
> print "Ergebnis: *$_*\n";
> }
> close R;
>
> # b.pl ########################################
> use strict;
> $| = 1;
>
> print "Eingabe war: $_" while <>;
>

Das hat bei mir noch immer einen Haken: ich kann a.pl nur mit Ctrl-C
gewaltsam abbrechen. Aber immerhin, der Text aus a.pl kommt in b.pl an,
wird mit "Eingabe war: " garniert und kommt wieder zurück. Das ist ein
entschiedener Fortschritt und zeigt, dass IPC::Open2 wohl doch nicht die
ganz falsche Richtung ist.

Dank und Gruß,
Hertha

Re: IPC::Open2, Windows: Eingabe-Umleitung tut nicht

Hertha Steck schrieb:
[...]
> Dass die Shebang-Zeile unter Windows nicht wirkt, ist mir schon klar.
> Ich dachte, es reicht, dass .pl eine registrierte Datei-Endung ist; Du
> hast aber recht, das reicht nicht. Allerdings verstehe ich dann eins
> nicht: das aufgerufene Skript schreibt ja seine Protokolldatei (es
> schreibt halt nur nicht die Eingabe aus dem aufrufenden Skript nicht
> hinein, sondern nur seine umgebenden zwei Sternchen), also wird es doch
> aufgerufen?!?

Nein.
Nur weil READER sofort geschlossen wird, da das gerufene Programm nicht
ausführbar ist, kommst Du überhaupt nur an @result = ; vorbei.

Mache den Test ohne shell:
my $pid = open2(*R, *W, 'perl', 'b.pl')
und kille das Programm mit der $pid. Dann bekommst Du deine Ausgabe (mit b.pl).

> Das hat bei mir noch immer einen Haken: ich kann a.pl nur mit Ctrl-C
> gewaltsam abbrechen. Aber immerhin, der Text aus a.pl kommt in b.pl an,

Das ist unter Win32 in der Tat ein Problem. Du kannst über einen kleinen Umweg
versuchen, weiter zu kommen, etwa in der Art:

# a.pl

use strict;
use IPC::Open2;
use Win32::API;
use Win32API::File;

$|=1;

my $pid = open2(*R, *W, 'perl', 'b.pl') or die;

print W "Dies ist ein Test\nUnd noch einer\n";

#####################################################
my @param = qw(kernel32 PeekNamedPipe NPNPPP N);
my $PeekNamedPipe = Win32::API->new( @param ) or die;

my $line = '';
my $l = pack 'V', 0;
my $osfh = Win32API::File::GetOsFHandle(\*R) or die;

for (1..5) {
$PeekNamedPipe->Call($osfh,0,0,0,$l,0) or die;

my $buff = '';
if (my $_l = unpack 'V', $l) {
sysread R, $buff, $_l;
$line .= $buff;
}
else {
sleep 1;
}
} ####################################################

# kill 9, $pid;

print "Ergebnis: $line\n";

Gruß,
Peter

Re: IPC::Open2, Windows: Eingabe-Umleitung tut nicht

"Peter J. Holzer" schrieb im Newsbeitrag
news:slrnf7pr5k.8fp.hjp-usenet2@zeno.hjp.at...
> On 2007-06-22 19:30, Hertha Steck wrote:
>> Frank Seitz schrieb:
>>> Hertha Steck wrote:
>>>> Was mache ich falsch (außer Windows zu benutzen - geht im konkreten
>>>> Fall
>>>> aber nicht anders, siehe oben)? ActivePerl 5.8, Windows XP
>>>> Professional.
>>>
>>> Aus perlipc:
>>>
>>> The open2() and open3() functions are unlikely to work
>>> anywhere except on a Unix system or some other one purporting to be
>>> POSIX compliant.
>>>
>> Bezieht sich das auf IPC::Open2 und IPC::Open3?
>
> Nachdem der nächste Absatz lautet:
>
> Here’s an example of using open2():
>
> use FileHandle;
> use IPC::Open2;
> $pid = open2(*Reader, *Writer, "cat -u -n" );
>
> und mir sonst kein open2 und open3 bekannt sind außer eben die in
> IPC::Open2 bzw. IPC::Open3 definierten Funktionen, würde ich das schwer
> annehmen.
>
> Allerdings findet Google etwas, das behauptet Doku von ActiveState Perl
> zu sein, und in dem steht, dass IPC::Open2 unter Windows unterstützt wird:

Im Source von IPC::Open3 findet sich "$^O eq 'MSWin32'", allerdings meist
indirekt: "my $do_spawn = $^O eq 'os2' || $^O eq 'MSWin32';". Also wird es
wohl unterstützt. Eine Einschränkung steht im POD:
| Note if you specify C<-> as the command, in an analogous fashion to
| C the child process will just be the forked Perl
| process rather than an external command. This feature isn't yet
| supported on Win32 platforms.

IPC::Open2 ruft IPC::Open3:
| This function is really just a wrapper around open3().

perl -v --> This is perl, v5.8.4 built for MSWin32-x86-multi-thread ...
Binary build 810 provided by ActiveState Corp.

Windows XP Home mit SP2.

Gruß

Klaus

Re: IPC::Open2, Windows: Eingabe-Umleitung tut nicht

Peter Arnhold schrieb:
> Das ist unter Win32 in der Tat ein Problem. Du kannst über einen kleinen Umweg
> versuchen, weiter zu kommen, etwa in der Art:
>
> # a.pl
>
> use strict;
> use IPC::Open2;
> use Win32::API;
> use Win32API::File;
>
> $|=1;
>
> my $pid = open2(*R, *W, 'perl', 'b.pl') or die;
>
> print W "Dies ist ein Test\nUnd noch einer\n";
>
> #####################################################
> my @param = qw(kernel32 PeekNamedPipe NPNPPP N);
> my $PeekNamedPipe = Win32::API->new( @param ) or die;
>
> my $line = '';
> my $l = pack 'V', 0;
> my $osfh = Win32API::File::GetOsFHandle(\*R) or die;
>
> for (1..5) {
> $PeekNamedPipe->Call($osfh,0,0,0,$l,0) or die;
>
> my $buff = '';
> if (my $_l = unpack 'V', $l) {
> sysread R, $buff, $_l;
> $line .= $buff;
> }
> else {
> sleep 1;
> }
> } ####################################################
>
> # kill 9, $pid;
>
> print "Ergebnis: $line\n";
>
> Gruß,
> Peter
>

Das funktioniert, so wie es da steht. Verstanden habe ich es noch nicht,
aber ich habe mir die Dokumentation zu WIN32::API auch noch nicht
angesehen. Wenn ich das getan habe, werde ich möglicherweise begreifen,
warum es zwar mit b.pl geht, nicht aber mit dem Programm, das ich
eigentlich steuern will (und auf das ich natürlich keinen Einfluss habe).

Aber eins ist arg seltsam: das Skript läuft, und es endet auch scheinbar
ganz normal. Aber danach kann ich die Eingabeaufforderung nicht mehr
normal mit dem Befehl "exit" schließen. Strg-Untbr geht, das Systemmenü
des Fensters tut es auch, im Taskmanager heißt es "Wird ausgeführt",
aber auf "exit" gibt es keine Reaktion.

Ein bisschen frustriert bin ich schon: es war überhaupt kein Problem,
das entsprechende Skript in Python zu schreiben (ohne spezielle
Windows-Verrenkungen). Es war etwas schwieriger in Delphi 6, ging nicht
ganz ohne einiges Googeln. Wieder einfacher mit Delphi 2006 als
..NET-Projekt. Wieso ist das jetzt plötzlich mit Perl so ein Theater???

Ich würde es ja bleiben lassen, aber ich habe leichtsinnige
Ankündigungen gemacht für eine Stelle, an der nur Perl benutzt wird und
nicht Python. Weil ich selbstverständlich der Meinung war, was in der
einen Sprache leicht geht, das wird in der anderen vielleicht hässlich,
aber nicht so viel schwieriger.

Jedenfalls vielen Dank,
Hertha

Re: IPC::Open2, Windows: Eingabe-Umleitung tut nicht

Hallo Hertha,

Hertha Steck schrieb:
> Peter Arnhold schrieb:
>> Das ist unter Win32 in der Tat ein Problem. Du kannst über einen
>> kleinen Umweg
>> versuchen, weiter zu kommen, etwa in der Art:
>>
>> # a.pl
>>
>> use strict;
>> use IPC::Open2;
>> use Win32::API;
>> use Win32API::File;
>>
>> $|=1;
>>
>> my $pid = open2(*R, *W, 'perl', 'b.pl') or die;
>>
>> print W "Dies ist ein Test\nUnd noch einer\n";
>>
>> #####################################################
>> my @param = qw(kernel32 PeekNamedPipe NPNPPP N);
>> my $PeekNamedPipe = Win32::API->new( @param ) or die;
>>
>> my $line = '';
>> my $l = pack 'V', 0;
>> my $osfh = Win32API::File::GetOsFHandle(\*R) or die;
>>
>> for (1..5) {
>> $PeekNamedPipe->Call($osfh,0,0,0,$l,0) or die;
>>
>> my $buff = '';
>> if (my $_l = unpack 'V', $l) {
>> sysread R, $buff, $_l;
>> $line .= $buff;
>> }
>> else {
>> sleep 1;
>> }
>> } ####################################################
>>
>> # kill 9, $pid;
>>
>> print "Ergebnis: $line\n";
>>
>> Gruß,
>> Peter
>>
>
> Das funktioniert, so wie es da steht. Verstanden habe ich es noch nicht,
> aber ich habe mir die Dokumentation zu WIN32::API auch noch nicht
> angesehen. Wenn ich das getan habe, werde ich möglicherweise begreifen,
> warum es zwar mit b.pl geht, nicht aber mit dem Programm, das ich
> eigentlich steuern will (und auf das ich natürlich keinen Einfluss habe).

Das geht nicht nur mit b.pl. Geht auch mit einem *.bat oder jedem anderen
Programm, dass ungepuffert über STDOUT schreibt. Ein kleine Änderung ist noch
nötig, falls das Programm vor a.pl endet:
$PeekNamedPipe->Call($osfh,0,0,0,$l,0) or last;
^^^^^^^^
Der Aufruf geht sonst ins Leere, wenn R geschlossen wurde und "die" ist da blöd.

Ich habe dir das Ganze mal modifiziert, dass Du nachvollziehen kannst, wann was
passiert. Und so wie mit b.bat sollte es auch mit deinem Programm gehen.

######################
b.bat

@echo off
echo Das ist ein Test.
pause
echo "hello world"
######################

# a.pl
[...]
my $pid = open2(*R, *W, 'b.bat') or die;
[...]
for (1..5) {
$PeekNamedPipe->Call($osfh,0,0,0,$l,0) or last;

my $buff = '';
if (my $_l = unpack 'V', $l) {
sysread R, $buff, $_l;

print "READER: $buff\n";

if ( $buff =~ /Taste/ ) {
sleep 2;
print "WRITER: \\n\n";
print W "\n";
}
}
else {
sleep 1;
}
}
Ausgabe:
READER (58): Das ist ein Test.
Drücken Sie eine beliebige Taste . . .
WRITER: \n
READER (17):
"hello world"

> Aber eins ist arg seltsam: das Skript läuft, und es endet auch scheinbar
> ganz normal. Aber danach kann ich die Eingabeaufforderung nicht mehr
> normal mit dem Befehl "exit" schließen. Strg-Untbr geht, das Systemmenü
> des Fensters tut es auch, im Taskmanager heißt es "Wird ausgeführt",
> aber auf "exit" gibt es keine Reaktion.

Das liegt daran, dass a.pl b.pl startet und b.pl noch läuft. Mit dem "kill 9,
$pid" in meinem Beispiel, also dem Beenden von b.pl, kannst Du auch das exit
anwenden. Das kill solltest Du aber nicht brauchen, wenn sich dein Programm
selbst beendet. Siehe obiges Beispiel.

> Ein bisschen frustriert bin ich schon: es war überhaupt kein Problem,
> das entsprechende Skript in Python zu schreiben (ohne spezielle
> Windows-Verrenkungen). Es war etwas schwieriger in Delphi 6, ging nicht
> ganz ohne einiges Googeln. Wieder einfacher mit Delphi 2006 als
> .NET-Projekt. Wieso ist das jetzt plötzlich mit Perl so ein Theater???

Weil IPC unter Win32 nicht immer so elegant geht wie in anderen Sprachen? Weil
nicht jede Sprache für alle Aufgaben gleichermaßen anwendbar ist? Weil Du das
ausgesprochene Pech hattest, nicht zu wissen, was dich erwartet, als Du eine
Lösung in Perl angekündigt hast?

Gruß,
Peter

Re: IPC::Open2, Windows: Eingabe-Umleitung tut nicht

Peter Arnhold schrieb:
>
> Das geht nicht nur mit b.pl. Geht auch mit einem *.bat oder jedem anderen
> Programm, dass ungepuffert über STDOUT schreibt. Ein kleine Änderung ist noch
> nötig, falls das Programm vor a.pl endet:
> $PeekNamedPipe->Call($osfh,0,0,0,$l,0) or last;
> ^^^^^^^^
> Der Aufruf geht sonst ins Leere, wenn R geschlossen wurde und "die" ist da blöd.
>
> Ich habe dir das Ganze mal modifiziert, dass Du nachvollziehen kannst, wann was
> passiert. Und so wie mit b.bat sollte es auch mit deinem Programm gehen.
>
> ######################
> b.bat
>
> @echo off
> echo Das ist ein Test.
> pause
> echo "hello world"
> ######################
>
> # a.pl
> [...]
> my $pid = open2(*R, *W, 'b.bat') or die;
> [...]
> for (1..5) {
> $PeekNamedPipe->Call($osfh,0,0,0,$l,0) or last;
>
> my $buff = '';
> if (my $_l = unpack 'V', $l) {
> sysread R, $buff, $_l;
>
> print "READER: $buff\n";
>
> if ( $buff =~ /Taste/ ) {
> sleep 2;
> print "WRITER: \\n\n";
> print W "\n";
> }
> }
> else {
> sleep 1;
> }
> }
> Ausgabe:
> READER (58): Das ist ein Test.
> Drücken Sie eine beliebige Taste . . .
> WRITER: \n
> READER (17):
> "hello world"

Jetzt habe ich zwar halbwegs begriffen, was dieses Programm tut. Aber es
trifft leider nicht zu, dass es mit jedem Programm funktioniert, das
ungepuffert über STDOUT schreibt. Und ich kann absolut nicht verstehen,
warum nicht.

Was ich brauche: das "innere Programm" bekommt seine Eingabe,
verarbeitet sie, schreibt das Ergebnis über STDOUT raus (ungepuffert lt.
Dokumentation), beendet sich. In dieser Reihenfolge (das ist also etwas
anders als b.bat, wo zuerst geschrieben wird). Deshalb am Anfang

print W "Dies ist ein Test\nUnd noch einer\n";
close W;

Das "close W" habe ich ergänzt. Für die Version mit b.bat passt es
natürlich nicht. Ich habe wieder getestet mit meinem "stdio_test.pl",
das alle Eingaben, die es bekommt, in eine Datei schreibt und am Ende
mit Präfix garniert auf die Standardausgabe ausgibt. Die Datei wird
geschrieben und enthält, was sie enthalten soll. a.pl gibt nichts aus,
und das Skript beendet sich nicht selbst (wartet das immer noch auf eine
Eingabe, die nicht mehr kommt, oder was?).

Wenn ich das Programm einsetze, um das es wirklich geht, bekomme ich
ebenfalls keine Ausgabe und es beendet sich nicht selbst. Ich habe mal
zur weiteren Untersuchung die unpack-Anweisung aus der if-Abfrage
herausgenommen und "print $_l" eingesetzt: da kommt in jedem
Schleifendurchgang 0. Bei mehr Durchgängen übrigens genau so. Bei b.bat
ist das anders. Beim ersten Durchgang kommt auch da 0 (ob das
reproduzierbar ist?), nachher nicht mehr.

> Weil IPC unter Win32 nicht immer so elegant geht wie in anderen Sprachen? Weil
> nicht jede Sprache für alle Aufgaben gleichermaßen anwendbar ist? Weil Du das
> ausgesprochene Pech hattest, nicht zu wissen, was dich erwartet, als Du eine
> Lösung in Perl angekündigt hast?
>

Bisher habe ich die Unterschiede zwischen den paar wenigen Sprachen, die
ich kenne, nie als so groß empfunden. Was in der einen geht, geht auch
in der anderen, vielleicht ein bisschen eleganter, vielleicht ein
bisschen hässlicher, in jedem Fall in der unvertrauteren Sprache mit
mehr Sucherei verbunden. Gerade zwischen Perl und Python habe ich mehr
ästhetische Unterschiede zu sehen geglaubt (mal abgesehen von
objektorientierter Programmierung), und aus der Unix-Welt kommen sie
m.W. beide. Und dann ist gerade Perl doch angeblich eine "glue
language"? Kurz gesagt, dass ich ausgerechnet an diesem Punkt so auf die
Nase falle, hätte ich wirklich nicht gedacht.

Gruß,
Hertha

Re: IPC::Open2, Windows: Eingabe-Umleitung tut nicht

Hallo Peter und alle Mitleser,

Hertha Steck schrieb:
>
> Jetzt habe ich zwar halbwegs begriffen, was dieses Programm tut. Aber es
> trifft leider nicht zu, dass es mit jedem Programm funktioniert, das
> ungepuffert über STDOUT schreibt. Und ich kann absolut nicht verstehen,
> warum nicht.
>
> Was ich brauche: das "innere Programm" bekommt seine Eingabe,
> verarbeitet sie, schreibt das Ergebnis über STDOUT raus (ungepuffert lt.
> Dokumentation), beendet sich. In dieser Reihenfolge (das ist also etwas
> anders als b.bat, wo zuerst geschrieben wird). Deshalb am Anfang
>

Ich bin jetzt einen winzigen Schritt weiter: ich weiß, woran es fehlt.
Das "innere Programm" scheint wirklich nicht mitzukriegen, dass keine
Eingaben mehr kommen.

b.bat erwartet und bekommt genau einen Tastendruck als Eingabe, da gibt
es kein Problem. Ein Perl-Skript, das auf ein bestimmtes Ende-Zeichen in
der Eingabe prüft, und dem das äußere Skript eben dieses Zeichen
liefert: ebenfalls kein Problem. Ein Perl-Skript, das seine Eingaben in
einer Schleife "while (<>) { ... }" bekommt und verarbeitet: aus dieser
Schleife kommt es nicht heraus. Ein zusätzlich eingebautes "last if
(eof)" hilft da nicht. Ein explizites Anhängen von Ctrl-Z , also
"\x1a\n" an die Eingabe, analog zum Verfahren über die Tastatur, hilft
genau so wenig.

Und das Programm, das ich wirklich steuern will, verhält sich wie das
Perl-Skript mit der "while (<>)"-Schleife.

Da möchte man jetzt meinen, das Problem läge ausschließlich beim inneren
Programm, aber das kann so auch nicht stimmen: Äußere Programme in
anderen Sprachen (Delphi, Python) sind ja ohne alle Verrenkungen in der
Lage, dem inneren Programm sein Abschluss-Signal zu liefern. Und weil
sie das tun, ohne dass ich speziell eingreifen musste, weiß ich auch
nicht, was sie liefern.

Was tun?

Beste Grüße,
Hertha

Re: IPC::Open2, Windows: Eingabe-Umleitung tut nicht

Hertha Steck schrieb:
> Hallo Peter und alle Mitleser,
>
> Hertha Steck schrieb:
>>
>> Jetzt habe ich zwar halbwegs begriffen, was dieses Programm tut. Aber
>> es trifft leider nicht zu, dass es mit jedem Programm funktioniert,
>> das ungepuffert über STDOUT schreibt. Und ich kann absolut nicht
>> verstehen, warum nicht.
>>
>> Was ich brauche: das "innere Programm" bekommt seine Eingabe,
>> verarbeitet sie, schreibt das Ergebnis über STDOUT raus (ungepuffert
>> lt. Dokumentation), beendet sich. In dieser Reihenfolge (das ist also
>> etwas anders als b.bat, wo zuerst geschrieben wird). Deshalb am Anfang
>>
>
> Ich bin jetzt einen winzigen Schritt weiter: ich weiß, woran es fehlt.
> Das "innere Programm" scheint wirklich nicht mitzukriegen, dass keine
> Eingaben mehr kommen.
>
> b.bat erwartet und bekommt genau einen Tastendruck als Eingabe, da gibt
> es kein Problem. Ein Perl-Skript, das auf ein bestimmtes Ende-Zeichen in
> der Eingabe prüft, und dem das äußere Skript eben dieses Zeichen
> liefert: ebenfalls kein Problem. Ein Perl-Skript, das seine Eingaben in
> einer Schleife "while (<>) { ... }" bekommt und verarbeitet: aus dieser
> Schleife kommt es nicht heraus. Ein zusätzlich eingebautes "last if

Du bringst mir zuviel durcheinander. Starte mal einfach folgendes b.pl und
tippe 1 Enter, 2 Enter, x Enter oder Ctrl-Z Enter;

# b.pl
use strict;

while ( <> ) {
s/\s+$//;
print "Ergebnis: *$_*\n";
last if /x/;
}

print "geht wohl doch\n";


> (eof)" hilft da nicht. Ein explizites Anhängen von Ctrl-Z , also
> "\x1a\n" an die Eingabe, analog zum Verfahren über die Tastatur, hilft
> genau so wenig.
>
> Und das Programm, das ich wirklich steuern will, verhält sich wie das
> Perl-Skript mit der "while (<>)"-Schleife.
>
> Da möchte man jetzt meinen, das Problem läge ausschließlich beim inneren
> Programm, aber das kann so auch nicht stimmen: Äußere Programme in
> anderen Sprachen (Delphi, Python) sind ja ohne alle Verrenkungen in der
> Lage, dem inneren Programm sein Abschluss-Signal zu liefern. Und weil
> sie das tun, ohne dass ich speziell eingreifen musste, weiß ich auch
> nicht, was sie liefern.
>
> Was tun?

Welches Programm willst Du steuern, darf man das erfahren?

Re: IPC::Open2, Windows: Eingabe-Umleitung tut nicht

Peter Arnhold schrieb:
>> Hertha Steck schrieb:

>> Ich bin jetzt einen winzigen Schritt weiter: ich weiß, woran es fehlt.
>> Das "innere Programm" scheint wirklich nicht mitzukriegen, dass keine
>> Eingaben mehr kommen.
>>
>> b.bat erwartet und bekommt genau einen Tastendruck als Eingabe, da gibt
>> es kein Problem. Ein Perl-Skript, das auf ein bestimmtes Ende-Zeichen in
>> der Eingabe prüft, und dem das äußere Skript eben dieses Zeichen
>> liefert: ebenfalls kein Problem. Ein Perl-Skript, das seine Eingaben in
>> einer Schleife "while (<>) { ... }" bekommt und verarbeitet: aus dieser
>> Schleife kommt es nicht heraus. Ein zusätzlich eingebautes "last if
>
> Du bringst mir zuviel durcheinander. Starte mal einfach folgendes b.pl und
> tippe 1 Enter, 2 Enter, x Enter oder Ctrl-Z Enter;
>
> # b.pl
> use strict;
>
> while ( <> ) {
> s/\s+$//;
> print "Ergebnis: *$_*\n";
> last if /x/;
> }
>
> print "geht wohl doch\n";
>

Ich sehe, dass ich mich oben nicht wirklich klar genug ausgedrückt habe.
Dieses Skript tut genau das, was ich erwartet habe:

- von der Kommandozeile aus für sich allein aufgerufen, beendet es sich
entweder nach einer Eingabe, die ein "x" enthält oder nach Eingabe von
Ctrl-Z Enter.

- aus dem Skript "a.pl" aufgerufen, beendet es sich nach einer
Eingabezeile, die ein "x" enthält. Dann wird auch die Abschlussmeldung
"geht wohl doch" ausgegeben. Gibt es aber keine Eingabezeile mit einem
"x", dann beendet sich b.pl eben nicht (bzw. es braucht den kill-Befehl,
um es zu beenden), die Abschlussmeldung wird nicht ausgegeben.

Diesen Fall meinte ich oben mit dem Perl-Skript (als aufgerufenes
Programm), das auf ein bestimmtes Ende-Zeichen in der Eingabe prüft.

>
> Welches Programm willst Du steuern, darf man das erfahren?

Das ist das Backend des Servers für ein nichtrelationales, außerhalb von
Bibliotheken wohl eher nicht so bekanntes Datenbanksystem (zum
Hintergrund: http://www.allegro-c.de/); und dieses Backend lässt sich
auch separat als Konsolenprogramm benutzen. Die wesentliche Aussage zur
Arbeitsweise, Originalton Entwickler, von mir zurechtgeschnipselt:

"Arbeitsweise
============

avanti-cl bekommt einen ganz normalen avanti-FLEX über die Standard-
eingabe, arbeitet ihn ab, und liefert das Ergebnis auf der Standard-
ausgabe aus.
Jeder Befehl, der eine Ausgabe erzeugt (write, qrix, ...), schreibt
diese sofort raus. Vom Ergebnis wird nichts im Programm gepuffert.
....
Außerdem arbeitet das Programm nur einen Job ab und beendet sich dann.
....
Aufruf von einem Programm aus
-----------------------------

Allgemein startet man avanti-cl als Subprozess und verbindet
es mit Pipes über die Standardkanäle mit dem Programm."

Und genau das versuche ich bisher vergeblich. Habe gestern bei erneuter
Google-Recherche noch einen neuen Ansatz gefunden
(Win32::Process::Create mit Tricks), aber noch nicht ausprobiert.

Beste Grüße,
Hertha

Re: IPC::Open2, Windows: Eingabe-Umleitung tut nicht

Hertha Steck schrieb:
> Peter Arnhold schrieb:
>>> Hertha Steck schrieb:
>>> b.bat erwartet und bekommt genau einen Tastendruck als Eingabe, da gibt
>>> es kein Problem. Ein Perl-Skript, das auf ein bestimmtes Ende-Zeichen in
>>> der Eingabe prüft, und dem das äußere Skript eben dieses Zeichen
>>> liefert: ebenfalls kein Problem. Ein Perl-Skript, das seine Eingaben in
>>> einer Schleife "while (<>) { ... }" bekommt und verarbeitet: aus dieser
>>> Schleife kommt es nicht heraus. Ein zusätzlich eingebautes "last if

[...]

> Ich sehe, dass ich mich oben nicht wirklich klar genug ausgedrückt habe.

[...]

Doch, hast Du. Es sollte dir zeigen, das b.pl (stellvertretend für das
eigentliche Programm) korrekt arbeitet und *nicht* in einem "while (<>) { ...
}" stecken bleibt. Wird eine Abbruchbedingung erfüllt, wird auch abgebrochen.
Entweder innerhalb des Blockes oder durch Ctrl-Z.

Damit wären wir auch beim eigentlichen Problem. Das Programm wird auf ein EOF
warten. Ich bin von was Interaktivem ausgegangen. Das Programm aber nimmt
seinen (einen) Job entgegen und will dann nichts weiter (aber eben EOF).
Ein "\x1a" am Ende bringt nichts (wie Du schon festgestellt hast), es geht
nämlich genau so rüber und nicht als EOF. Das liegt daran, das W im binmode
ist. Auch das Schließen von W bringt kein EOF.

Du könntest den Job vorher in eine Datei schreiben und diese pipen, dann kommt
auch das EOF (das "Pause" aus b.bat muss dann aber raus;)

open R, '-|', 'b.bat|perl.exe b.pl' or die;

Gruß,
Peter

Re: IPC::Open2, Windows: Eingabe-Umleitung tut nicht

On 2007-07-05 12:16, Hertha Steck wrote:
> Hertha Steck schrieb:
>>
>> Jetzt habe ich zwar halbwegs begriffen, was dieses Programm tut. Aber es
>> trifft leider nicht zu, dass es mit jedem Programm funktioniert, das
>> ungepuffert über STDOUT schreibt. Und ich kann absolut nicht verstehen,
>> warum nicht.
>>
>> Was ich brauche: das "innere Programm" bekommt seine Eingabe,
>> verarbeitet sie, schreibt das Ergebnis über STDOUT raus (ungepuffert lt.
>> Dokumentation), beendet sich. In dieser Reihenfolge (das ist also etwas
>> anders als b.bat, wo zuerst geschrieben wird). Deshalb am Anfang
>>
>
> Ich bin jetzt einen winzigen Schritt weiter: ich weiß, woran es fehlt.
> Das "innere Programm" scheint wirklich nicht mitzukriegen, dass keine
> Eingaben mehr kommen.

Schließt Du denn das Schreibende der Pipe im "äußeren Programm" nachdem
Du die letzten Daten geschickt hast? Wenn nicht, kann das "innere
Programm" ja nicht wissen, dass nichts mehr kommt: Die Pipe ist noch da
und das "äußere Programm" könnte noch was schicken.

hp


--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"

Re: IPC::Open2, Windows: Eingabe-Umleitung tut nicht

Peter Arnhold schrieb:
>
> Hertha Steck schrieb:
>> Peter Arnhold schrieb:
>>>> Hertha Steck schrieb:
>>>> b.bat erwartet und bekommt genau einen Tastendruck als Eingabe, da gibt
>>>> es kein Problem. Ein Perl-Skript, das auf ein bestimmtes Ende-Zeichen in
>>>> der Eingabe prüft, und dem das äußere Skript eben dieses Zeichen
>>>> liefert: ebenfalls kein Problem. Ein Perl-Skript, das seine Eingaben in
>>>> einer Schleife "while (<>) { ... }" bekommt und verarbeitet: aus dieser
>>>> Schleife kommt es nicht heraus. Ein zusätzlich eingebautes "last if
>
> [...]
>
>> Ich sehe, dass ich mich oben nicht wirklich klar genug ausgedrückt habe.
>
> [...]
>
> Doch, hast Du. Es sollte dir zeigen, das b.pl (stellvertretend für das
> eigentliche Programm) korrekt arbeitet und *nicht* in einem "while (<>) { ...
> }" stecken bleibt. Wird eine Abbruchbedingung erfüllt, wird auch abgebrochen.
> Entweder innerhalb des Blockes oder durch Ctrl-Z.
>
> Damit wären wir auch beim eigentlichen Problem. Das Programm wird auf ein EOF
> warten. Ich bin von was Interaktivem ausgegangen. Das Programm aber nimmt
> seinen (einen) Job entgegen und will dann nichts weiter (aber eben EOF).
> Ein "\x1a" am Ende bringt nichts (wie Du schon festgestellt hast), es geht
> nämlich genau so rüber und nicht als EOF. Das liegt daran, das W im binmode
> ist. Auch das Schließen von W bringt kein EOF.
>
> Du könntest den Job vorher in eine Datei schreiben und diese pipen, dann kommt
> auch das EOF (das "Pause" aus b.bat muss dann aber raus;)
>
> open R, '-|', 'b.bat|perl.exe b.pl' or die;

Es war spät. Nunja, nochmal anders formuliert: trenne den Programmstarter in
den startenden + auswertenden Teil (a.pl) und einen Job-Erzeuger (a2.pl) und
pipe das Ergebnis des Job-Erzeugers zum eigentlichen Programm:

open R, '-|', 'perl a2.pl|perl.exe b.pl' or die;

# a2.pl
print "das ist ein job\n";

Allerdings würde mich auch interessieren, warum bei Verwendung des Writers von
open2[3] kein EOF beim Schließen des selbigen kommt. Ist das Win32 spezifisch
oder hat es einen anderen logischen Grund? Vielleicht weiß das jemand hier?

Gruß,
Peter

Re: IPC::Open2, Windows: Eingabe-Umleitung tut nicht

On 2007-07-07 21:33, Peter Arnhold wrote:
> Auch das Schließen von W bringt kein EOF.

Warum nicht?

hp


--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"

Re: IPC::Open2, Windows: Eingabe-Umleitung tut nicht

Hallo Peter,

Peter J. Holzer schrieb:
> On 2007-07-07 21:33, Peter Arnhold wrote:
>> Auch das Schließen von W bringt kein EOF.
>
> Warum nicht?

Wüsste ich auch gern.

Gruß,
Peter

Re: IPC::Open2, Windows: Eingabe-Umleitung tut nicht

Peter Arnhold schrieb:
> Doch, hast Du. Es sollte dir zeigen, das b.pl (stellvertretend für das
>> eigentliche Programm) korrekt arbeitet und *nicht* in einem "while (<>) { ...
>> }" stecken bleibt. Wird eine Abbruchbedingung erfüllt, wird auch abgebrochen.
>> Entweder innerhalb des Blockes oder durch Ctrl-Z.
>>

Aber nach dem Schließen des Writers müsste doch eigentlich schon "<>" in
der While-Bedingung falsch werden, oder nicht? So dass dann ein Prüfung
innerhalb der Schleife überflüssig wäre.

>
>
> Es war spät. Nunja, nochmal anders formuliert: trenne den Programmstarter in
> den startenden + auswertenden Teil (a.pl) und einen Job-Erzeuger (a2.pl) und
> pipe das Ergebnis des Job-Erzeugers zum eigentlichen Programm:
>
> open R, '-|', 'perl a2.pl|perl.exe b.pl' or die;
>
> # a2.pl
> print "das ist ein job\n";
>

Werde ich ausprobieren, allerdings nicht gleich. Zum Glück stehe ich bei
der ganzen Geschichte nicht unter Zeitdruck.

> Allerdings würde mich auch interessieren, warum bei Verwendung des Writers von
> open2[3] kein EOF beim Schließen des selbigen kommt. Ist das Win32 spezifisch
> oder hat es einen anderen logischen Grund? Vielleicht weiß das jemand hier?
>

Da unter Linux vergleichbare Probleme nicht auftreten, tippe ich schon
auf Win32 spezifisch. Und da mit mindestens zwei anderen
Programmiersprachen auch keine vergleichbaren Probleme auftreten, tippe
ich noch spezifischer auf den Win32-Port von Perl.

Dank und Gruß,
Hertha

Re: IPC::Open2, Windows: Eingabe-Umleitung tut nicht

Peter J. Holzer schrieb:
>
> Schließt Du denn das Schreibende der Pipe im "äußeren Programm" nachdem
> Du die letzten Daten geschickt hast? Wenn nicht, kann das "innere
> Programm" ja nicht wissen, dass nichts mehr kommt: Die Pipe ist noch da
> und das "äußere Programm" könnte noch was schicken.
>

Aber ja doch. Schön wär's, wenn es so einfach wäre!

Grüße,
Hertha