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.
|
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.
|
Fri 23 Jun 2017 11:55:30 PM UTC, comment #6:
As an example:
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.
|
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:
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?
|
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.)
|
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.
|
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).
|
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.
|
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.
|