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

"Up" key should recall previously entered command instead of previous command from history #1383

Closed
develop7 opened this issue Mar 29, 2014 · 30 comments

Comments

@develop7
Copy link
Contributor

develop7 commented Mar 29, 2014

Repro:

  1. execute echo foo
  2. execute <Space>echo bar (prepend command with a space ( ) to prevent storing it in history)
  3. press key

Expected: <Space>echo bar is recalled

What happens instead: echo foo is recalled

This 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.

@develop7
Copy link
Contributor Author

Is something wrong with this issue? if so, where should I start to make it look better? Thanks.

@lilyball lilyball added this to the fish-future milestone Sep 22, 2014
@zanchey
Copy link
Member

zanchey commented Oct 6, 2014

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.

@ridiculousfish
Copy link
Member

I don't think fish ignores commands that exit with non-zero status?

@zanchey
Copy link
Member

zanchey commented Oct 6, 2014

No, it doesn't - apologies. That is issue #5. It only ignores nonexistent commands.

@ridiculousfish
Copy link
Member

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.

@develop7
Copy link
Contributor Author

@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)?

bash and zsh behave in the way that the originator describes

not sure of bash, but zsh does indeed

@zanchey
Copy link
Member

zanchey commented Oct 26, 2014

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.

@develop7
Copy link
Contributor Author

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?

@ridiculousfish
Copy link
Member

zsh says:

Note that the command lingers in the internal history until the next command is entered before it vanishes, allowing you to briefly reuse or edit the line. If you want to make it vanish right away without entering another command, type a space and press return.

So there's at most one volatile entry in zsh. That's an interesting compromise. What do you think?

@develop7
Copy link
Contributor Author

@ridiculousfish I'm perfectly ok with just one entry. Sorry for not being clear enough, I was sure I was.

@develop7 develop7 changed the title "Up" key should recall previous command instead of previous command from history "Up" key should recall previously entered command instead of previous command from history May 22, 2015
@pickfire
Copy link
Contributor

What is the progress on this?

@alphapapa
Copy link

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.

@develop7
Copy link
Contributor Author

If this change were made, I would have to kill the fish process, or the command would remain in that shell's history.

@alphapapa the whole point of this feature the space-prefixed command won't hit history file and will be overwritten by next command

@alphapapa
Copy link

@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.

@develop7
Copy link
Contributor Author

develop7 commented Feb 12, 2016

I don't want it to be recorded, period--neither on-disk nor in-memory

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).

@krader1961
Copy link
Contributor

when I prefix a command with a space, I don't want it to be recorded, period--neither on-disk nor in-memory.

@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.

@alphapapa
Copy link

@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. :(

Seriously, your proposal is off current issues' topic (and IMHO is more like security theater).

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: hrm takes an argument, and deletes any shell history entries matching the arguments. hrmrm removes any rm commands from the shell history. This makes it easy to clean the history of commands that delete files so they are not accidentally re-executed in the future. You could use some commands like this, and maybe an hrl command for "history-remove-last" to remove the last command from the history. That way, you could leave these entries in the history, and then easily remove them when you're done.

@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.

@krader1961
Copy link
Contributor

@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 cd. Did you even read what the other people in this thread wrote?

@krader1961
Copy link
Contributor

@develop7: You asked back on 2015-03-20:

... would be accepted a pull request implementing this feature?

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.

@develop7
Copy link
Contributor Author

@alphapapa

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. :(

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.

This makes it easy to clean the history of commands that delete files so they are not accidentally re-executed in the future.

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.

@develop7
Copy link
Contributor Author

@zanchey @ridiculousfish Any suggestions where could I start hacking?

@faho
Copy link
Member

faho commented Nov 26, 2018

@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").

@j-f1
Copy link

j-f1 commented Nov 26, 2018

Just to add some info here, I typically use (cat) to i our sensitive data into a command. You can use it like this: foo --token=(cat) enter token goes here enter ^D

@develop7
Copy link
Contributor Author

@j-f1 whoa, that's smart! Following this further, I've tried to replace cat with read, which wasn't so successful since read cannot mask input completely and it requires a variable to put input to.

@faho
Copy link
Member

faho commented Dec 12, 2018

read [...] requires a variable to put input to.

#4407 and #4490. Included in the freshly released 3.0 beta. Grab your packages while they're still hot!

@floam
Copy link
Member

floam commented Dec 12, 2018

read shouldn't need a variable, and --silent can do the silent thing. set fish_history to '' to prevent read from storing history.

$ 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.

@domdom domdom mentioned this issue Sep 27, 2019
3 tasks
@vifon
Copy link
Contributor

vifon commented Sep 29, 2020

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.

ridiculousfish added a commit to ridiculousfish/fish-shell that referenced this issue Jan 3, 2021
@will
Copy link

will commented Jan 3, 2021

Thank you @ridiculousfish!!!

@ridiculousfish
Copy link
Member

With 9fdc4f9 we try to match zsh's HIST_IGNORE_SPACE feature. A command with a leading space can be recalled immediately by pressing up arrow; it is cleared from history when you run a new command, or type space and hit return. It's never written to disk.

@Korkman
Copy link

Korkman commented Mar 27, 2021

@develop7 @alphapapa

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.

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.

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

No branches or pull requests