Bug in command history viewer
Jason Quinn wrote on Jan 12, 2011
One can browse through previous commands using the up and down arrow keys.
There is a bug however where if one scrolls back 2 or more commands, you cannot get back to the current command line. The "farthest back down" you can get is the previous command.
This seriously hinders the usefulness of the history mechanism. In progress lines are lost because of it. Frequently one scrolls back on an empty line to view some commands but then wish to return back to the empty line... instead you have to delete unwanted stuff from the previous command to get your empty line back.
Simple test case:
1) Start new IRAF ecl
2) Execute a "dir" command.
3) Execute a "time" command.
4) You a now waiting at an empty prompt.
5) If you scroll back two commands, you cannot return to your empty prompt. (If you only scroll back one command, you can successfully return to the empty current.)
The bug actually gets more complicated when multiline commands are in the history. It's hard to put into words and I haven't isolated the exact behavior but "pieces" of the multiline command tend to show up as the "furtherest down in history" command, even when the multiline command was several commands ago.
This was tested with 2.15. I'll try it on 2.14 went I get a chance but I think the behavior is the same there.
I never stopped to think about it but I always felt there was something strange about the command history behavior. This is it. The frequency of using only the previous command kind of hides the problem since it only shows up if you scroll back two or more. There's also something strange with how multi-line commands are treated in the history mechanism but I have yet to explicitly notice what it is.
Jason
There is a bug however where if one scrolls back 2 or more commands, you cannot get back to the current command line. The "farthest back down" you can get is the previous command.
This seriously hinders the usefulness of the history mechanism. In progress lines are lost because of it. Frequently one scrolls back on an empty line to view some commands but then wish to return back to the empty line... instead you have to delete unwanted stuff from the previous command to get your empty line back.
Simple test case:
1) Start new IRAF ecl
2) Execute a "dir" command.
3) Execute a "time" command.
4) You a now waiting at an empty prompt.
5) If you scroll back two commands, you cannot return to your empty prompt. (If you only scroll back one command, you can successfully return to the empty current.)
The bug actually gets more complicated when multiline commands are in the history. It's hard to put into words and I haven't isolated the exact behavior but "pieces" of the multiline command tend to show up as the "furtherest down in history" command, even when the multiline command was several commands ago.
This was tested with 2.15. I'll try it on 2.14 went I get a chance but I think the behavior is the same there.
I never stopped to think about it but I always felt there was something strange about the command history behavior. This is it. The frequency of using only the previous command kind of hides the problem since it only shows up if you scroll back two or more. There's also something strange with how multi-line commands are treated in the history mechanism but I have yet to explicitly notice what it is.
Jason
Mike Fitzpatrick wrote on Jan 12, 2011
Hi Jason,
I'll see if I can get it fixed for the next release, this has been around since the first release of the ECL.
-Mike
I'll see if I can get it fixed for the next release, this has been around since the first release of the ECL.
-Mike
Jason Quinn wrote on Jan 12, 2011
fitz
Hi Jason,
I'll see if I can get it fixed for the next release, this has been around since the first release of the ECL.
-Mike
That would be awesome if you get the chance.
An amendment to my previous post, the behavior is not as simple as the rules I mentioned above imply. The incorrect command that shows up at the bottom of the command stack depends on the number of times that the user scrolled up and down. It changes, even if not new commands were actually executed.
Jason
Mike Fitzpatrick wrote on Jan 12, 2011
Hi Jason,
I had a look but it's more complicated than I have time for right now. The history arrows are managed in the readline() procedure itself so there's a lot of stuff that needs to be built on top of that to get the behavior you're familiar with from tcsh/bash shells.
In any case, a simple Ctrl-U will always erase the line back to the prompt wherever you are in the history list.
-Mike
I had a look but it's more complicated than I have time for right now. The history arrows are managed in the readline() procedure itself so there's a lot of stuff that needs to be built on top of that to get the behavior you're familiar with from tcsh/bash shells.
In any case, a simple Ctrl-U will always erase the line back to the prompt wherever you are in the history list.
-Mike
Jason Quinn wrote on Jan 12, 2011
fitz
Hi Jason,
I had a look but it's more complicated than I have time for right now. The history arrows are managed in the readline() procedure itself so there's a lot of stuff that needs to be built on top of that to get the behavior you're familiar with from tcsh/bash shells.
In any case, a simple Ctrl-U will always erase the line back to the prompt wherever you are in the history list.
-Mike
Okay.
Is the readline you mention GNU readline library stuff or some IRAF internal routine?
If I can manage to find a night were I don't have yet another date with a supermodel, I may look at the code for giggles. I've have never glanced at the CL internals so I don't know if I'll be able to understand the code but it might be fun to me on some level.
Cheers,
Jason
Mike Fitzpatrick wrote on Jan 12, 2011
Yeah, it's all the magic in the GNU readline() and add_history() procedures called from ecl$history.c Here's hoping your social life hits a dry spell 8-)
Cheers,
-Mike
Cheers,
-Mike
Last post on Jan 12, 2011