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

Submitted by:  Tasos Papastylianou <tpapastylianou>
Submitted on:  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

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

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

We have this code block in octave.cc:

    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>
Project Member
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>
Project 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:

        // 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>
Project Member
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.

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>
Project Member
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";

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

on a Windows 10 machine. When this is run,

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


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.

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:

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)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project 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

    Powered by Savane 3.6