Terminal.startScreen() may hide the cursor "permanently"

[GoogleCodeExporter]

Hi,

First of all I'd like to thank you for this wonderful library, that's actually 
the first time in ages I find a pure Java lib to build Text Based interfaces, 
so I'm very excited as I'm discovering it.

I'd like to share my experience here, which might be due to my not using the 
lib properly, as I had an annoying issue when running my first test program: 
after exiting, the cusor would not be visible, until I issues a "reset" command 
in order to reset the terminal.

After a quick look at the code, I seems to me that there is an issue with my 
using the startScreen, which hides the cursor here:
terminal.setCursorVisible(false);

Nowhere else in the source code (at least in release 2.1.1) is it called to 
show the cursor again.
May I suggest to add it in stopScreen() as follows ? :)

{quote}
diff --git 
a/3rd-party/lanterna/lanterna-2.1.1-sources/com/googlecode/lanterna/screen/Scree
n.java 
b/3rd-party/lanterna/lanterna-2.1.1-sources/com/googlecode/lanterna/screen/Scree
n.java
index 122f4a2..e833ea4 100644
--- 
a/3rd-party/lanterna/lanterna-2.1.1-sources/com/googlecode/lanterna/screen/Scree
n.java
+++ 
b/3rd-party/lanterna/lanterna-2.1.1-sources/com/googlecode/lanterna/screen/Scree
n.java
@@ -211,6 +211,7 @@
             return;

         terminal.exitPrivateMode();
+        terminal.setCursorVisible(true);
         hasBeenActivated = false;
     }

{quote} 

Thanks again

Jessé

Original issue reported on code.google.com by jli...@gmail.com on 21 Dec 2012 at 3:12

[GoogleCodeExporter]

By the way I forgot to specify I'm testing under the following environment:

Terminal emulator: KiTTY

System:
-bash-3.00$ uname -a
SunOS xxxxxxxxx 5.10 Generic_142901-02 i86pc i386 i86pc

-bash-3.00$ echo $TERM
xterm

-bash-3.00$ $JAVA_HOME/bin/java -version
java version "1.6.0_37"
Java(TM) SE Runtime Environment (build 1.6.0_37-b06)
Java HotSpot(TM) Server VM (build 20.12-b01, mixed mode)

Original comment by jli...@gmail.com on 21 Dec 2012 at 3:51

[GoogleCodeExporter]

Seems there's also something to do about interrupts, as a reset of the terminal 
displays the following information:

Interrupt set to control-C (^C).

Original comment by jli...@gmail.com on 21 Dec 2012 at 3:51

[GoogleCodeExporter]

My code does call exitPrivateMode, which seems to try and restore the terminal 
behaviour correctly through calls to stty commands, in 
restoreSpecialCharacters().
I initially thoughts the stty path was incorrect, but I was wrong. 
Manually invoking "/bin/stty intr ^C < /dev/tty" does restore the ability to 
interrupt through ctrl-c.

Original comment by jli...@gmail.com on 21 Dec 2012 at 4:17

[GoogleCodeExporter]

Sorry, seems I did not properly search for duplicates as the isse is already 
fixed on HEAD 
(http://code.google.com/p/lanterna/source/detail?r=008009a93c49b5b8b42ff3c23a11d
5780326d864)

Original comment by jesse.li...@ullink.com on 27 Dec 2012 at 9:41

[GoogleCodeExporter]

Yeah, sorry to take so long to reply, there is a fix to make the cursor visible 
again when exiting private mode committed, but I've yet to make a new release 
(2.1.2 is long overdue, I know, tomorrow I can cut it).

How about interrupts? I know there are some issues with it on Solaris, but I 
haven't been able to look into it yet. I take it this is still an issue for 
you? ctrl + d probably doesn't work either, after closing a lanterna-app, right?

Original comment by mab...@gmail.com on 2 Jan 2013 at 12:40

• Changed state: Accepted

[GoogleCodeExporter]

no worries, thanks for your reply anyway !

You're right, ctrl-d doesn't get restored either on exit. Haven't tested ctrl-Z 
either.

What I don' get is why the restoreSpecialCharacters() fails to restore the 
interrupts.
As I said in a previous comment, I managed to properly restore them by invoking 
exactly the same commands as the ones you are invoking.

I think I'll give it a try by running a minimal java program only calling 
UnixTerminal.disableSpecialCharacters() followed by 
disableSpecialCharacters.restoreSpecialCharacters() and see what happens.

By the way, don't know if you are able to rename this issue, but the title does 
not match the topic we are actually discussin now :) (shame on me for reporting 
already fixed issues :p)

Original comment by jli...@gmail.com on 2 Jan 2013 at 8:00

[GoogleCodeExporter]

After playing around with my sample program, I believe I identified why the 
restore commands do not work. It seems that the "restore character" needs to be 
wrapped with single quotes, otherwise stty will silently ignore.

For instance, for the moment, the following line is trying to restore ctrl c 
that way:
 exec("/bin/sh", "-c", "/bin/stty intr ^C < /dev/tty");
It should actually be written this way:
 exec("/bin/sh", "-c", "/bin/stty intr '^C' < /dev/tty");

I succesfully tested the above change on Solaris 10 x86.

Original comment by jli...@gmail.com on 3 Jan 2013 at 10:33

[GoogleCodeExporter]

Actually, when you issue the following commands, this shows what error happens:
-bash-3.00$ /bin/sh -c "/bin/stty intr ^C < /dev/tty"
/bin/sh: C: not found
-bash-3.00$ stty: : I/O error

-bash-3.00$ /bin/sh -c "/bin/stty intr '^C' < /dev/tty"
-bash-3.00

Escaping with single quotes is required because of passing the command to 
/bin/sh -c.

Original comment by jli...@gmail.com on 3 Jan 2013 at 10:57

[GoogleCodeExporter]

How about using the -g option of stty to save and restore the options ? I just 
came across this one when reading the man page:
     The -g flag is designed to facilitate the saving and restor-
     ing  of  terminal state from the shell level. For example, a
     program may:

     saveterm="$(stty -g)"      # save terminal state
     stty (new settings)        # set new state
     ...           # ...
     stty $saveterm                # restore terminal state

     Since the -a format is so loosely  specified,  scripts  that
     save and restore terminal settings should use the -g option.

Original comment by jli...@gmail.com on 3 Jan 2013 at 11:06

[GoogleCodeExporter]

Actually I see this is already reported in issue 50. Will 'cross post' my 
answer in it as it is more relevant than this issue which could be closed.

Original comment by jli...@gmail.com on 3 Jan 2013 at 3:59

[GoogleCodeExporter]

Excellent, I've been able to verify it works with stty -g like your example 
above. Thank you for fixing this! Committing to 2.1.x and default, I'll make a 
new 2.1.x release as soon as I've gone through the remaining issues.

Original comment by mab...@gmail.com on 4 Jan 2013 at 2:00

• Changed state: Fixed

[GoogleCodeExporter]

Issue 50 has been merged into this issue.

Original comment by mab...@gmail.com on 4 Jan 2013 at 2:01