Frage zu sysread (gelöst) (Allgemeines zu Perl) - Perl-Community.de

Start · Board · Anwendungen/Programme/Skripte in Perl · Allgemeines zu Perl

2024-05-04 05:31:06
Europe/Berlin
Einloggen (Registrieren)
- Einstellungen
- Statistics
Jemand zu Hause?
0 Benutzer online
1 Gast

[thread]18646[/thread]

submit to reddit

Frage zu sysread [gelöst]

[gelöst]

Tags: perl5 Ähnliche Threads

Leser: 18

Articles: hide open all | hide show old branches

+19 replies
bianca

2013-10-01 09:18
User since
2009-09-13
6978 Artikel
BenutzerIn
Hallo!
Es geht nach wie vor um die bidirektionale Kommunikation mit einer anderen Anwendung unter Windows.
Folgende Simulation funktioniert:
Code (perl): (dl )

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

#!/usr/bin/perl use strict; use warnings; use IPC::Open3 1.12; my $prog = join(' ',qw(perl doit.pl)); print "Rufe Programm '$prog' auf \n"; my ($in,$out,$err,$pid,$ausgabe,$puffer); eval { $pid = open3($in,$out,$err,$prog); }; die "Gescheitert: '$@'" if $@; if (defined $pid) { print "PID '$pid', lese...\n"; #$ausgabe .= $puffer while (sysread $out,$puffer,4096); sysread $out,$ausgabe,4096; print "Fertig mit lesen\n"; if (defined $ausgabe) { print "\n\nErhalte:\n".('=' x 30)."\n$ausgabe"; my $code = <STDIN>; chomp($code); print $in $code."\n"; sysread $out,$ausgabe,4096; print "\n\nErhalte:\n".('=' x 30)."\n$ausgabe"; } } else { die "Keine PID"; }
Dazu die doit.pl:
Code (perl): (dl )

1 2 3 4 5 6 7 8 9 10

#!/usr/bin/perl use strict; use warnings; use IO::Handle 1.24; STDOUT->autoflush(1); print "Guten Tag!\nBitte Zugangscode eingeben: "; my $code = <STDIN>; chomp($code); print "Danke fuer '$code'\n";
Das Problem: Diese Simulation funktioniert. Aber wenn ich das Programm verwende, das tatsächlich benutzt werden soll bleibt das sysread() nach ca. 248 Byte (hab es nicht genau abgezählt) einfach stehen und kehrt nicht zurück.

Wenn ich Zeile 17 durch 16 auswechsle liest es zwar die gesamte Ausgabe des Programms, kehrt aber nicht zurück.

Hat jemand eine Idee, wie man das richtig macht?
Wie kann ich dem sysread() sagen, dass es aufhören soll, wenn da nichts mehr kommt? Habe in älteren Artikeln gelesen, dass man bei der Konstruktion mit IPC::Open3 unbedingt sysread() verwenden muss.
Oder gibt es doch Alternativen.
10 print "Hallo"
20 goto 10
- +5 replies
- topeg
  
  2013-10-01 16:51
  
  User since
  2006-07-10
  2611 Artikel
  BenutzerIn
  
  Mir scheint das Problem zu sein, das das aufgerufenen Programm kein "update" für das Handle sendet. Perl erwartet das ihm mitgeteilt wird, das neue Daten im Transferpuffer sind. Das wird bei POSIX konformen System von diesen gehandhabt, unter Windows scheint das Programm dafür zuständig zu sein (oder das Programm macht irgend einen Mist mit dem System). Mit dem while sysread umgehst du das. Perl schaut von sich aus nach ob Daten im Puffer sind. Der Nachteil ist aber das Perl auf das "update"-Signal wartet wenn der Puffer leer ist.
  
  Du könntest schauen ob du das lesen nicht nonblocking machen kannst. Dann wartet perl nicht am sysread sondern gibt 0 zurück. Nachteil ist dann das man selber schauen muss ob das handle noch offen ist, das Programm also noch läuft, sonst beschwert sich Perl dass man versucht von einem geschlossenen Handle zu lesen, oder das script macht weiter obwohl noch Daten kommen, weil einmal aus einem leeren Puffer gelesen wurde.
  
  Eine einfachere Lösung fällt mir nicht ein.
  
  Sysread wird empfohlen weil das die Perlinternen Puffer und Filter umgeht. Das kann bei Pipes zu Problemen führen, wenn z.B zerteilte UTF8 Zeichen gelesen werden, oder "\r\n" gesplittet gelesen wird. Perl hat das mittlerweile ganz gut im Griff, aber die Funktionen können einem natürlich auch dazwischen funken.
  Du kannst sysread nutzen, darfst das nur nicht mit read / readline mischen, da kommt Müll raus.
  - bianca
    
    2013-10-01 17:39
    
    User since
    2009-09-13
    6978 Artikel
    BenutzerIn
    
    2013-10-01T14:51:59 topeg
    Du könntest schauen ob du das lesen nicht nonblocking machen kannst.
    
    Danke dir vielmals für die Hilfe!
    Was müsste ich hierfür konkret machen?
    Der Begriff sagt mir auf Anhieb nichts.
    10 print "Hallo"
    20 goto 10
  - +3 replies
  - bianca
    
    2013-10-01 19:09
    User since
    2009-09-13
    6978 Artikel
    BenutzerIn
    
    Habe mal was versucht:
    
    Code (perl): (dl )
    
    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
    
    #!/usr/bin/perl use strict; use warnings; use IPC::Open3 1.12; use IO::Handle 1.24; my $prog = join(' ',qw(perl doit.pl)); print "Rufe Programm '$prog' auf \n"; my ($in,$out,$err,$pid,$ausgabe,$puffer); eval { $pid = open3($in,$out,$err,$prog); $out->blocking(0); }; die "Gescheitert: '$@'" if $@; if (defined $pid) { print "PID '$pid', lese...\n"; #$ausgabe .= $puffer while (sysread $out,$puffer,4096); sysread $out,$ausgabe,4096; print "Fertig mit lesen\n"; if (defined $ausgabe) { print "\n\nErhalte:\n".('=' x 30)."\n$ausgabe"; my $code = <STDIN>; chomp($code); print $in $code."\n"; sysread $out,$ausgabe,4096; print "\n\nErhalte:\n".('=' x 30)."\n$ausgabe"; } } else { die "Keine PID"; }
    
    Habe ich das in Zeile 13 richtig gemacht? Es verhält sich nämlich leider genau so wie vorher.
    Gewundert hat mich auch, dass es keine Fehlermeldung gab, als ich use IO::Handle 1.24; nicht drin hatte. Ich dachte, das wäre eine Funktion von IO::Handle?
    10 print "Hallo"
    20 goto 10
    - martin.g
      
      2013-10-02 08:44
      
      User since
      2013-09-20
      40 Artikel
      BenutzerIn
      
      2013-10-01T17:09:57 bianca
      Gewundert hat mich auch, dass es keine Fehlermeldung gab, als ich use IO::Handle 1.24; nicht drin hatte. Ich dachte, das wäre eine Funktion von IO::Handle?
      
      Seit wann muss man denn Module laden, wenn man Objekte von anderer Stelle bekommt? Da bräuchtest Du in umfangreicheren OO Anwendungen ja einen ganz Wald an uses. Und im Gegensatz zu open3() verwendest Du mit ->blocking() ja keine exportierte Funktion, sondern eine Methode eines Objekts, das Du schon hast.
      
      Ich denke, dass das aber gut aussieht. $out ist zwar nicht direkt vom Typ IO::Handle, aber mir scheint, dass das Typeglob im Hintergrund IO::File verwendet. Und das erbt von IO::Handle.
      Was Du mal probieren könntest, wäre vor dem open3() ein $out = IO::Handle->new()
      Generell wäre ein nicht funktionierendes Beispiel natürlich ideal. Kannst Du da evtl. etwas basteln? Oder ist das Programm zu dem Du kommunizieren willst kein Skript, sondern ein Binary? Kannst Du es evtl. mit Windows Builtins reproduzieren? dir, ipconfig, irgendwas...
      
      Wie sind denn aktuell die Ergebnisse mit Z18 bzw. Z19?
      Du schreibst, dass sysread nicht zurückkehrt. Ist das tatsächlich so oder bleibst Du möglicherweise in der while sysread Schleife hängen, weil sysread nie nach false evaluiert?
    - murphy
      
      2013-10-02 11:11
      
      User since
      2004-07-19
      1776 Artikel
      HausmeisterIn
      
      IO;:Handle ist ein wenig magisch und verleiht normalen Dateihandles zusätzliche objektorientierte Funktionen, dazu muss man das Modul aber explizit laden.
      
      Auf den ersten Blick sieht der Code in Ordnung aus, wobei man bei einer realen Anwendung wohl in einer Schleife aus dem nicht-blockierenden Dateihandle lesen wollte, aber natürlich nur nach einer Prüfung durch poll(2), select(2), WaitForSingleObject(Win32), WaitForMultipleObjects(Win32) oder ähnliches, um Busy-Waiting zu vermeiden.
      
      Es wundert mich allerdings überhaupt nicht, dass das ganze unter Windoof nicht funktioniert, denn vermutlich setzt IO::Handle::blocking auf ioctl(2) auf, was garantiert unter Windoof genauso toll (= gar nicht ;-) funktioniert wie IO::Select auf Basis von select(2).
      When C++ is your hammer, every problem looks like your thumb.
- +9 replies
- bianca
  
  2013-10-02 11:41
  
  User since
  2009-09-13
  6978 Artikel
  BenutzerIn
  
  Danke für alle Antworten.
  Das Problem dabei ist, nach jeweils 3 Fehlversuchen habe ich ziemlich zeitintensiven Aufwand, das System wieder entsperren zu lassen.
  Ich würde es also gern mit möglichst wenig Versuchen ergründen.
  Daher die Frage: Was kann ich jetzt konkret noch versuchen?
  
  Eure Texte kann ich zwar lesen, topeq, murphy und martin.g aber in Code umsetzen ist etwas schwierig für mich. Ich verstehe davon eigentlich zu wenig, will das aber trotzdem hinkriegen :)
  Würdet ihr mir bitte nochmal etwas konkreter auf die Sprünge helfen oder mir sagen, wo ich lesen muss.
  Wäre wirklich super lieb von euch.
  
  martin.g: Zu deiner Frage: Das print in Zeile 18 (Nummerierung nach dem ersten Code oben) wird nicht ausgeführt, das Script hängt dann in Zeile 17 und lässt sich nur mit STRG C abwürgen.
  Last edited: 2013-10-02 12:04:49 +0200 (CEST)
  10 print "Hallo"
  20 goto 10
  - +5 replies
  - martin.g
    
    2013-10-02 12:25
    User since
    2013-09-20
    40 Artikel
    BenutzerIn
    
    Ich hatte mich mit Z.18 und Z.19 auf Dein geändertes Listing inklusive blocking(0) bezogen. Aber bleiben wir der Übersichtlichkeit lieber bei Z.16/17.
    
    Also um das nochmal zusammenzufassen, dass wir nicht aneinander vorbeireden:
    
    Das hier funktioniert, liest aber nicht alles: sysread $out,$ausgabe,4096;
    Nach dem Aufruf steht in $ausgabe ein Teil der Ausgabe drin.
    
    Was hier passiert, weißt Du nicht genau, das Perl Skript hängt irgendwann und die Folgeanweisungen werden nicht mehr ausgeführt. $ausgabe .= $puffer while (sysread $out,$puffer,4096);
    
    Das Zurücksetzen des Systems verstehe ich nicht. Meinst Du das Perl Skript abzubrechen? Oder hängt sich durch das Perl Skript der andere Service auf?
    
    Ich würde etwas in der Form versuchen, um erstmal herauszufinden, wie oft durchlaufen wird und ob irgendwelche Auffälligkeiten dabei sind.
    
    Code (perl): (dl )
    
    1 2 3 4 5 6 7 8
    
    for( my $i = 1; $i <= 10; $i++ ) { last unless $out; print "Calling sysread; "; my $bytes = sysread($out, $buffer, 4096); print "Try #$i: $bytes Bytes read.\n"; last unless $bytes; print "$buffer\n\n"; }
    
    Vermutlich wird er dann tatsächlich irgendwann nach "calling sysread" hängen. Evtl. sagt aber der vorherige buffer irgendwas aus. Evtl. wird auch das Filehandle ungültig und sysread merkt das nicht. Dann sollte die erste last Anweisung für Abbruch sorgen.
    
    Nachtrag: Deine Ergänzung im Beitrag bzgl. Strg+C lässt darauf schließen, dass Du tatsächlich das Remote System abschießt. Das ist natürlich richtig blöd :-) Und bedeutet wohl, dass es zu irgendeiner Deadlock Situation kommt. Wieso das dann aber dreimal funktioniert, ist mir schleierhaft.
    
    Nachtrag2: Ich habe es begriffen. Du versuchst, Dich irgendwo anzumelden, schaffst es aber nicht, weil Dein Skript nicht funktioniert. Und das System, wo Du Dich anmelden willst, sperrt den Zugang dann. Die Frage, die sich stellt: Das ist eine lokale Anwendung auf Kommadozeilenebene, richtig? Zwei falsche Versuche sind okay. Wenn Du Dich von Hand nach dem zweiten Mal einmal korrekt einloggst - hast Du dann wieder drei Versuche?
    Last edited: 2013-10-02 12:34:38 +0200 (CEST)
    - +4 replies
    - martin.g
      
      2013-10-02 12:57
      
      User since
      2013-09-20
      40 Artikel
      BenutzerIn
      
      Ich habe eben erst geschnallt, dass auch Deine Simulation mit der sysread Schleife nicht funktioniert. Bisher ging ich davon aus, dass Deine Sim immer funktioniert und die unterschiedlichen Fehler nur mit dem richtigen System auftreten.
      Ich kann den Schleifen Fehler mit nem Perl 5.8, das ich noch drauf hatte, jedenfalls reproduzieren und schaue mir das mal an.
      - +3 replies
      - martin.g
        
        2013-10-02 14:41
        
        User since
        2013-09-20
        40 Artikel
        BenutzerIn
        
        Nun habe ich mich deutlich intensiver damit auseinandergesetzt, als ich eigentlich vorhatte :-)
        Für mich ist die eindeutige Quintessenz: IPC::Open3 sollte man unter Windows nicht verwenden. Zumindest nicht mit Filehandles. Um sysread vernünftig einzusetzen brauchst Du auch select() und das funktioniert unter Windows bekanntlich nur für Sockets.
        
        Du könntest also auf Sockets umbauen:
        http://www.perlmonks.org/?node_id=811081
        Gibt aber wohl auch viele Programme, deren Ausgabe sich ungern in Sockets umlenken lässt
        
        Das einfachste aber uneleganteste wäre ein Workaround mit sinnlosen Schleifendurchläufen:
        
        Code (perl): (dl )
        
        1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38
        
        #!/usr/bin/perl use strict; use warnings; use IPC::Open3; use IO::Handle; STDOUT->autoflush(1); my $prog = join(' ',qw(perl doit.pl)); print "Rufe Programm '$prog' auf \n"; my ($in,$out,$err,$pid,$ausgabe,$buffer); eval { $pid = open3($in,$out,$err,$prog); $out->blocking(0); }; die "Gescheitert: '$@'" if $@; if (defined $pid) { print "PID '$pid', lese...\n"; for( my $i = 1; $i <= 100000; $i++ ) { undef $buffer; #select(undef, undef, undef, 0.25) # Verzoegerung my $bytes = sysread($out, $buffer, 4096); $ausgabe .= $buffer if $buffer; #last if $ausgabe && ! $bytes; # Abbruch sobald einmal nichts mehr gelesen wurde } print "Fertig mit lesen\n"; if (defined $ausgabe) { print "\n\nErhalte:\n".('=' x 30)."\n$ausgabe"; my $code = <STDIN>; chomp($code); print $in $code."\n"; sysread $out,$ausgabe,4096; print "\n\nErhalte:\n".('=' x 30)."\n$ausgabe"; } } else { die "Keine PID"; }
        
        Die Anzahl der notwendigen Schleifendurchläufe ist vermutlich vom System abhängig, wäre also anzupassen.
        Man könnte auch die Schleifenzahl erhöhen und das last einkommentieren. Sobald die Ausgabe beginnt, muss aber am Stück gelesen werden können, sonst ist der Zug abgefahren.
        Etwas robuster ginge es, indem man einen Sinnlos select() zur Verzögerung verwendet. Vor jedem read 250ms Gedenkzeit sollte dicke reichen. Wenn die Anwendung zu Beginn länger braucht, weil sie erst initialisiert, dann ist das über die Schleife abgefangen.
        
        Das ganze wird durch zwei Probleme bei sysread() notwendig.
        1. Wenn Du sysread aufrufst, obwohl das Handle noch nicht fertig ist, wartet es ewig und ignoriert auch, wenn irgendwann was kommt.
        2. Wenn Du blocking abstellst, dann läuft sysread zwar durch, aber Du kannst nicht feststellen, nach dem wievielten Durchlauf es fertig ist. $bytes ist immer undef, wenn es nichts gelesen hat. Egal ob das Handle noch nicht fertig ist, ob die Ausgabe beendet ist oder ob nur gerade nichts kommt. Ich weiß auch nicht sicher, ob es das überhaupt feststellen kann.
        
        Robust ist mein Vorschlag leider trotzdem nicht. Baue in Dein doit.pl nach der ersten print() Anweisung ein sleep(2) und eine weitere print() Anweisung ein. Die zweite Ausgabe wirst Du erst nach Deiner Eingabe sehen.
        
        So ein ähnliches Problem habe/hatte ich mit den Net::SSH Modulen auch. Dort habe ich mir so beholfen, dass ich entscheide, wann die letzte Zeile erreicht ist (weil ich weiß, was in der letzten Zeile stehen muss). Bei Dir könnte das "Zugangscode eingeben" sein o.ä..
        Sobald Du Dich auf einer Shell bewegst kannst Du die letzte Zeile immer selbst erzeugen, indem Du nach jedem Kommando ein NOP() oder echo ausführst und bis zu dessen Ausgabe liest.
        
        Es gibt noch einige andere Möglichkeiten - ich würde Dir empfehlen, mal IPC::Run zu testen. Das ist etwas Higher-Level als IPC::Open und bringt wohl trotz einer ganzen Latte Win32-Limitations auch auf Windows sehr gute Ergebnisse.
        
        GRuß MArtin
        Last edited: 2013-10-02 14:42:17 +0200 (CEST)
        
        martin.g
        
        2013-10-02 15:41
        
        User since
        2013-09-20
        40 Artikel
        BenutzerIn
        
        IPC::Run habe ich gerade mal unter Windows getestet. Ist der gleiche Käse in grün. Zur Ausführung einzelner Kommandos kann man es wahrscheinlich gebrauchen, aber für richtige IPC scheint es auch nicht rund zu laufen. Im Prinzip ist es auch logisch, denn woher soll irgendein Modul der Welt wissen, dass alle Daten da sind und Du nun gerne etwas eingeben würdest. Du erkennst das an der Kommandozeile des Programms auch nur aus dem logischen Verständnis. Entweder weil nichts mehr kommt oder weil es Dir der Inhalt klar macht. Effektiv wissen, dass nichts mehr kommt, kannst Du nicht.
        
        Ich würde mir an Deiner Stelle selbst was bauen und auf IPC::Open3 basieren lassen. Für meine SSH Problematik habe ich es auch so gemacht.
        Du arbeitest zum Fremdsystem hin non-blocking, für Dich aber blocking. Wenn Du viel kommunizieren willst, würde ich dafür eine Klasse bauen, dass Du den Mist nur einmal hast.
        - Verbindung aufbauen
        - senden (das sollte kein Problem sein)
        - lesen (in mehr Varianten - zeitgesteuert und ausgabegesteuert)
        
        Deine Klasse liest also solange, bis Dein eigener Timeout (einfach was kleines per time()) erreicht ist, z.B. 2 Sekunden. Oder bis ein bestimmter Rückgabewert erreicht ist, den Du der Methode übergeben kannst.
        
        topeg
        
        2013-10-03 01:18
        
        User since
        2006-07-10
        2611 Artikel
        BenutzerIn
        
        Ja das ist ziemlich das was ich mir vorgestellt hatte. Ich habe hier gerade kein natives Windows um es selber zu testen.
        
        Was das "nicht wissen ob etwas kommt" betrifft. Wenn nichts mehr kommt macht der Sender das Handle zu, das wird an den Empfangenen weiter gegeben und der weiß das alles gesendet wurde. So läuft das unter POSIX-Konformen Systemen. Das funktioniert weil Handles wie Sockets behandelt werden. Unter Windows gibt es diese Direkte an das Handle gebundene Kommunikation nicht. Das läuft gesondert ab und ist Aufgabe des Programms.
        Und damit entstehen all diese Probleme.
        Man kann schauen, ob noch alle Partner mit dem Transferpuffer verbunden sind, aber das ist halt sehr Windowsspezifisch. Wenn man mit einem Fremdprozess kommuniziert kann man auch schauen ob dieser noch läuft (kill(0,$pid)).
        Viele andere Möglichkeiten gibt es wohl nicht.
        
        Meine Erfahrungen mit Windows sind auch etwas älter.
  - +3 replies
  - murphy
    
    2013-10-02 15:41
    
    User since
    2004-07-19
    1776 Artikel
    HausmeisterIn
    
    Soll das ganze jetzt eigentlich portabel auf allen Systemen laufen, oder reicht eine Lösung, die nur auf Windoof arbeitet?
    
    Ich beginne nämlich, darüber nachzudenken, ob sich portable Workarounds um die großflächigen Funktionslücken der Perl-Standardbibliothek auf Windows überhaupt lohnen, oder ob man eher eine Lösung auf Basis von XS und Win32-API oder zumindest direkt über Win32::API anstreben sollte.
    
    Es ist nämlich definitiv möglich, auf Basis von CreatePipe, CreateProcess, SetHandleInformation und WaitForMultipleObjects eine Lösung zu bauen, welche die Standardeingabe, -ausgabe und -fehlerausgabe eines Kindprozesses umleitet und korrekt zwischen den Datenströmen multiplext.
    
    Wenn es portabel sein muss, dann würde ich, wie auch bei den Perlmonks an einigen Stellen vorgeschlagen, mal darüber nachdenken, die Kommunikationskanäle des Subprozesses in Sockets der Adressfamilie AF_LOCAL umzuleiten, damit IO::Select und perlfunc sysread auf den entstehenden Handles erwartungsgemäß arbeiten.
    
    Allerdings befürchte ich, dass es bei der internen Umsetzung von Sockets auf Win32-Handles auch wieder irgendwelche Reibungsverluste gibt.
    When C++ is your hammer, every problem looks like your thumb.
    - +2 replies
    - martin.g
      
      2013-10-02 15:47
      
      User since
      2013-09-20
      40 Artikel
      BenutzerIn
      
      2013-10-02T13:41:44 murphy
      über Win32::API anstreben sollte.
      
      Hatte ich mir auch schon angesehen - scheint aber zu erfordern, dass Parent und Child daraufhin angepasst werden (named pipes in beiden Prozessen). Und wenn sie selbst den Login Zähler nicht zurücksetzen kann, dann hat sie vermutlich auch keine Kontrolle über die Gegenstelle.
      
      2013-10-02T13:41:44 murphy
      Allerdings befürchte ich, dass es bei der internen Umsetzung von Sockets auf Win32-Handles auch wieder irgendwelche Reibungsverluste gibt.
      
      Richtig, so habe ich das auch aus diversen Beiträgen herausgehört. Man könnte es mit dieser einen Anwendung sicher probieren, aber Garantie, dass das irgendwann läuft, hat man leider nicht.
      - murphy
        
        2013-10-02 15:59
        
        User since
        2004-07-19
        1776 Artikel
        HausmeisterIn
        
        2013-10-02T13:47:35 martin.g
        2013-10-02T13:41:44 murphy
        über Win32::API anstreben sollte.
        
        Hatte ich mir auch schon angesehen - scheint aber zu erfordern, dass Parent und Child daraufhin angepasst werden (named pipes in beiden Prozessen).
        [...]
        
        Ich bin zwar kein Windowsexperte, aber CreateProcess akzeptiert unter anderem ein Argument vom Typ STARTUPINFO, welches explizit Einträge zur Umleitung der Standardeingabe, -ausgabe und -fehlerausgabehandles für den neuen Subprozess enthält. Ferner kann man mit CreatePipe auch anonyme Pipes erzeugen und Microsoft schreibt selbst in der Doku, dass damit eine Umleitung von Datenströmen zur Interprozesskommunikation möglich ist. Man muss halt noch darauf achten, dass man jeweils genau das richtige Ende der Pipes in den Kindprozess klonen lässt, nicht das andere und auch nicht beide, da ist Windows etwas empfindlich, wenn ich mich recht erinnere.
        
        Jetzt kann es natürlich sein, dass Microsoft mal wieder in der Doku mehr verspricht, als die kaputte Implementation hält, aber auf den ersten Blick sieht das so aus als wären alle nötigen Funktionen da, nur halt in anderer Form als auf Unixsystemen.
        When C++ is your hammer, every problem looks like your thumb.
- +3 replies
- bianca
  
  2013-10-02 17:05
  
  User since
  2009-09-13
  6978 Artikel
  BenutzerIn
  
  Es ist so: dieses externe Programm bietet auch die Möglichkeit, seine Ausgabe via >datei.txt in eine Datei umzuleiten. Das hat auch funktioniert aber führte mich zu diesem Problem: Offene Datei unter Windows lesen
  Dank FIFO klappt aber jetzt das Lesen dieser Datei mit <:raw
  
  Und da ich immer nur 3 Fehlschüsse habe möchte ich es jetzt gern erst mal so machen und schauen, wie stabil das im Gesamtumfeld ist.
  Danke euch vielmals für die vielen Impulse. Und ich bin fast überzeugt, dass ich hierauf nochmal irgendwann zurück komme :)
  
  Zu euren Rückfragen (unsortiert):
  
  2013-10-02T13:41:44 murphy
  Soll das ganze jetzt eigentlich portabel auf allen Systemen laufen, oder reicht eine Lösung, die nur auf Windoof arbeitet?
  
  Es muss später einzig und allein auf Win 7 64 Bit laufen. Schön wäre auch 32 Bit, damit ich nicht auf dem Produktionsserver entwickeln muss. Perl Version kann ich der Lösung anpassen, derzeit wäre Strawberry 5.10.1 drauf.
  
  2013-10-02T13:41:11 martin.g
  IPC::Run habe ich gerade mal unter Windows getestet. Ist der gleiche Käse in grün.
  
  Ja, *seufz* ich weiß, siehe IPC::Run process ended prematurely
  
  2013-10-02T12:41:10 martin.g
  Nun habe ich mich deutlich intensiver damit auseinandergesetzt, als ich eigentlich vorhatte :-)
  
  Bist ein Schatz, was möchtest du trinken?
  
  2013-10-02T10:25:10 martin.g
  Das Zurücksetzen des Systems verstehe ich nicht. Meinst Du das Perl Skript abzubrechen? Oder hängt sich durch das Perl Skript der andere Service auf?
  
  Das externe Programm wiederum kommuniziert mit einer dritten Stelle und die duldet nur 3 Fehlversuche und wird nicht von mir administriert.
  
  2013-10-02T10:25:10 martin.g
  Nachtrag: Deine Ergänzung im Beitrag bzgl. Strg+C lässt darauf schließen, dass Du tatsächlich das Remote System abschießt.
  
  Das externe Programm wartet auf eine Eingabe, daher brauche ich es ja bidirektional. Und wahrscheinlich flusht oder schließt es einfach sein STDOUT während des Wartens nicht, was wiederum auf meiner Seite zu einem "ewigen Lesen" führt. Aber ich kann das leider im Moment nicht ändern, muss es so nehmen wie es ist.
  
  2013-10-02T10:25:10 martin.g
  Wieso das dann aber dreimal funktioniert, ist mir schleierhaft.
  
  Wie gesagt, das hat mit der dritten Gegenstelle zu tun. Wenn ich dem externen Programm die geforderte Antwort nicht gebe verursacht das an der Zielstelle einen Fehlversuch.
  
  2013-10-02T10:25:10 martin.g
  Nachtrag2: Ich habe es begriffen. Du versuchst, Dich irgendwo anzumelden, schaffst es aber nicht, weil Dein Skript nicht funktioniert. Und das System, wo Du Dich anmelden willst, sperrt den Zugang dann.
  
  Anmelden nicht, das ist ja der erste Schritt bei Start des externen Programms. Aber im zweiten muss eine Freigabe erfolgen und wenn die nicht kommt ist das ein Fehlversuch.
  
  2013-10-02T10:25:10 martin.g
  Die Frage, die sich stellt: Das ist eine lokale Anwendung auf Kommadozeilenebene, richtig?
  
  Auch korrekt!
  
  2013-10-02T10:25:10 martin.g
  Wenn Du Dich von Hand nach dem zweiten Mal einmal korrekt einloggst - hast Du dann wieder drei Versuche?
  
  Nein, leider nicht.
  Die heutigen Entsperrung hat von halb acht bis vor 30 Minuten auf sich warten lassen (nachdem ich tel. nachgehakt habe), das heißt, ein kompletter Tag ist jeweils futsch bei einer Sperrung.
  10 print "Hallo"
  20 goto 10
  - +2 replies
  - GwenDragon
    
    2013-10-02 17:15
    
    User since
    2005-01-17
    14548 Artikel
    Admin1
    
    2013-10-02T15:05:34 bianca
    Die heutigen Entsperrung hat von halb acht bis vor 30 Minuten auf sich warten lassen (nachdem ich tel. nachgehakt habe), das heißt, ein kompletter Tag ist jeweils futsch bei einer Sperrung.
    Sag mal, können die dir denn keinen Entwicklerzugang geben, dass es nicht nach drei Fehlversuchen gesperrt ist?
    die Drachin, Gwendolyn
    
    Unterschiedliche Perl-Versionen auf Windows (fast wie perlbrew) • Meine Perl-Artikel
    - bianca
      
      2013-10-02 17:27
      
      User since
      2009-09-13
      6978 Artikel
      BenutzerIn
      
      2013-10-02T15:15:58 GwenDragon
      Sag mal, können die dir denn keinen Entwicklerzugang geben, dass es nicht nach drei Fehlversuchen gesperrt ist?
      
      Im Moment nicht. Hat einige Zusammenhänge die ich nicht darstellen kann.
      10 print "Hallo"
      20 goto 10
- bianca
  
  2013-11-06 06:01
  
  User since
  2009-09-13
  6978 Artikel
  BenutzerIn
  
  Das hier konnte ich bis heute nicht 100 % mit Modul lösen. Ist mit Windows alles nicht so einfach wie wir festgestellt haben.
  
  Meine Umgehungslösung: Zwar wird mit IPC::Open3 die Anwendung geöffnet. Aber der Kanal wird aus Sicht von Perl nur schreibend benutzt. Die Ausgaben der Anwendung kann man mit >datei in eine Datei umlenken. Die liest mein Script ein und holt sich auf diesem Wege die Ausgaben der Anwendung.
  Total Banane aber es klappt.
  10 print "Hallo"
  20 goto 10

View all threads created 2013-10-01 09:18.