bugGNU Octave - Bugs: bug #44661, The "pause" command with...


bug #44661: The "pause" command with no parameter: strange behavior (GUI + Windows)

Submitter:  Giorgio De Nunzio <giorgio_denunzio>
Submitted:  Sun 29 Mar 2015 01:18:37 PM UTC
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 4.0.0 Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Thu 03 Dec 2015 04:27:16 AM UTC, comment #13: 

The code for kbhit/pause is completely different than the code for kbhit/pause.  I fixed the behavior on Windows in this cset http://hg.savannah.gnu.org/hgweb/octave/rev/a8ee668e7fd7.  This will be a part of the 4.0.1 bug fix release.

Rik <rik5>
Group administrator
Tue 02 Jun 2015 04:43:34 PM UTC, comment #12: 

Retagging release from 4.0.0-rc2 to 4.0.0.

John W. Eaton <jwe>
Group administrator
Sat 04 Apr 2015 07:28:41 PM UTC, comment #11: 

My guess is there is no easy solution.  Pause is a tricky issue, along with Cntrl-C/signaling, and the pager is another one I suppose.  These are low-level things that haven't been worked out in the GUI's asynchronous paradigm.

Dan Sebald <sebald>
Wed 01 Apr 2015 06:04:32 PM UTC, comment #10: 

Is there something simple here, an option to the Windows Terminal, which sets line buffering and which we could disable when we create the terminal?

Rik <rik5>
Group administrator
Mon 30 Mar 2015 06:16:07 PM UTC, comment #9: 

OK, thank you.  Sounds like a low level bug only made more confusing by the presence of the GUI.  Seems like a 4.0-critical issue if Windows is playing a more significant role now.

Dan Sebald <sebald>
Mon 30 Mar 2015 07:52:10 AM UTC, comment #8: 

Sorry, the sentence
"(so I am using octave.exe as the starting executable)"
had no sense because I was also using octave-cli.exe and octave-gui.exe.
What I wanted to say was that I was not starting by the vbs...

Giorgio De Nunzio <giorgio_denunzio>
Mon 30 Mar 2015 07:39:51 AM UTC, comment #7: 

Here I am.

Gone to the windows line command (cmd) then
cd C:\Octave\Octave-4.0.0-rc2\bin
(so I am using octave.exe as the starting executable)

(1)  octave-cli
I launch test_pause.m by Rik, everything is ok, four <enter> key strokes, each welcome by a number 1 to 4
BUT keys different from <enter> don't make the pause finish: they are bufferized and taken by the subsequent pause command.

(2) octave
the GUI opens, I launch test_pause.m: I need only two <enter> key strokes, and numbers appear in pairs: after the first <enter> I see 1 then 2, after the second <enter>, I see 3 then 4. Again, key strokes different from <enter> don't oblige the pause to finish, and are bufferized for the future...

(3) octave --no-gui
like (1)

(4) octave --no-gui-libs
like (1)

The automatically created Windows desktop start links to octave use octave.vbs in
instead of directly calling the various octave executables in
but the results (as said in the previous messages) are alike.
Best regards

Giorgio De Nunzio <giorgio_denunzio>
Mon 30 Mar 2015 06:35:41 AM UTC, comment #6: 

Could you try your same test with a couple more cases?

[system@] octave
You've indicated this configuration has problems

[system@] octave --no-gui
You've indicated this configuration has problems

[system@] octave --no-gui-libs

[system@] octave-cli

The first two cases activate the com interface with the Qt environment.  The latter two don't, if I recall correctly.

Dan Sebald <sebald>
Mon 30 Mar 2015 05:46:47 AM UTC, comment #5: 

I also checked the CLI version (that is, starting with octave.vbs --no-gui).
The behavior is almost identical.
Almost everything works the same: pause() returs only if I type <enter> and it does not return after any other key, bufferizing them all (so that they are taken by the following pause()s).
The difference is that the <enter> key does not leave the LF bufferized, so that the sequence:
pause <enter> [command starts and waits]
<enter> [command exits as expected]
pause <enter> [command starts and waits, no LF bufferized]
<enter>  [command exits as expected]
works fine. But when you insert a <any other key>, pause() does not exit, while the subsequent pause() exits immediately.
So for me the problem is not limited to the GUI: it is only the interpretation of the <enter> key that is different.

Giorgio De Nunzio <giorgio_denunzio>
Mon 30 Mar 2015 04:11:36 AM UTC, comment #4: 

There is something definitely wrong with the GUI and the terminal.  pause() is supposed to be a character-oriented input and any key hit, not just <RETURN>, should terminate the input.  However, on Windows it appears that the input is line-buffered.  I can type a whole sentence after running pause() and it is only when I hit <RETURN> that it is processed.

In the same vein, kbhit is supposed to return a single character and it too waits until a <RETURN> is pressed.

Rik <rik5>
Group administrator
Mon 30 Mar 2015 01:13:51 AM UTC, comment #3: 

Attached is a straightforward test script test_pause.m.

pause ();
disp ("1");
pause ();
disp ("2");
pause ();
disp ("3");
pause ();
disp ("4");

You should need to press Enter 4 times to proceed through the script and each key stroke will be numbered.  Executing on Linux in the CLI or GUI is fine.  On Windows XP, the CLI works fine.  It is only the GUI on Windows XP which has a problem.

Just to confirm, perhaps Giorgio can test whether running the CLI works for him.  If so, then this is a GUI terminal interaction problem.

(file #33484)

Rik <rik5>
Group administrator
Sun 29 Mar 2015 06:28:38 PM UTC, comment #2: 

Hi Dan, thanks for your reply.
Trying with any other keys (say "p" just to fix ideas) confirms imho that pause() really has buffering problems.

Pause() should return immediately after typing "p", but it doesn't. The key is buffered and pause() returns only when I press <enter>.

Here is what happens:
pause <enter> [octave waits as it has to]
p [octave still waits]
<enter> [octave returns, possibly for the "p"]
pause <enter> [octave returns immediately, possibly for the CR]
pause <enter> [octave returns immediately, possibly for the LF]
pause <enter> [octave waits and finally does its duty]

and so on.

If I enter more letters (e.g. "pp" instead of only one "p") and begin the same game, one more pause() will return immediately after being given.
Best regards

Giorgio De Nunzio <giorgio_denunzio>
Sun 29 Mar 2015 05:55:04 PM UTC, comment #1: 

That sounds plausible.  pause() is supposed to respond to any key.  What happens if you type a key other than Enter, say, 'p'?  Does pause() work as expected then?

Dan Sebald <sebald>
Sun 29 Mar 2015 01:18:37 PM UTC, original submission:  

Hi all, here is the strange behavior of the "pause" command, when used with no parameter, that I am experimenting in Windows.
In a sequence of "pause" commands, the first "pause" works (it waits until I press "enter"), the second doesn't (and returns immediately), the third works, the fourth doesn't... and so on.
IMHO, and without knowing anything about octave internal working, I'd suppose that the CR+LF given by the "enter" key is acting as a double entry, so that the CR makes the first "pause" to return, while the LF remains buffered, and is eaten by the second "pause", which returns as soon as it is issued.

Giorgio De Nunzio <giorgio_denunzio>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #33484:  pause_test.m added by rik5 (88B - text/x-objcsrc)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Updated the item)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by giorgio_denunzio (Submitted the item)
  • -email is unavailable- added by giorgio_denunzio

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.


    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-12-03 rik5 StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2015-06-02 jwe Release4.0.0-rc2 4.0.0
    2015-03-30 rik5 StatusNone Confirmed
    2015-03-30 rik5 CategoryOctave Function GUI
        SummaryThe &quot;pause&quot; command with no parameter: strange behavior The "pause" command with no parameter: strange behavior (GUI + Windows)
    2015-03-30 rik5 Attached File- Added pause_test.m, #33484
    2015-03-29 giorgio_denunzio Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-b921.
    Corresponding source code