bugGNU Octave - Bugs: bug #60453, Input function on windows fails to...

 
 

bug #60453: Input function on windows fails to trim carriage return character when running in batch mode

Submitter:  Tasos Papastylianou <tpapastylianou>
Submitted:  Sun 25 Apr 2021 10:10:38 PM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Confirmed Assigned to:  None
Originator Name:  Tasos Papastylianou Open/Closed:  * Open
Release:  * dev Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 03 May 2021 01:54:50 PM UTC, comment #6: 

We have this code block in octave.cc:
https://hg.savannah.gnu.org/hgweb/octave/file/26af8b64a739/libinterp/octave.cc#l403

    if (m_options.gui ())
      {
        if (m_options.no_window_system ())
          {
            std::cerr << "error: --gui and --no-window-system are mutually exclusive options" << std::endl;
            octave_print_terse_usage_and_exit ();
          }
        if (! m_options.line_editing ())
          {
            std::cerr << "error: --gui and --no-line-editing are mutually exclusive options" << std::endl;
            octave_print_terse_usage_and_exit ();
          }
        if (m_options.server ())
          {
            std::cerr << "error: --gui and --server are mutually exclusive options" << std::endl;
            octave_print_terse_usage_and_exit ();
          }
      }


That makes me believe that we might need to take care in the initialization of the interpreter to not use a combination of settings that we need to avoid presumably. (In this case, running the GUI combined with setting `line_editing = false;`.)

Is there an easy way to check during interpreter initialization if we are using the GUI?

Markus Mützel <mmuetzel>
Group administrator
Fri 30 Apr 2021 03:33:27 PM UTC, comment #5: 

Starting at the other end with the input() function itself, the code is very simple


  octave::input_system& input_sys = interp.get_input_system ();

  return input_sys.get_user_input (args, std::max (nargout, 1));


Maybe the constructor for either the interpreter or the input_system is called differently or not initialized fully when Octave believes it is running in batch mode.

In Octave's defense, batch mode is not meant to be interactive.  Typically a programmer develops a script in interactive mode, tests it with sample data, and when it is completely debugged it is ready for using in batch mode where you call "octave script data_file".

Because it is uncertain how, and therefore when, this will be fixed I would just use the simple workaround of adding "--no-gui" to the command line when running scripts like this.

 Rik <rik5>
Group administrator
Mon 26 Apr 2021 06:16:40 PM UTC, comment #4: 

I can confirm with Octave 6.2.0 and a recent build from the default branch on Windows. But only when using the GUI.
When started with "--no-gui" it works as expected.

I guess that for some reason only the (Linux line ending) LF is stripped instead of the complete Windows line ending CRLF.
Maybe something should be opened in text mode but it is opened in binary mode?

It also works if I force using readline with "--line-editing".

Maybe we should always assume the Octave is run interactively if it is starting with GUI?

Maybe something around these lines of code needs to be adapted:
https://hg.savannah.gnu.org/hgweb/octave/file/e8e9f815945a/libinterp/corefcn/interpreter.cc#l568

        // If stdin is not a tty, then we are reading commands from a
        // pipe or a redirected file.
        bool stdin_is_tty = octave_isatty_wrapper (fileno (stdin));

        m_interactive = (! is_octave_program && stdin_is_tty
                         && octave_isatty_wrapper (fileno (stdout)));

        // Check if the user forced an interactive session.
        if (options.forced_interactive ())
          m_interactive = true;

        line_editing = options.line_editing ();
        if ((! m_interactive || options.forced_interactive ())
            && ! options.forced_line_editing ())
          line_editing = false;


 Markus Mützel <mmuetzel>
Group administrator
Mon 26 Apr 2021 02:08:19 PM UTC, comment #3: 

I updated to 6.2.0, and saw the same behavior. The batch file now contains

@echo off
C:\Octave\Octave-6.2.0\octave.vbs --eval batchTest('%~dp0')
cmd /c

for the updated version (removal of "--force-gui" was required for it to work).

The Octave script batchTest.m excerpt is unchanged from below, including the output with the carriage return coming from the input function.

Tasos' good suggestion of using 'strtrim' still works, but this was a subtle error that was hard to catch, and I'm not sure I ever would have figured it out without his help.

 Anonymous
Mon 26 Apr 2021 04:18:21 AM UTC, comment #2: 

Octave 4.4 is old and no longer supported.
Can you reproduce the error with Octave 6.2?

Markus Mützel <mmuetzel>
Group administrator
Mon 26 Apr 2021 01:31:32 AM UTC, comment #1: 

Tasos helped me on Stack Overflow. I use a batch file:

@echo off
C:\Octave\Octave-4.4.1\octave.vbs --force-gui --eval batchTest('%~dp0')
cmd /c

to execute the Octave function:

%%%%
s1 = "abcd";
double(s1)

s2 = input('Input:  ',"s");
double(s2)
%%%%

on a Windows 10 machine. When this is run,

double(s1) = 97 98 99 100 (as it should)

but

double(s2) = 97 98 99 100 13

when typing "abcd" and hitting "enter" for the input function. This only occurs when executing from the batch file, where it seems that the carriage return (Tasos pointed out that the 13 is the ASCII number for the "\r" carriage return character) is also being errantly placed into the string. Alternatively, using Octave directly with this function correctly results in

double(s1) = double(s2) = 97 98 99 100

As Tasos also pointed out, this can be overcome with the use of the "strtrim" function, i.e.

double(s1) = double(strtrim(s2)) = 97 98 99 100,

but the behaviors are different when using Octave directly vs. execution via the batch file.

 Anonymous
Sun 25 Apr 2021 10:10:38 PM UTC, original submission:  

For details please see this stackoverflow post: https://stackoverflow.com/q/67245152/4183191

My apologies, I cannot test this personally on a windows system.
Perhaps the user of that post may be able to answer more questions if the bug is not immediately replicable. I will invite them here.

 Tasos Papastylianou <tpapastylianou>

 

(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 rik5 (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by tpapastylianou (Submitted the item)

    •  

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

    Date Changed by Updated Field Previous Value => Replaced by
    2021-04-26 mmuetzel CategoryNone Octave Function
        StatusNeed Info Confirmed
        Release4.4.1 dev
    2021-04-26 mmuetzel StatusNone Need Info

    Back to the top

    Copyright © 2024 Free Software Foundation, Inc.
    Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
    The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team.
    Page source code

    Powered by Savane 3.14-f13d.
    Corresponding source code