bugGNU Octave - Bugs: bug #54672, Unexpected behavior on first...


bug #54672: Unexpected behavior on first input, due to ~/.inputrc

Submitted by:  Michael Godfrey <godfrey>
Submitted on:  Mon 17 Sep 2018 02:59:19 PM UTC  
Category:  Documentation Severity:  2 - Minor
Priority:  3 - Low Item Group:  Documentation
Status:  Need Info Assigned to:  None
Originator Name:  Godfrey Open/Closed:  Closed
Release:  dev Operating System:  GNU/Linux

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)

Thu 13 Dec 2018 06:18:01 AM UTC, comment #22:

I think this issue has been hashed out, and is mostly Readline rather than Octave.  Can we close this report?

Rik <rik5>
Project Administrator
Mon 24 Sep 2018 06:01:11 PM UTC, comment #21:

Well, what confused me is the xterms ran correctly
with the vi setting as did everything else except
Octave. Therefore, I took an interest in Octave.

Of course, I did not understand all of the vi implications,
but vi itself worked, too.

Michael Godfrey <godfrey>
Project Member
Mon 24 Sep 2018 05:04:38 PM UTC, comment #20:

Oh, I see. I think your interpretation of the configuration is not correct. The configuration was not wrong or conflicting with Octave in some way. I assumed that when you discovered it was the cause, that you knew how vi mode works with readline.

The configuration file 'set keymap vi' was putting your input into vi command mode instead of insert mode. If you are familiar with vi, this means that any keys you input are commands instead of sent to the input buffer. When you pressed the 'c' key, readline went into replace-and-insert mode. If you had typed the 'a' key it would have gone into append mode. But the 'e' key, for example, only advances the cursor, so it would have seemed to be doing nothing. The 'j' and 'k' keys scroll through the command history.

This is an entirely valid configuration to be in with respect to how readline works and doesn't have anything to do with Octave in particular at all.

When I start a Python interactive shell with the same .inputrc, I get the exact same behavior, it starts in vi command mode.

Does this help explain why there is not really anything wrong with this configuration, and therefore why I think there is nothing for Octave to detect or warn about?

Mike Miller <mtmiller>
Project Administrator
Mon 24 Sep 2018 04:54:06 PM UTC, comment #19:

I just meant that:
set keymap vi
as the contents of user local .inputrc causes
Octave CLI to not function properly.

To me, that suggests that this content is not
"compatible" with the Octave settings.

Michael Godfrey <godfrey>
Project Member
Mon 24 Sep 2018 04:50:34 PM UTC, comment #18:

I don't know what an "incompatible" .inputrc file means, so I don't know what it means to address that.

The .inputrc file you had was valid syntax and was a valid, although unexpected for you, configuration. Other programs would have read the .inputrc file in the same way and operated the same way.

If the .inputrc configuration has a syntax error, on the other hand, then readline will definitely print a warning about it.

Mike Miller <mtmiller>
Project Administrator
Mon 24 Sep 2018 04:37:34 PM UTC, comment #17:

Rik et. al.

I agree with what you have said. And, the settings that
I now have work for me. The only issue that may be worth
thinking about is the case of a user having an "incompatible"
.inputrc, i.e. one that conflicts with the Octave one.

Maybe, at least, mention in the Manual that care should be
taken when providing a user .inputrc.

In my case, I forgot about the Octave requirements when
trying some experiments with my .inputrc and then forgot
to remove the last experiment. So, all my fault, but could
happen to others...

Michael Godfrey <godfrey>
Project Member
Mon 24 Sep 2018 03:58:53 PM UTC, comment #16:

@Michael: I also use a complicated VI-based setup for my .inputrc.  I looked at my file and I use this construct

# Set overall mode to vi
set editing-mode vi

rather than

set keymap vi

to switch modes.  You might try this.  When I start Octave I am automatically in "insert" mode and can just begin typing.  I then use <ESC> to exit insert mode and enter command mode where default VI-bindings like '0' to start of line or '$' to end of line work.

I'm also with Mike, in that I expect my own preferences in ~/.inputrc to override all other defaults.  For a while the terminal in the Octave GUI did not do this and it made me give up the GUI.

Rik <rik5>
Project Administrator
Tue 18 Sep 2018 10:05:54 PM UTC, comment #15:

This is useful. Important to check what Matlab does.

And, whatever choice emerges, clear documentation of it
will help a lot.

Michael Godfrey <godfrey>
Project Member
Tue 18 Sep 2018 09:14:41 PM UTC, comment #14:

I agree that I am not the right person or example audience to figure out how this should be documented (including the possibility of a warning message).

I would recommend avoiding the word "unpredictable", because everything you experienced is entirely predictable and well behaved, maybe not obvious or clearly described.

In order to remove myself from the decision process, I would recommend comparing the behavior of Octave with other programs that also use readline and are affected by the user's ~/.inputrc or lack thereof. I have already tested Python and verified that it behaves the same as Octave when I run a Python interactive shell, and no warning message is printed about the existence of ~/.inputrc. How does GNU bc behave? How about gdb, guile, or units? I guess that most or all of them silently load ~/.inputrc.

Mike Miller <mtmiller>
Project Administrator
Tue 18 Sep 2018 07:20:45 PM UTC, comment #13:


First, I meant to indicate:
## Re-read user's personal inputrc to give precedence over Octave's default.
inputrc = getenv ("INPUTRC");

which is what is done. Replace was not the right word.
Modify in unpredictable ways would have been better.

And, I can understand that in your case, since you knew
what you were doing, a warning would not be helpful. That
does not imply that it would never be helpful. But, it does
not seem the best choice to tailor Octave only for people
who have had the time and energy to learn all of its details.

So, I still think that for many users a warning that applying
their .inputrc over Octave's can have unexpected side-effects
would save them debugging time in the cases where it goes

Michael Godfrey <godfrey>
Project Member
Tue 18 Sep 2018 06:43:31 PM UTC, comment #12:

No, I don't think a message on the terminal output would be useful.

The user's ~/.inputrc does not replace the Octave default, it supplements it. If I have a ~/.inputrc that only has one rule, let's say it binds the Left arrow key to delete the previous character, then the Octave default inputrc that binds the Up and Down arrow keys is still applied.

If my ~/.inputrc does bind the Up and Down arrow keys differently from Octave's default, then I definitely do want ~/.inputrc loaded last to overwrite the Octave defaults. And I don't want to see a warning message about that, that's just the way readline is supposed to work.

Mike Miller <mtmiller>
Project Administrator
Tue 18 Sep 2018 04:27:53 PM UTC, comment #11:

Would it be useful to include a message in the case
that the user .inputrc replaces the Octave default?

I was not aware that this was the intended behavior
and therefore had considerable effort discovering
what was happening. It is not likely that many users have
carefully read Section 2.4 of the Manual.

Michael Godfrey <godfrey>
Project Member
Tue 18 Sep 2018 04:03:55 PM UTC, comment #10:

Yes, it is a good idea to allow the user's ~/.inputrc to override Octave's default inputrc. I have been doing that in my own ~/.octaverc for years. And bug #49323 was about the opposite undesirable behavior, that Octave's inputrc was overriding only portions of the user's preferred ~/.inputrc. Octave is now doing the correct thing, loadings its own default settings first, and then loading the user's preferred readline configuration.

We can leave this bug open to discuss where and how this should be documented better.

Mike Miller <mtmiller>
Project Administrator
Tue 18 Sep 2018 12:38:14 PM UTC, comment #9:

Well, after all this was easy with the help of
Dmitri and Mike. I had recently
changed my .inputrc file from empty to handle some
input differently.  My .inputrc was changed from empty to:

set keymap vi

Deleting that line fixed the problem. One
way to deal with this would be to test for an incompatible
.inputrc file. However, is it really a good idea to
allow the user's .inputrc file to replace Octave's?
At least some user's would prefer Octave's default while
in Octave, but use their own otherwise.

Also, the description in the Manual (pg.32) is not clear.
It states:  The default configuration file is
normally ~/.inputrc.

But, it does not describe what happens if .inputrc is empty.

An obvious choice would be another command line argument to
allow choice of use octaverc or use .inputrc. It seems to me
that the default should be to only use the Octave
configuration.  This would have avoided my problem...
And, it would mean that most users (those who do not explicitly
choose otherwise) would have the environment settings.

Now the only reason to keep this report open would be a discussion of any change to octaverc. At least the
consequences of running Octave with a non-empty
~/.inputrc should be documented.

Thanks again Dmitri and Mike

Michael Godfrey <godfrey>
Project Member
Tue 18 Sep 2018 11:09:39 AM UTC, comment #8:

Thanks for the information. Unfortunately, the version-rcfile
from current source and octaverc match. I will try to
isolate the problem caused by the octaverc. I have not
changed my startup configuration in a long time, but
there have been quite a few Fedora updates, ...

Michael Godfrey <godfrey>
Project Member
Tue 18 Sep 2018 12:34:38 AM UTC, comment #7:

That startup script is a copy of the file scripts/startup/version-rcfile in the Octave source tree.

If you do repeated builds and make installs, the file is not overwritten if it already exists. So there is a chance that you have an outdated file from a previous revision of the default branch. If that's the case you can delete the file and make install again to install the latest revision. However, that script has not changed since Octave 4.2.2.

If you know that the version startup script is to blame, can you determine exactly which command in the startup script is causing a problem? Among other things, the script loads your system or personal readline configuration, which may be related to this effect that you are seeing on the Octave command line.

Mike Miller <mtmiller>
Project Administrator
Tue 18 Sep 2018 12:05:17 AM UTC, comment #6:


The problem is in

I have not found how this file is generated, but it only
gets written to its location under some condition.
Its date is April 17. But, I did a make install on 26 Aug.

I am reluctant to do a make install right now due to
other work. But, noting the above a make install might not
update that copy of the octaverc anyhow.

Anyhow, this means that this is an Octave problem, not Fedora.

Michael Godfrey <godfrey>
Project Member
Mon 17 Sep 2018 10:10:01 PM UTC, comment #5:

Yes, I am running Fedora 28 with the latest updates.


cat ~/.octaverc
./run-octave -q
octave:1> w
error: 'w' undefined near line 1 column 1
octave:1> quit

./run-octave -q
octave:1> _octave_config_info_ ("hg_id")
ans = 4e108574385c
octave:2> quit

The same works with gui.


Dmitri A. Sergatskov <dasergatskov>
Mon 17 Sep 2018 09:47:19 PM UTC, comment #4:


I checked .octaverc same since dec. 2017,
and replacing it does nothing.

Are you running Fedora 28 with latest updates?

Michael Godfrey <godfrey>
Project Member
Mon 17 Sep 2018 06:11:27 PM UTC, comment #3:

I cannot reproduce it.

Please make sure your .octaverc does not contain any
non-printable chars.
(Delete it and re-create from scratch.)


Dmitri A. Sergatskov <dasergatskov>
Mon 17 Sep 2018 05:01:29 PM UTC, comment #2:


Good. The -qf fixes it!
My .octaverc contains:

But, it is the -q that causes the problem!!

Just -f works too.

Michael Godfrey <godfrey>
Project Member
Mon 17 Sep 2018 03:54:40 PM UTC, comment #1:

I cannot reproduce it (or perhaps I misunderstood what is the problem):

./run-octave -qf
octave:1> _octave_config_info_ ("hg_id")
ans = 4e108574385c


Dmitri A. Sergatskov <dasergatskov>
Mon 17 Sep 2018 02:59:19 PM UTC, original submission:

Since both the most recent build: 4e108574385c
and (as a possible cause the most recent Fedora 28 update)
when Octave is started in terminal mode only a few
characters are accepted, all others are rejected (and bell
rings). An accepted character is "c". After input of a string
of c's then CR, everything is normal. And, the same error
occurs in gui mode. I suspect that this is some quirk in
the latest Fedora updates, possibly related to Wayland stuff.
This is entirely a guess.

Has anyone else noticed this?

Michael Godfrey <godfrey>
Project Member


(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 dasergatskov (Posted a comment)
  • -email is unavailable- added by godfrey (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 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-12-14 rik5 Open/ClosedOpen => Closed
    2018-09-19 mtmiller Carbon-CopyRemoved 80942 => -
    2018-09-18 mtmiller CategoryInterpreter => Documentation
        Severity3 - Normal => 2 - Minor
        Priority5 - Normal => 3 - Low
        Item GroupRegression => Documentation
        StatusWorks For Me => Need Info
        SummaryOdd behavior on first input => Unexpected behavior on first input, due to ~/.inputrc
    2018-09-18 mtmiller StatusNone => Works For Me

    Back to the top

    Powered by Savane 3.4