Exit Befehl in eigener Konsole

[haui95]

Guten Tag,

Ich habe mir jetzt endlich einen Server erstellen können, den ich in einer eigenen, in Java geschriebenen Konsole starte. Nun möchte ich die Konsole aber auch wieder schließen können, also nicht nur durch betätigen des Schließen Buttons, sondern auch durch Eingabe des Exit Befehls.

Nun habe ich im Internet folgendes gefunden, um den Inhalt der Konsole zu löschen:

char c;
    InputStream po = process.getInputStream();
        while ((c = (char) processOutput.read()) != -1) {
            if ((byte) c == 12) {
                outputArea.setText("");
            }
        }

Nun frage ich mich zum Einen, was es genau mit diesem Bytecode auf sich hat und wie man für den Befehl "cls", den man in der Java Konsole eingibt, auf einen Bytewert von 12 kommt, und zum Anderen, welchen Bytecode man abfragen müsste, um dem äquivalenten CMD Befehl "exit" in einer if-Abfrage handhaben zu können.

Vielen Dank !

MfG

 

[xehpuk]

Nun habe ich im Internet folgendes gefunden, um den Inhalt der Konsole zu löschen:

Keine Ahnung, was das machen soll. Sieht für mich ziemlich schwachsinnig aus.
Bei

char c = ...; boolean b = c == -1;

sollte b eigentlich immer

false

sein, weil

char

keine negativen Werte annimmt.

in einer eigenen, in Java geschriebenen Konsole

Wie hat man das zu verstehen?

Bytecode

Was meinst du damit? Den Cast auf

byte

und den Vergleich mit 12? Würd ich auf jeden Fall vergessen.
Das Wort ist jedenfalls schlecht gewählt, denn unter Java-Bytecode versteht man schon etwas anderes: Java bytecode - Wikipedia, the free encyclopedia

Deinem Code-Schnipsel ist zu entnehmen, dass du einen [JAPI]Process[/JAPI] hast, von dessen InputStream du lesen willst?
Zeichenbasierte Streams liest man über einen [JAPI]InputStreamReader[/JAPI] aus und wrappt ihn gern in einen [JAPI]BufferedReader[/JAPI]:

BufferedReader reader = new BufferedReader(new InputStreamReader(process.getInputStream()));
String line;
while ((line = reader.readLine()) != null) {
    if (line.equals("exit")) {
        // Server killen
    }
}

 

[haui95]

Danke !

Ja, ich weiß auch nicht, inwiefern mir der Codeschnipsel aus dem Internet weiterhelfen kann,
auf jeden Fall war der Code den du gepostet hast auch schon recht hilfreich, da ich schon mit verschiedenen Output Streams versucht habe, das Problem zu lösen, es jedoch nicht hinbekommen habe.
Was mich jedoch wundert ist, dass, auch wenn mir der Code aus dem Internet nicht wirklich etwas bringt, dieser jedoch funktioniert und den CMD Befehl "cls" an der Stelle bei den Cast auf

byte

ausführt und den Inhalt des Fensters löscht.

Hier noch einmal der Codeausschnitt, da ich mich glaube ich einmal vertippt habe:

char c;
InputStream output = p1.getInputStream();
    while ((c = (char) output.read()) != -1) {
        if ((byte) c == 12) {
            ConsoleCmdGui.txtConsole.setText("");
        } else {
               [...]
        }
    }

MfG

 

[jnetdev]

1) Java-Bytecode ist mal ein ziemlich schlecht gewähltes Wort. Als ichs gelesen habe dachte ich an was total anderes.

2) Was meinst du mit "eigener Console in Java" ? Etwas was in einem Terminal läuft ? Das tun grundsätzlich alle Terminal-Programme ohne GUI. Oder meinst du eine eigene GUI die aussieht wie ein Terminal und ein ähnliches verhalten nachahmt ? Kann ich mir zwar nicht von dir vorstellen, ich weis aber das es sowas schon gibt.

3) Ich nehme mal an dein Problem bezieht sich auf folgendes Thema : http://www.java-forum.org/netzwerkp...va-chat-verbindung-server-fehlgeschlagen.html
Dort siehst du unten in dem Code den ich gepostet habe wie es richtig geht. Das "PrintStream.println()" muss nicht unbedingt sein, dient aber dem sauberen Abbau des Threads auf dem Server, ist also zu bevorzugen anstatt den Server-Thread gewaltsam nach Timeout mit Thread.interrupt() zu killen.


@xehpuk
Ich weis zwar auch das Thread.stop() deprecated ist, aber nicht wirklich wie diese mal ursprünglich geplant und implementiert war. Aber grundsätzlich würde ich mal schätzen das diese durch einen native call den Thread einfach gekillt hat. Und was macht interrupt ? Etwas ähnliches : native ein Flag setzen was die VM selbstständig prüft und mit einer Exception rausspringt. Ohne try-catch oder gesetzten Thread.UncaughtExceptionHandler hat es den selben effekt nur das es halt API-konform ist. Um einen Thread von außen zu killen sollte man in dessen Loop grundsätzlich ein von außen toogle-bares Flag prüfen. Für blocking-I/O hab ich mal was auf stackoverflow gelesen.

 

[Mujahiddin]

char c;
InputStream output = p1.getInputStream();
    while ((c = (char) output.read()) != -1) {
        if ((byte) c == 12) {
            ConsoleCmdGui.txtConsole.setText("");
        } else {
               [...]
        }
    }

Also dieser Codeschnipsel ist ja wirklich eigenartig, ich frage mich, wo du den herhast.

InputStream output

<-- meinst du das ernst?
Außerdem wandelt der Code einen byte in einen char um, um diesen dann wieder in einen byte umzuwandeln... Wozu das ganze, frag ich mich.

 

[haui95]

Ich galube, dass dieses

if ((byte) c == 12) {
      ConsoleCmdGui.txtConsole.setText("");
}

nur funnktioniert, weil sich Process an die Ausgangsströme von CMD anhängt, und somit auch den Befehl "cls" in Byteform abfragen kann. Nur wie würde es mit dem CMD Befehl "exit" aussehen ?

MfG

 

[haui95]

So hab es hinbekommen, indem ich einfach die Byte Werte beim Cast von

Char

auf

Byte

über

System.out.println((byte) c)

ausgegeben habe.

BufferedReader pOutput = new BufferedReader(new InputStreamReader(proc1.getInputStream()));
    while ((c = (char) pOutput.read()) != -1) {
        System.out.println((byte) c);
            if ((byte) c == 12) {
                ConsoleCmdGui.txtConsole.setText("");
            } else if ((byte) c == -1) {
                 System.exit(c);
            }
      }

 

[haui95]

Hmm...

habe mich gewundert, warum der CMD Prozess nach Beenden der Konsole im Taskmanager immer noch aktiv war, dabei habe ich garnicht berücksichtigt, dass ich meine Instanz von Process mit destroy() beenden muss.

else if ((byte) c == -1) {
     proc1.destroy();
     System.exit(proc1.exitValue());
} [...]

Nun frage ich mich aber, wie beim Eintippen des Befehls "exit" ein Return Code von -1 zustande kommt und kein Return Code von 0, also normales Beenden ?

MfG

 

[Hüte]

Wie gesagt, byte oder char kann doch gar net negativ werden. Für den Rest würde ich mal in der API nachschauen. Woher kommt denn des Beispiel überhaupt? Kannst du eine Referenz angeben?

Hüte

 

[xehpuk]

Etwas ähnliches : native ein Flag setzen was die VM selbstständig prüft und mit einer Exception rausspringt. Ohne try-catch oder gesetzten Thread.UncaughtExceptionHandler hat es den selben effekt nur das es halt API-konform ist.

Nein. Eine InterruptedException wird nur an wohldefinierten Stellen geworfen. Ein

Thread.stop()

kann den Thread an beliebiger Stelle rausschmeißen. Wenn dieser Thread also gerade dabei war, den Zustand eines Objekts zu ändern, ist dieses dadurch korrupt, die Anwendung insgesamt also kaputt.
Solange das Interrupted-Flag nicht überprüft wird, juckt es den Thread gar nicht.

Um einen Thread von außen zu killen sollte man in dessen Loop grundsätzlich ein von außen toogle-bares Flag prüfen.

Nein, das von mir gezeigte Konstrukt ist in Ordnung und common practice. Den Thread beendet man kontrolliert, indem man den Stream/Socket schließt.
Bei NIO geht es mit [JAPI]InterruptibleChannel[/JAPI] über ein normales

Thread.interrupt()

.

Nochmal im Klartext:

while ((c = (char) pOutput.read()) != -1)

ist Käse und äquivalent zu:

while (true) {
    c = (char) pOutput.read();
    // ...
}

Gehen wir von einer gängigen Zeichenkodierung aus (Windows-1252, UTF-8), dann bedeutet 12 an dieser Stelle, dass das Zeichen "Form feed" übertragen wurde, was ich nebenher auch für unwahrscheinlich halte.

Der Code ist also Quatsch. Ich kann mir auch nicht vorstellen, dass er funktioniert. Es wird immer nur auf ein Byte, nämlich 12, überprüft. Es kann also unmöglich an der Kombination der drei Zeichen "cls" liegen, dass die Bedingung eintrifft.

Wieso hältst du an dem Code fest? Löse es so, wie vorgeschlagen.