So, actually I was using this behavior as a way to interact with octave-cli via stdin/out. That is, I wrote a vscode debugger for octave which communicates with the octave-cli process through stdin/out. Since the user sends keyboard events to vscode, these are translated to stdin sequences.

I just confirmed on windows that version 5.2.0 when using pause requires an keypress received directly by the octave-cli process to continue execution, while version 5.1.0 can be unlocked via stdin.

Maybe we can find a halfway where we can set octave to one of two modes. stdio mode (previous behavior) or a interactive mode (current behavior). That way I could select the mode via some bool, and everyone is happy. How does that sound?

Correct, this bug is fixed on the Octave stable branch after 5.1.0 was already tagged, it will be part of version 5.2.0.

@Pantxo do you want another bug report for the remaining raw mode improvement, or will you keep track of that yourself?

This is finally fixed on the stable branch now

https://hg.savannah.gnu.org/hgweb/octave/rev/c3716220d5b9

This patch also works for me, and maybe is a bit clearer since it groups the 'std::cin' along with the 'clearerr (stdin)':

--- a/libinterp/corefcn/sysdep.cc
+++ b/libinterp/corefcn/sysdep.cc
@@ -617,7 +617,10 @@ namespace octave
     int c = std::cin.get ();

     if (std::cin.fail () || std::cin.eof ())
-      std::cin.clear ();
+      {
+        std::cin.clear ();
+        clearerr (stdin);
+      }

     // Restore it, enabling system call restarts (if possible).
     octave::set_interrupt_handler (saved_interrupt_handler, true);

@Pantxo The following quick and dirty patch fixes this issue completely for me.

--- a/libinterp/corefcn/sysdep.cc
+++ b/libinterp/corefcn/sysdep.cc
@@ -466,6 +466,7 @@ namespace octave
         }

       tcsetattr (tty_fd, wait ? TCSAFLUSH : TCSADRAIN, &s);
+      clearerr (stdin);
     }
 #elif defined (HAVE_TERMIO_H)
     {

I haven't tried putting it at different places in the process, or trying to see exactly where the EOF condition is triggered, but this particular call to 'clearerr' in the 'raw_mode' helper function fixes all problems for me.

Is this safe? Can we start from here and make something safer if needed?

@Mike: "running octave --no-line-editing and calling 'kbhit(1)' causes Octave to exit immediately".  You mean, it segfaults?  Ugh.

I have setup a virtual box with Fedora 29 (this took me hours) and couldn't find anything to make kbhit work as expected (this took me hours also :-)).

As Mike has shown, "kbhit (0)" works once and then returns immediately afterwards. The first times, std::cin.get() manages to retrieve a charater but std::cin's error flags (fail and eof) are set. Even after clearing those flags and doing a seekg(0), we can never get the terminal to returns into actual raw_mode and std::cin.get() always returns -1.

This is strange: why should the failbit be set when the read succeeded?

Also when using a timeout (VTIME > 0 and VMIN = 0) the observed behavior with glibc 2.28 does not match termios doc:

>> ... read(2) returns either when at least one byte of data is available, or when the timer expires. [1]

I setup a 2s timeout (using the patch from comment #49) and saw that the first call to "pause ()", when it seemingly works, does not exactly do that: std::cin.get() returns the character after the timeout, even though the character has been typed well before.

I am lost.

[1] http://man7.org/linux/man-pages/man3/termios.3.html

And sorry for not having the courage to setup a system with glibc2.29 myself.

Michael - like I said earlier (comment #44), I now have glibc 2.28. I was unable to reproduce back in November when Debian still used glibc 2.27.

Pantxo - I don't know for sure, but I think calling std::cin.clear may only affect the error flags at the C++ streams level, not at the C FILE streams level?

Maybe something like 'std::cin.seekg (0, std::ios::cur)' would work, since that is documented to call 'fseek' on the underlying C stream, which should also clear the C-level state of the stdin stream.

No, this patch only makes things worse on my system.

On stable (ada14ef3067f), I still have the original behavior described here.

With this patch applied, pause now seems to swallow characters randomly and still does not return on the first or any key press, only on Ctrl+C.

If I run 'pause' with no args and then enter 'asdf' followed by Ctrl+C, first without the patch:

>> pause
asdf^C
>> kbhit
ans =
>>

And with the patch applied:

>> pause
sd
>> kbhit
ans =

It now sometimes requires 2 or more Ctrl+C to break out of pause, the first one is sometimes discarded/ignored.

As mentioned below in #46 this appears to be due to an incompatibility
between glibc 2.27 and 2.28.

Thus a fix is required for glibc 2.28 (and presumably above)
in order to clear the entry in

https://wiki.octave.org/wiki/index_php?title=Bug_Fix_List_-_5.0_Release

Bugs marked as regressions

Since glibc 2.28 is the current release on Fedora 29
this bug should be resolved before the Octave 5.0 release.

I just built the stable branch (rev 67724e9f6661) on Debian testing and in a Flatpak build environment on the same system, with all optional dependencies disabled in the build.

Running on the Debian testing host, with glibc 2.28, pause with no arguments hangs indefinitely as reported in this bug. Ctrl+C in pause returns and then kbhit returns an empty string indefinitely after that.

Running in the Flatpak container environment, with glibc 2.27, pause with no arguments returns immediately on a key press, the expected behavior.

I can now reproduce this issue on Debian with Octave 5.0.1. This may correspond to the recent glibc transition from 2.27 to 2.28, because I was previously unable to reproduce this back in November, when Debian testing still had glibc 2.27.

With Pantxo's kbtest script, the character that was typed is returned correctly. But after calling pause once and Ctrl+C to break out of it, kbtest says "Caught ''".

On Fedora 28 it is kind of hit-and-miss:

octave:11> disp ("Type a character")
Type a character
octave:12> pause (5)
aoctave:13> c = kbhit (0)
c = a
octave:14> disp ("Type a character")
Type a character
octave:15> pause (5)
aoctave:16> c = kbhit (0)
c =
octave:17> disp ("Type a character")
Type a character
octave:18> pause (5)
aoctave:19> c = kbhit (0)
c = a
octave:20> disp ("Type a character")
Type a character
octave:21> pause (5)
aoctave:22> c = kbhit (0)
c =

Dmitri.
--

I think that what I got is consistent with Dmitri:

I also tried:
octave:19> disp ("Type a character")
Type a character
octave:20> pause (15)
c=kbhit(0)
a
octave:21> c=kbhit(0)
c =

==================
I extended the time to 15sec so that I could enter
c=kbhit(0)
a
before time ran out.

This is what I get with the current dev:

octave:3> disp ("Type a character")
Type a character
octave:4> pause (5)
aoctave:5> c = kbhit (0)a
parse error:

  syntax error

>>> c = kbhit (0)a
                 ^

(On Fedora 29)

Dmitri.
--

John,

Since you are the author of sysdep.cc which containd
kbhit (), do you have an idea of why it is broken in
Fedora 29?

I also observe the following on Fedora 29. When Octave starts, the 'kbhit' function behaves correctly. However, after calling 'pause' with no arguments, and breaking out of it with Ctrl+C, the 'kbhit' function now returns an empty string immediately for the remainder of the Octave session. This agrees with the change that Dmitri bisected to, which uses 'octave::kbhit' inside of an infinite loop. The 'octave::kbhit' function continues to return -1 inside that loop, no matter how many keys are pressed, so the loop is never broken until the user issues an interrupt.

https://hg.savannah.gnu.org/hgweb/octave/rev/f7b205562f1d

Looks like the bad revision.

Dmitri.
--

I can also confirm that hg id 1c6dd836bca9
(pre 511295347a27) still has a problem on my (Fedora 29) computer.

Dmitri.

To clarify my statement:
I still have a coputer with Fedora 28 on it. i just built
a current dev tip and it does not show the problem.

Dmitri.

No -- by mistake i was applying to stable branch that is why the patch was rejected. When i applied to dev, instead of fix I got even worse behaviour.

BTW -- I tried on Fedora 28 computer and I do not see this bug there. I doubt Fedora changed terminal interface between those
two versions.

Dmitri.

hg update -r 511295347a27^  did not fix the problem.
Sorry.

I attached an updated version of the patch, with a log and an implementation for Windows also. As for sgtty terminal interface, the "raw_mode" function was already incomplete and I don't expect modern platforms to not have termios or termio at least.

@Dmitri: That is strange, I can't imagine why a patch could be entirely rejected...

(file #45455)

Patch failed for me:

patch -p1 < ~/Downloads/pause_timeout.patch
patching file libinterp/corefcn/sysdep.cc
Hunk #1 FAILED at 358.
Hunk #2 FAILED at 405.
Hunk #3 FAILED at 448.
Hunk #4 FAILED at 540.
Hunk #5 FAILED at 549.
5 out of 5 hunks FAILED -- saving rejects to file libinterp/corefcn/sysdep.cc.rej
patching file libinterp/corefcn/sysdep.h
Hunk #1 FAILED at 40.
1 out of 1 hunk FAILED -- saving rejects to file libinterp/corefcn/sysdep.h.rej
patching file libinterp/corefcn/utils.cc
Hunk #1 FAILED at 1287.
1 out of 1 hunk FAILED -- saving rejects to file libinterp/corefcn/utils.cc.rej

I assume you have a Mercurial clone of the development branch.  Try updating to the parent of the problem changeset.

hg update -r 511295347a27^

The '^' asks Mercurial for the parent of the named revision.

Once there, build as usual, run-octave, try pause() and see if it hangs.

--Rik

I'd bet the bisection is not necessary, I'm 99% sure it's due to cset 511295347a27. As for the system dependent behavior, we use a "raw_mode" function to capture keyboard entries and the implementation depends on the kind of terminal interface in use (termio, termios or stty).
If someone can confirm that cset 511295347a27 is at fault, I'll try to rework this.

@Dimitri

I tried compared ./run-octave with ./run-octave -cli?

They behave the same.

I am not able to reproduce this on Debian with readline 7.0. I tested both with libreadline7 provided by Debian (currently at 7.0 patchlevel 3) and with my own self-built readline from git (currently at 7.0 patchlevel 5).

Are the only users affected by this on Fedora 29?

Has anyone affected by this compared ./run-octave with ./run-octave -cli?

@Rik,

I get:
[godfrey@pbdsl4 ~]$ octave -f -q --no-line-editing
octave:1> pause
aaaa^C
octave:1>

As you said, I also get

>>without readline, octave quits on Ctrl-C (rather than returning to interpreter).

without readline, octave quits on Ctrl-C (rather than returning to interpreter). Pause still ignores keybord input.

Dmitri.

Just to keep up-to-date, I am now testing with:
octave:1>  _octave_config_info_ ("hg_id")
ans = 8b6f1731474b

@Dimitri  That is exactly what I reported.

and:

>>@Michael: Maybe try starting with '-f' to avoid reading any configuration files in case it is something with your personal .octaverc or with the OS' base configuration.

Tried that:
octave:1> pause
xxx^C
octave:1>

No change in behavior.

There might be something else going on.  pause with no argument works for me.  I tried both CLI and GUI versions of Octave.

@Michael: Maybe try starting with '-f' to avoid reading any configuration files in case it is something with your personal .octaverc or with the OS' base configuration.

You might also want to move your .inputrc file to a new name in case Readline is causing the issue.

As of HG 1861e2ea0a4b pause
with no argument hangs Octave.
Typing any character or CR only echos the text.
^C is required to exit Octave.

Again this is using FC29 current update.