The next major release of Octave will be 6.1 and that should occur at the end of 2019/beginning of 2020.

@genadij: Yes, you precisely installed the Octave version that has this bug :-). It should be gone in the next released version.

@Philip: Great, thanks for testing.

@Panxto:
I just returned from a week abroad. Somewhere this week I'll try the fix.

I pushed the change under Mike's name here (https://hg.savannah.gnu.org/hgweb/octave/rev/7894624afc47).  If it doesn't work, I'm sure we'll here about it.

I am also impacted by this bug, on Windows only, Octave 5.1.0. Looking forward to the next release with this patch.

The kbhit(); workaround is working for me for now.

I have a suspicion about this bug. It's Windows specific, which means it may be caused by the Windows specific section of code here:

https://hg.savannah.gnu.org/hgweb/octave/file/4388526646ef/libinterp/corefcn/sysdep.cc#l596

Now I don't really know how these functions work on Windows, but it looks to me like in non-blocking mode, it's either returning a valid character or the value 0 if no keys were pressed.

Can someone please test a patch on Windows that simply returns -1 instead of 0 in that ternary expression?

In the Unix section of code, the return value when no character is available is 'EOF', which is defined to be -1 in stdio.h.

Meanwhile, in the new 'octave::sleep(inf)' section of code that was added in Octave 5.1, 'octave::kbhit' is called in a loop, and any non-negative value, including 0, breaks out of the loop. So that may explain why this returns immediately on Windows.

https://hg.savannah.gnu.org/hgweb/octave/file/4388526646ef/libinterp/corefcn/utils.cc#l1295

Using 'hlog -k pause' I think these changesets should be examined

changeset:   26026:511295347a27
user:        Pantxo Diribarne <pantxo.diribarne@gmail.com>
date:        Wed Oct 31 23:07:19 2018 +0100
summary:     Allow pause state to be changed (bug #53723)

changeset:   25961:f7b205562f1d
user:        Pantxo Diribarne <pantxo.diribarne@gmail.com>
date:        Mon Oct 22 16:34:06 2018 +0200
summary:     Allow graphics events to be processed while pause is active (bug #53729)

They are roughly equivalent, unless you care about plots.

If you have a plot active, then the intent is that 'pause()' still allows plots and graphics to be resized or zoomed or otherwise interacted with, while 'kbhit()' stops everything until a key is pressed.

For your usage, simply waiting for a user to press a key to continue, they are equivalent.  Try 'help kbhit' to see the documentation.

 -- kbhit ()
 -- kbhit (1)
     Read a single keystroke from the keyboard.

     If called with an argument, don't wait for a keypress.

     For example,

          x = kbhit ();

     will set X to the next character typed at the keyboard as soon as
     it is typed.

          x = kbhit (1);

     is identical to the above example, but doesn't wait for a keypress,
     returning the empty string if no key is available.

     See also: input, pause.

The kbhit function also doesn't echo the character to string (whatever it was) the way that pause does.

pause() works on Linux where I can test it.  Something must have changed with the Windows implementation.

Can you try

x = kbhit ()

Does this return immediately, or wait for you to hit a key on the keyboard?

I can reproduce this bug, it only happens when the command is called without arguments. Otherwise, it works fine.

>> OCTAVE_VERSION
ans = 5.1.0
>> computer
x86_64-w64-mingw32
>> tic, pause(), toc
Elapsed time is 0.100191 seconds.
>> tic, pause, toc
Elapsed time is 0.100247 seconds.
>> tic, pause(5), toc
Elapsed time is 5.00048 seconds.
>> tic, pause(1), toc
Elapsed time is 1.00014 seconds.

This doesn't sound anything like bug #55029, not a duplicate.

Can someone with Octave on Windows reproduce this?

This bug is reported against MS Windows.  Bug #55029 is about a problem on Linux with the underlying glibc.  It might not be a true duplicate?

I know the underlying kbhit function is different on Windows than it is on Linux.