Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

History numbers are set to large number if fc is called in particular way. #744

Open
kaesluder opened this issue Apr 16, 2024 · 3 comments

Comments

@kaesluder
Copy link

kaesluder commented Apr 16, 2024

I've been experimenting with implementing fzf history search, and found the following error if fc is called with an invalid argument. I've put in as close as I can get to a minimal example below. Calling fc with the output of $(history $HISTSIZE | fzf | cut -f1) renumbers history relative to a very large number. History resets if ksh is exited, sometimes clearing the history file, although I've not been able to reliably trigger tha.

Getting fzf running for this case is entirely optional. I'm more concerned about potential history and/or memory corruption.

20 ~ $ fc $(history $HISTSIZE | fzf | cut -f1)
ksh: hist: 50000-20: invalid range

...

1454470982 ~ $ echo $PS1
! ${RELATIVE_PWD}$(getBranch) $ $(__zoxide_hook)
1454470983 ~ $ history
1454470968      source ~/fzfc.ksh
1454470969      source ~/fzfc.ksh
1454470970      ls
1454470971      history 500
1454470972      exit
1454470973      history

Oops, forgot version sh (AT&T Research) 93u+m/1.0.8 2024-01-01

@hlangeveld
Copy link

I thought ksh93 updated history files real time. The problem starts when you have multiple sessions open, for which I used a hack to incorporate the name of my current tty into the history file (which I would keep in a ~/.hist directory). Tricky bit was that ksh93 would require a restart to change the history file on startup.

What is the value of the HISTFILE you use? And do you have any other shells using that same file? Do they save in real time or on exit?

@kaesluder
Copy link
Author

History file is set to $HOME/.kshrc_history

Aaaaand, now I can't reproduce the problem, although I did earlier today for u+m and u. I seem to remember having the same weirdness using ksh2020.

I tested it originally with only one ksh running. I'm running two interactive shells now and it looks like they're sharing history (and the line number on the prompt) with no issues. But as I said, I can't seem to break it following the same steps now.

@kaesluder
Copy link
Author

I have not seen this happen since updating on OpenSUSE. Ticket can be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants