49

More than once I've accidentally run a number of commands and polluted my bash history. How do I close my terminal without saving my bash history? I'm using Fedora.

Improve this question
0

7 Answers 7

Reset to default
51

There's more than a few ways to accomplish this.

One thing you should understand is that Bash and most shells keep an in-memory history and only writes it to the history file when the shell exits normally, or when you call history -a inside the shell. Obviously, some of the following solutions won't help you if your PROMPT_COMMAND contains the history -a command, like mine does.

Note: These options are not mutually exclusive; they can be used in any combination, or all at once.

Option 0

Delete the HISTFILE shell variable.

# (On your command line now)
unset HISTFILE

According to the man page, this will remove the shell's ability to automatically write any history to a file, regardless of if you set HISTFILE to something after unsetting it.

This causes history -a/history -n invocations to become a no-op.

Option 1

If you're a perfectionist when it comes to cluttering up your history file, then what you can do is modify the HISTIGNORE variable to include globs of commands you don't want recorded. For instance, if you add HISTIGNORE='ls*:cd*' to your ~/.bashrc then any instance of ls and cd aren't inserted into your history file:

# (Somewhere in ~/.bashrc)
# Ignore all "git status" and "ls" invocations.
# When called with an argument, these still pass into the history.
HISTIGNORE='git status:ls'
# As with any Bash variable, append using "+=" to add more patterns later:
HISTIGNORE+=':another-program *'

This variable respects extglob when turned on:

shopt -s extglob
# With `extglob` on I can use extended globs to ignore all:
# cd ..
# cd ../
# cd ..//
# cd ../..
# cd ../../
# cd ../..//
# etc.
HISTIGNORE='cd +(..|../)*(/)'

This will ignore cd .., cd ../, cd ../.., etc but leave cd myfolder.

More information on extended globs can be found in the bash man page.

Option 2

If you want to control on a command-by-command basis what commands get left out of your history, you can set HISTCONTROL='ignorespace' which will omit any command lines starting with a space. Using ignoreboth will also omit repeated lines. Then, hitting the space bar before you enter a command will cause it to not show up in your history file.

# (Somewhere in ~/.bashrc)
HISTCONTROL=ignoreboth

Then...

# (On your command line now)
# With HISTCONTROL=ignorespace (or =ignoreboth) this line gets appended to history:
$ mycommand
# But this line does not:
$  mycommand

Option 3

If you just want to make it so when you close the terminal the shell exits immediately, you can trap the signal the terminal program sends the shell (xterm, for instance sends SIGHUP then waits for the shell to exit) and make exit without saving the history when it receives this signal. Add this to your ~/.bashrc:

# (Somewhere in ~/.bashrc)
# Don't record history to $HISTFILE when the window is closed
trap 'unset HISTFILE; exit' SIGHUP

Option 4

While some may consider this the "barbarian" approach, sending SIGKILL to your shell's PID will kill your shell right away without the shell being able to do anything such as trap the signal, save history, execute ~/.bash_logout, warn about stopped jobs, or any of that good stuff.

($$ expands to the PID of the shell process executing the command)

# (On your command line now)
kill -9 $$
Improve this answer
6
  • 4
    +1 for the 'kill -9 $$' method. That's certainly one way around situations where HISTIGNORE, etc are set as read-only. Commented Nov 21, 2011 at 5:28
  • 9
    I don't think it's a good idea to promote using kill -9 for anything except dire situations when everything else has failed. Commented Nov 21, 2011 at 16:51
  • 2
    Sending SIGKILL never a good idea as a standard operating procedure. Use the proper procedures, like unsetting HISTFILE. Commented Nov 21, 2011 at 23:26
  • @Arcege TMTOWTDI. Commented Nov 22, 2011 at 3:16
  • 3
    kill -9 $$ is ideal to execute if you accidentally entered your password in the shell and hit enter (expecting a password prompt instead). Commented Feb 14, 2021 at 8:20
38

Your shell's history is saved in the file indicated by the HISTFILE variable. So:

unset HISTFILE

This also applies to zsh, but not to ksh which keeps saving to the file indicated by $HISTFILE when the shell starts (and conversely, you decide to save your history in ksh once you've started the shell).

Improve this answer
2
  • I can use this before i log out after i polluted the history? and its ust for this session? i dont need to set HISTFILE next time i log in? (just say if this is correct or incorrect) Commented Nov 21, 2011 at 0:51
  • @acidzombie24 That is correct, changes to environment variables are not saved across sessions unless you store the changes explicitly, e.g. in rc files. Commented Nov 21, 2011 at 1:44
4

I'm surprised to see no one has suggested history -c immediately prior to exit. IINM (I'm no expert) that will do nicely.

Improve this answer
3
  • 5
    You're on the right track: history -r will re-read the history file, so saving becomes a no-op. Commented Nov 21, 2011 at 9:47
  • 2
    Flushing the history is a bad habit... shell history contains a lot of useful information about who did what. it's very useful for people who are new on your platforms (unless you are 100% confident about you documentation, change management) Commented Sep 14, 2015 at 13:53
  • This, if won't fail, will save the current shell partial history to the file, including commands you may have wanted to omit, i.e. those that you ran in the current shell. Commented Jun 26, 2024 at 10:17
2

There are two environment variables that bash uses to determine the history file and how many lines to write to it when the shell exits.

You can throw away your session's history with either of these (set during the session you want to omit from your history file):

HISTFILE=/dev/null

or

HISTSIZE=0

Either of these work fine in Bash on Fedora

Improve this answer
1

Not sure why you care about your command history so much. If you need certain commands often, you might have more fun if you define aliases for them so you can get them back with two keystrokes rather than having to look for them in the history.

Improve this answer
0

  1. Eli already gave you the correct answer for Bash which is to set HISTSIZE=0.

  2. I would just add the method to do it for GNU screen. Press Ctrl+A (screen escape sequence) followed by :scrollback 0. This will delete scroll-back history. Now you can immediately do :scrollback 15000 to reset scroll-back buffer size.

Improve this answer
4
  • When did the OP say they were using screen(1)? Commented Nov 21, 2011 at 2:47
  • He didn't. But, you could be running Bash inside a screen session and HISTSIZE=0 will still leave your activity details in screen's scroll-back buffer. So, if you really want it clean, you have to do scrollback=0 as well. Commented Nov 21, 2011 at 3:37
  • The scrollback buffer is cleared when the window closes (i.e. when the shell exits). What about if you typed Ctrl-a H? Will it kill the logfile? Commented Nov 21, 2011 at 7:23
  • @amphetamachine: nope, it will only begin/end logging of current window. Neighther Ctrl+a H nor Ctrl+a :clear will remove history. You need Ctrl+a :scrollback 0. You can test it yourself. Start a fresh screen session. Now do a cat /etc/passwd. Now, do any of the above - Ctrl+a H or Ctrl+a :clear. Now, try copying from screen buffer by donig a Ctrl+a [ followed by up-arrow to go up and see how far you can go to copy. If you have done a Ctrl+a :scrollback followed by a clear, you would only go as far as you can see in current window since there wont be any scrollback buffer. Commented Nov 21, 2011 at 12:15
0

Here is a safe/natural alternative which should work if you are connected to a unix server via an SSH/telnet client such as PuTTY, which is something that I don't like when it happens, but when you want it to happen, then just let the connection on without interacting with the window until it gets lost when the timeout limit hits, or you can also go ahead and disconnect from internet and try to type something until it disconnects similarly due to network error. This way your commands from that session get lost because you don't properly exit when it would normally save them to history. I don't know if this approach can be applied somehow for a computer that is running unix itself.

Improve this answer

You must log in to answer this question.