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

[develop7]

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]

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

[zanchey]

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]

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

[zanchey]

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

[ridiculousfish]

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]

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

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]

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]

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]

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

[pickfire]

What is the progress on this?

[alphapapa]

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]

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]

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

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]

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]

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

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

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

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

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

[faho]

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

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]

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

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]

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.

[vifon]

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.

[will]

Thank you @ridiculousfish!!!

[ridiculousfish]

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]

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