Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Sometimes I misunderstand the syntax of a command:

# mysql -d test
mysql: unknown option '-d'
# echo $?

I try again and get it right:

# mysql --database test
Welcome to the MySQL monitor.
mysql >

How do I prevent the first command, with error code different than 0, to enter the history?

share|improve this question
up vote 13 down vote accepted

I don't think you really want that. My usual workflow goes like this:

  • Type a command
  • Run it
  • Notice it failing
  • Press UP key
  • Edit the command
  • Run it again

Now, if the failed command weren't saved into history I couldn't get it easily back to fix and run again.

share|improve this answer
+1 for getting the primary point of hihstory! – ams Jul 4 '12 at 21:11
I guess a better design would be a session history and a permanent history. Thanks! – Adam Matan Jul 5 '12 at 5:22
History get saved when you exit the terminal. So while you can go back to commands you've typed in this terminal session it actually gets saved to the bash history on exiting the terminal. – To Do Feb 7 at 21:32

The only way I can think of to do this would be to use history -d in $PROMPT_COMMAND. The problem with this or any approach is that it's impossible to tell if a command exited with an error or completed successfully with a non-zero exit code.

$ grep non_existent_string from_file_that_exists
$ echo $?
share|improve this answer

It's good to have last incorrect comment to correct it, but soon after that, it becomes potentially confusing garbage.

My approach is two-step: store commands that fail when they do, and remove them sometime later.

Store commands that fail when they do:

error_handler() {
    FAILED_COMMANDS="$(history | tail -1l | cut -c -5) $FAILED_COMMANDS"

trap error_handler ERR

trap command signals executes command when one of signals is "raised".

$(command), executes the command and captures its output.

When command fails, this snippet of code captures history number of last command saved into history, and stores it in variable for future deletion.

Simple, but works incorrectly with HISTCONTROL and HISTIGNORE – when command is not saved into history due to one of the variables, history number of last command saved into history is previous command's one; so, if incorrect command is not saved into history, previous command is going to be deleted.

Slightly more complicated version, which works correctly in that case:

debug_handler() {

error_handler() {
    local LAST_HISTORY_ENTRY=$(history | tail -1l)

    # if last command is in history (HISTCONTROL, HISTIGNORE)...
    if [ "$LAST_COMMAND" == "$(cut -d ' ' -f 2- <<< $LAST_HISTORY_ENTRY)" ]
        # ...prepend it's history number into FAILED_COMMANDS,
        # marking the command for deletion.

trap error_handler ERR
trap debug_handler DEBUG

Remove stored commands sometime later:

exit_handler() {
    for i in $(echo $FAILED_COMMANDS | tr ' ' '\n' | uniq)
        history -d $i

trap exit_handler EXIT


When exiting Bash, for each unique history number remove corresponding history entry,
then clear FAILED_COMMANDS to not remove commands which inherited history numbers from already deleted commands.

If you're sure that FAILED_COMMANDS will be free from duplicates, you can simple iterate over it
(ie. write for i in $FAILED_COMMANDS). If, however, you expect it to be not sorted from greatest to smallest (in this case it always is), replace uniq with sort -rnu.

History numbers in FAILED_COMMANDS must be unique and sorted from greatest to smallest, because when you delete entry, next commands' numbers are shifted – ie. when you issue history -d 2, 3rd entry becomes 2nd, 4th becomes 3rd, etc.

Because of that, when using this code, you cannot manually call history -d <n>
where n is smaller or equal to greatest number stored in FAILED_COMMANDS
and expect the code to work properly.

It's probably good idea to hook exit_handler at EXIT, but you can also call it anytime earlier.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.