bugGNU Octave - Bugs: bug #54621, kbhit does not return on...

 
 

bug #54621: kbhit does not return on non-interactive shell

Submitter:  Andreas von Borany <aborany>
Submitted:  Wed 05 Sep 2018 08:17:45 AM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Wont Fix Assigned to:  None
Originator Name:  Andreas von Borany Open/Closed:  * Closed
Release:  * 4.4.0 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 12 Oct 2018 04:41:03 PM UTC, comment #8: 

I haven't used Robot Framework before, but I just read up a bit, and it seems that it is simply not designed for testing CLI applications thoroughly.

The same will be true of any testing framework that doesn't take care of what the program stdin is attached to. If stdin is a terminal or a pipe, then Octave will run as if it's waiting for input from the other end of that terminal or pipe.

A non-portable solution would be to use it like this


Run Process    octave-cli script.m < /dev/null    shell=True …


The discussion on this bug report shows that the Robot Framework Process library is not suited or prepared to work with CLI programs that interact with stdin at all.

Mike Miller <mtmiller>
Group Member
Fri 12 Oct 2018 01:57:27 PM UTC, comment #7: 

We have scripts which are run from within octave (where keyboard inputs are valid and are handled within the script) and the same scripts are executed in a command line script on our contigous integration server (where no input is expected). In the second case we just handled the 'empty' input , which was previously returned and the script was executed fully. With the new octave we have the problem that the function does not return at all and therefore the script stalls.

The script is run in in a robot shell process (http://robotframework.org/robotframework/latest/libraries/Process.html) via octave-cli.

Andreas von Borany <aborany>
Wed 19 Sep 2018 06:40:12 PM UTC, comment #6: 

I would also point out that the function linked (https://de.mathworks.com/matlabcentral/fileexchange/30622-non-wait-detection-of-keyboard-input-including-mex-implementation) is not part of Matlab, but is a function contributed by a user.

What does Matlab's input function do in a similar situation?

What is the definition of "interactive" here?  How are you running your script so that you consider it to be in a "non-interactive" mode?

John W. Eaton <jwe>
Group administrator
Wed 19 Sep 2018 06:30:08 PM UTC, comment #5: 

I see, I misunderstood this bug report from the beginning. You are reporting the new fixed behavior of 'kbhit' as a bug, when it was actually a fix for the incorrect behavior that you want to be restored.

Yes, in versions of Octave prior to 4.4, the 'kbhit' function returned immediately without waiting for user input. It is useful to be able to call this function in a user script or program, similar to the 'input' function. The 'input' function has always waited for user input in both interactive and non-interactive mode, and now the 'kbhit' function does also for consistency.

If you want to discuss alternative behaviors, the possibility of a new function with a different behavior, or ask about the usefulness of one behavior against the other, please use either the Octave help (https://lists.gnu.org/mailman/listinfo/help-octave) or maintainers (https://lists.gnu.org/mailman/listinfo/octave-maintainers) mailing lists.

Mike Miller <mtmiller>
Group Member
Thu 06 Sep 2018 12:38:21 PM UTC, comment #4: 

Of course I could do that or adopt my script, but what would be the reason of not returning an empty string when we are in a non-interactive shell (would be far more convenient).

In Matlab a similar function is provided (https://de.mathworks.com/matlabcentral/fileexchange/30622-non-wait-detection-of-keyboard-input-including-mex-implementation) which is also returning.


Andreas von Borany <aborany>
Wed 05 Sep 2018 06:31:05 PM UTC, comment #3: 

Yes, kbhit waits for input when it is called and correctly returns the key that was hit, whether Octave is running interactively or not.

If you want kbhit to return immediately without waiting for some reason, then you might want to look at redirecting stdin to something other than a terminal, for example an empty file or /dev/null. If you need further help, you can use the help mailing list (https://lists.gnu.org/mailman/listinfo/help-octave).

Mike Miller <mtmiller>
Group Member
Wed 05 Sep 2018 06:23:27 PM UTC, comment #2: 

We have tested octave 4.4.0 and there the given fix is already included. The problem is that kbhit in an non-interactive shell does not return but waits for a key pressed.

I think this issue is related to the change you have mentioned, because this behavior is new in octave 4.4.0 (the mentioned change removed the check

if (octave::application::interactive ())"


This leads to the effect that you can not rely on the fact that kbhit returns in non-interactive shells.

Andreas von Borany <aborany>
Wed 05 Sep 2018 06:00:43 PM UTC, comment #1: 

Thanks for the bug report. This issue has already been reported and fixed (see bug #53412 and the fix at https://hg.savannah.gnu.org/hgweb/octave/rev/10ec5795bd06). If you are able to update to the current Octave 4.4 release on your system, please do so to get the fix for this bug and many others.

Mike Miller <mtmiller>
Group Member
Wed 05 Sep 2018 08:17:45 AM UTC, original submission:  

Function kbhit does not return on non-interactive shell.

If a script that contains kbhit is executed in an non-interactive shell kbhit does not return and waits for input (which is obviously not possible in non-interactive mode).

In octave version 4.2.1 kbhit returns an empty string if called in non-interactive shells.

Andreas von Borany <aborany>

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

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 aborany (Submitted the item)
  • -email is unavailable- added by aborany
  •  

    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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-09-19 mtmiller Carbon-CopyRemoved 80942 -
    2018-09-19 mtmiller StatusFixed Wont Fix
    2018-09-05 mtmiller StatusNone Fixed
        Open/ClosedOpen Closed
    2018-09-05 aborany Carbon-Copy- Added aborany

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code