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
"Up" key should recall previously entered command instead of previous command from history #1383
Comments
Is something wrong with this issue? if so, where should I start to make it look better? Thanks. |
Reframed, this is a request for both universal and global history, where only universal history is saved to disk or visible to other shells. I am not sure that it is a good idea. Fish already ignores commands that exit with a non-zero status when saving them to the history, which helps to avoid polluting it with error-prone entries. |
I don't think fish ignores commands that exit with non-zero status? |
No, it doesn't - apologies. That is issue #5. It only ignores nonexistent commands. |
It looks like bash and zsh behave in the way that the originator describes. It doesn't make a whole lot of sense to me either though. |
@ridiculousfish @zanchey looks like you're ok with polluting shell history with volatile entries in order to enable user to reuse previous command (that's a use case for this feature too)?
not sure of bash, but zsh does indeed |
It might be worth having a read of some of the discussion in #940, where I think we have covered some of the ideas behind this request. |
I've added another possible use case to issue description. Also since core team is not sure if they want to see this implemented, I've got a question: would be accepted a pull request implementing this feature? |
zsh says:
So there's at most one volatile entry in zsh. That's an interesting compromise. What do you think? |
@ridiculousfish I'm perfectly ok with just one entry. Sorry for not being clear enough, I was sure I was. |
What is the progress on this? |
I'm not sure this is a good idea. When I prefix a command with a space, it's because I do not want the command recorded. If this change were made, I would have to kill the fish process, or the command would remain in that shell's history. At the least, this feature should be optional, and off by default. |
@alphapapa the whole point of this feature the space-prefixed command won't hit history file and will be overwritten by next command |
@develop7 The point I'm making is that, when I prefix a command with a space, I don't want it to be recorded, period--neither on-disk nor in-memory. If this change were made, the command would remain in the in-memory history list until another command is run or the shell is killed. This is not only a potential privacy and security issue, but a potential data-loss issue as well. A common reason to prefix commands with a space and prevent them from being recorded is to prevent potentially dangerous commands from being accidentally run a second time from the command history. I'm sorry, but this is not a good idea. |
I see. Did you disable echoing typed symbols too? I mean you had to, because otherwise they'll stay in memory of your terminal emulator (scrollback buffer) regardless whether command begins with space. And oh, there's video memory which might be not cleared properly. And not having previous command in history doesn't mean it is not somewhere in process' memory. Seriously, your proposal is off current issue's topic (and IMHO is more like security theater). |
@alphapapa: Your expectations are unreasonable and borderline impossible. How exactly do you expect your command to be executed if it can't be stored in memory and passed to the kernel? However, I suspect that you really don't expect the command to not be stored in memory. I'm guessing your real concern is that someone who has access to your terminal could press up-arrow and retrieve the most recent volatile command. But as @develop7 points out that doesn't keep the person from leveraging your terminal scroll back history. Plus, if you're stepping away from your computer and you're that security conscious you damn well better be locking the screen. I vote for implementing the zsh behavior. It makes volatile commands easier to rerun (no need to scroll-back and cut-and-paste). It also allows people like @alphapapa to wipe the volatile command buffer by pressing space+enter. |
@develop7 When I said I don't want it to be recorded in memory, I didn't mean that the bytes are literally not resident somewhere in RAM. I meant that I don't want it to be recorded in the shell's in-memory history list. There's no need to be pedantic and rude. :(
My comment isn't off-topic, and my "proposal" is the status quo, i.e. how Fish currently works, how Bash works, etc. Maybe you misunderstood me. I recommend leaving the current behavior alone. Instead, you could emulate this behavior in a more flexible way by having commands to remove certain entries from the shell history. For example, in Bash I have two commands: @krader1961 Obviously it's not primarily a security or privacy feature. The biggest benefit is protecting against accidentally re-executing dangerous commands. I often do this when I delete a file or directory which shares a name with other files or directories in other places in the filesystem. By not recording it in the shell history, I protect against unintentionally deleting other files. |
@alphapapa: The onus is on you to clearly communicate your concern. You failed to do so. Telling me I was rude for pointing out your proposal, as you stated it, is nonsensical only serves to make me inclined to dismiss anything you have to say. Especially since you appear to be unwilling to invest the effort to clearly communicate your position. I'm still not convinced by your argument for leaving the implementation as is. The most recent command, whether volatile or not, should be retrievable so it can be edited and rerun. With the proposed change your "dangerous" command would not be retrievable as soon as you type another command -- including |
@develop7: You asked back on 2015-03-20:
Yes, if it implements behavior equivalent to zsh. That is, the most recent volatile command is retrievable only as long as no other command has been entered. Also, if a single space is entered that removes the volatile command from being retrievable (but just pressing [enter] does not). Don't forget to update the documentation and add unit tests. |
Well we do want it and want it for Reasons :( And yeah, being snarky wasn't really necessary (yet I couldn't really help it at the moment), sorry for that.
If you've accidentally hit "Up" & "Enter" right away after deleting some files, the command will most certainly fail, which means no harm done, right? Unless these files were recreated somehow, which also means no harm done. |
@zanchey @ridiculousfish Any suggestions where could I start hacking? |
@develop7: The obvious part is where commands starting with a space are currently dropped entirely. In https://github.com/fish-shell/fish-shell/blob/master/src/reader.cpp#L2889-L2894. I'd probably move the space check into history.cpp, and instead of dropping it I'd move it to a special "volatile" entry that I'd clear if anything else is added. That volatile entry is then checked first on history search (also mostly in reader.cpp, look for "history_search" or "HISTORY_SEARCH"). |
Just to add some info here, I typically use |
@j-f1 whoa, that's smart! Following this further, I've tried to replace |
$ echo secretly got (set -l fish_history ''; read -s) from user
read> ●●●
secretly got asd from user It's a lot to type - might want to make an abbr. |
What is the progress on this feature? Are there any plans to implement it? I believe this is the feature I miss the most from zsh. |
Thank you @ridiculousfish!!! |
With 9fdc4f9 we try to match zsh's |
Sorry for the late reply to this, but the dangerous commands I tend to space-prefix are the likes of mkfs.ext4. My shells can stay open for years in tmux. So yeah, full filesystem loss when accidentally re-executed, with plenty of live data. It is a valid point that removing this "safety-latch" feature may come unexpected to some users, including me, and the remedy of executing a sole space afterwards is something that has to be actively learned. Then again, it is a handy feature to be able to edit the last line - private or not. It's a feature I didn't know I missed! I see both points. I solve this for myself by adding an echoed hint on fish_postexec whenever a space-prefixed command is executed so I can't forget to clear it. |
Repro:
echo foo
<Space>echo bar
(prepend command with a space (Expected:
<Space>echo bar
is recalledWhat happens instead:
echo foo
is recalledThis behavior is very convenient if a user wants to try various approaches to run command but doesn't want to flood history with non-working entries and/or entries containing private data.
The text was updated successfully, but these errors were encountered: