bugGNU Octave - Bugs: bug #51289, Up arrow not showing Octave...

 
 

bug #51289: Up arrow not showing Octave history commands from an executable script

Submitter:  Francisco Vico <nightcod3r>
Submitted:  Wed 21 Jun 2017 09:58:46 PM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Wont Fix Assigned to:  None
Originator Name:  Nightcod3r Open/Closed:  * Closed
Release:  * 4.0.0 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 25 Jun 2017 03:29:21 PM UTC, comment #8: 

Thanks for the feedback. I'm going to close this as won't fix because I don't think we want user input prompts mixing with Octave history by default, and a few workarounds have been shown here.

Mike Miller <mtmiller>
Group Member
Sat 24 Jun 2017 06:48:05 AM UTC, comment #7: 

Mike, you cannot be more right. Indeed, that's the behavior Octave showed until version 3.6.4 and it was weird to me, but it perfectly fitted my needs, since I'm using it to build an Octave's command interpreter in Octave language, so sending the input to the history list was just what I needed.

I agree with you in that rlwrap (which I didn't know) should be the way to implement this, and the old functionality should stay deprecated.

Francisco Vico <nightcod3r>
Fri 23 Jun 2017 11:55:30 PM UTC, comment #6: 

As an example:


$ rlwrap -C myprogram octave --eval 'a = input ("enter something>> ", "s")'
enter something>> first
$ rlwrap -C myprogram octave --eval 'a = input ("enter something>> ", "s")'
enter something>> second


If you call Octave this way, you get your own custom readline wrapper around Octave, your own history file (~/.myprogram_history by default), you can configure your own command completions if you want, and so on. IMHO this is much better done outside of Octave, if I'm understanding correctly what you're trying to do.

Mike Miller <mtmiller>
Group Member
Fri 23 Jun 2017 11:51:01 PM UTC, comment #5: 

On the other hand, I don't want input to add the text that was read to the history list if I'm running Octave interactively.

This seems very wrong to me, but this is how it worked in Octave 3.6.4:


>> ls
>> pwd
>> ## Up and Down give me previous commands entered so far
>> text = input ("enter something>> ", "s")
enter something> ok
text = ok
>> ## now Up arrow gives me "ok" as if it were the previous command entered, that's not good


That was fixed in 3.8.0. I don't think we want that behavior back by default.

For your use case, do you intentionally want to intermix Octave command history and the history of what was entered into your custom input prompt?

If not, could you consider using rlwrap instead, which is an external program that can wrap any program that gets input and automatically adds full readline support, including history and command editing?

Mike Miller <mtmiller>
Group Member
Thu 22 Jun 2017 01:16:00 AM UTC, comment #4: 

Correction: Up- and Down-arrows behave correctly after adding --line-editing option. As for input adding the strings to the history file, this does not replicate older versions behavior. But it can be sorted out by using an alternative history file, writing the strings in it, and reading (history -f file) into the history list.

(John, thanks so much for your help, and for creating this wonderful tool, which is the best option for coding learners and which we'll implement in thousands of schools in Andalusia along the next course.)

Francisco Vico <nightcod3r>
Wed 21 Jun 2017 11:48:04 PM UTC, comment #3: 

Launching the script with --line-editing, Ctrl-p and Ctrl-n do fetch the previous and next command in the ~/.octave_hist file, same behavior as pressing up- and down-arrow. If I recall well, the words fed at the input were also fetched, I mean, for older versions, this script:

#!/usr/bin/octave --line-editing

a = input(">> ", "s");
a = input(">> ", "s");

would allow to fetch the word fed in the first input command during the second input command, meaning that the word that was input first was somehow stored in the history. This doesn't happen in 4.0.0 version.

Francisco Vico <nightcod3r>
Wed 21 Jun 2017 10:30:14 PM UTC, comment #2: 

I've run the scrip with that option (--line-editing, without -q), in that case the ^[[A characters don't show up, but nothing happens, the prompt stays the same (empty).

Francisco Vico <nightcod3r>
Wed 21 Jun 2017 10:22:44 PM UTC, comment #1: 

Thanks for the report.

At some point, command-line editing was disabled when Octave is reading input from a file.

You can force command-line editing to be enabled using --line-editing, but unfortunately, there is no corresponding short option for that, and I think most systems won't allow a #! line with -q --line-editing.

Instead of changing the default to have line editing enabled when Octave is reading from scripts, I guess a better solution would be to enable line editing just for functions that get user input, even when the main interpreter loop is reading from a file.

I'll see if that's easy to do.

John W. Eaton <jwe>
Group administrator
Wed 21 Jun 2017 09:58:46 PM UTC, original submission:  

(Not sure if this can be considered a bug, or just a change in the functionality from older versions, but just in case.)

Pressing up-arrow will show past commands. But executing this script:

#!/usr/bin/octave -q

a = input(">> ", "s");

it will prompt for an input, but when pressing up-arrow it will show ^[[A. This is for version 4.0.0, but in older versions, like 3.2.4, up-arrow would work fine in the executable script, showing the commands in the history file, just as the original prompt in the GNU Octave command window. I've checked and both runs (command window and script) are updating the same history file, so may be the thing is in the way input is taken. I believe it's a readline thing, but can't figure out how to make it work.

Francisco Vico <nightcod3r>

 

(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 mtmiller (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by nightcod3r (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 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-06-25 mtmiller StatusNone Wont Fix
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code