Komponente für SSH-Verbindung

[xZise]

Hat keiner eine Idee, warum der Thread sich nachher blockiert?

MfG
xZise

[omata]

Der Quellcode enthielt mehrere Problemstellen, der schlimmste Fehler war in PLinkremote.pas und dort in ReadPipe. Dort wurde nämlich nicht an allen Stellen die übergebene Pipe benutzt, sondern immer die globale Output-Pipe.

[xZise]

Zitat von omata:

Der Quellcode enthielt mehrere Problemstellen, der schlimmste Fehler war in PLinkremote.pas und dort in ReadPipe. Dort wurde nämlich nicht an allen Stellen die übergebene Pipe benutzt, sondern immer die globale Output-Pipe.

Ookay, dass ist ungünstig Weil gerade ReadPipe sollte das verhindern. Was sind den weitere Probleme gewesen?

MfG
xZise

[omata]

Zitat von xZise:

...gerade ReadPipe sollte das verhindern.

Naja, aber nicht wenn die zu lesende Bytemenge aus einer Pipe kommt und dann aus einer anderen diese Anzahl gelesen wird. Dann steht das System, weil eben erst so viel Bytes wie angegeben gelesen werden, bevor ReadPipe wieder zurückkehrt.

Zitat von xZise:

Was sind den weitere Probleme gewesen?

Verschiedenes, habe alles korrigiert. Für genau Informationen empfehle ich KDiff, dann werden die Änderungen sichtbar.

[xZise]

Genau, dass hatte ich mir auch gedacht. Ich werde mal gucken in wie fern ich das noch weiter auslagern kann.

MfG
xZise

[omata]

Was hast du dir gedacht? Das eigentliche Problem sollte jetzt behoben sein. Mich würde eher mal interessieren, ob der besagte Fehler noch auftritt oder nicht. Darüber läßt du leider keine Informationen durchsickern, schade.

[seim]

Im folgenden rede ich über ein paar Begriffe die ich zwar nicht ganz verstehe, aber zumind. weis was damit gemeint ist bzw. wie diese Wirken auch wenn ich sie nicht selbst programmieren kann ^.^


Also ist es möglich, dass in einem anderen Thread (<> Hauptthread) der Buffer, der auch im Event "Data available" verwendet wird die ganze Zeit an einen globalen String hinten angehängt wird?
Das wäre nämlich notwendig um die Antwort des Severs in seinem Programm verwenden zu können etwa so:

Delphi-Quellcode:

..
PLink.write_str('ls -l');

Sleep(200); //An dieser Stelle "friert" der Hauptthread ein und deshalb funktioniert das Event auch nicht, dass in diesem Fall die Variable "Answer" füllen würde

//.. Verarbeite Antwort

[seim]

Hat da jmd schon ne Lösung zu? Also die Antwort vom Server zu bearbeiten?


In diesem Projekt gibts eine

procedure sshExecCommand(const Command : string); Dessen Antwort wird gut aufgenommen und in einer MemoBox ausgegeben. Allerdings ist die procedure zum Zeitpunkt der Antwort bereits zu ende und kann deshalb nicht verarbeitet werden.. Das Ziel ist es die Antwort zurückzugeben:

function sshExecCommand(const Command : string): TStringList; Jmd Vorschläge?


Wer's testen will müsste das neu compilen um die IP, Port, User und PW anzupassen (bitte nur in einer Testumgebung also auf keinen Fall mit root an nem 100Mbit Server einloggen )

[WeissenbornC]

Hi,

vielen Dank für die Komponente und die Verbesserungen von omata. Leider erhalte ich eine Speicher-Warnmeldung beim Beenden der Demo von Omata (s.A.)

Außerdem kann ich die neue Version der plinkremote nicht als Komponente in die Palette bekommen - Versuche ich, die neue Version der .pas über die alte zu schreiben und dann mit der .dkp zu kompilieren wird die Komponente aus der Palette entfernt.

Ich verwende Delphi 6 Prof. (Die PosEx habe ich bereits hinzugefügt, an der liegt es nicht )

Vielen Dank im voraus.

@seim: Falls das noch aktuell sein sollte, ich würde in einer schleife auf Antwort warten, etwa

Delphi-Quellcode:

repeat
 sleep(10);
 Application.ProcessMessages;
until gotReply OR Application.Terminated;

Bei mir habe ich das warten vorerst über einen Timer gelöst.

[edit=mkinzler]Delphi-Tag eingefügt Mfg, mkinzler[/edit]

[omata]

Ich weiss nicht was du da gemacht hast, aber in der Demo gibt es die Komponenten TObjectList, TWinHelpViewer und THelpManager gar nicht, dementsprechend weiss ich nicht wie diese Fehler in der Demo zu finden sein sollen.

Sorry, da kann ich nicht helfen.