You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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?
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.
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.
Oops, forgot
version sh (AT&T Research) 93u+m/1.0.8 2024-01-01
The text was updated successfully, but these errors were encountered: