0

When I'm pressing upper arrow to browse history for some reason the terminal saves either bad out put and good output (commands and junk).

for example when I'm typing the following junk it remember the junk in the terminal history.

the pressed command:
the pressed command

output:
output

when pressing up arrow:
when pressing  up arrow

12
  • 3
    unix.stackexchange.com/questions/41739/…
    – Ravexina
    Mar 30, 2018 at 22:47
  • 5
    That's the default behaviour.
    – pomsky
    Mar 30, 2018 at 22:49
  • 4
    Just to be clear, your question doesn't sound right, no outputs are stored in bash history. It only stores the commands you have run, the onus is on you to put the correct command. Also you can always clear history or delete individual items from it.
    – pomsky
    Mar 30, 2018 at 22:58
  • 1
    @Asaf "When using terminal usualy only commands that successfully ran was saved to the bash history..." [citation needed]
    – pomsky
    Mar 30, 2018 at 23:05
  • 1
    I reckon most probably false memory or you didn't notice carefully. Let's see if someone else can shed some light on the matter.
    – pomsky
    Mar 30, 2018 at 23:21

1 Answer 1

3

What you have described seeing now is the default behavior in Bash and most, if not all, other shells. I rely on this behavior daily, with Bash and other shells, on multiple machines running Ubuntu and other OSes. I have never had to make any configuration changes to achieve it. I can assure you that the default behavior of Bash is not to omit recording commands in the history just because they failed.

So I sympathize if you don't find this answer very helpful. But I'll try to describe and explain the general situation, as well as why that behavior is the default and why you probably don't really want--and likely did not previously have--the exact behavior you seem to be asking for.

In a comment, you clarified:

When using terminal usualy only commands that successfully ran was saved to the bash history, now any junk input is stored

It's hard to know precisely what the previous behavior was that you had set up, but if you somehow managed to configure Bash to do that, then you would probably have been very unhappy with that. This would not achieve what you are probably thinking that it would achieve. So unless you were quite dissatisfied with the way Bash used to work, it most likely was not doing quite what you have described.

First of all, many commands run in the intended way but return with an exit code representing failure under some situations. Every exit code except 0 is considered to indicate failure. For example:

  • The find command returns an exit code of 1 when the tests you give it do not find any files. find mainly does this so that it is easy to use in scripts, but it does it even when you run it interactively. If commands that failed were suppressed, then you would mysteriously lose commands that, from your perspective (and that of any other user in your position), had actually succeeded.
  • The ls command returns an exit code of 2 if any of the filenames you pass it do not exist, even if you passed one or more other filenames that did exist and whose information it successfully showed you.

Similarly, a command may succeed, i.e., terminate normally and return an exit code of 0, but still not actually do what you had meant for it to do.

Second of all, when a command fails, that does not usually mean you want it to be harder for you to know about what happened. When things go wrong, most people want to be able to easily find out what was done that failed. In particular, Rene Saarsoo has pointed out (as cited by Ravexina) that it is common to make a mistake in entering a command, then press the up arrow so you can edit and retry the command. If commands that failed could not be accessed in your shell's history, you would not be able to do that.

There are some alternatives presented in other answers to that question, which might interest you, though most users will probably not want Bash to do anything like what is described in any of them. For example, wrong commands far back in your history are potentially confusing, but also potentially illuminating, so I doubt most people would want that setup.

From the examples in your question, it appears that you specifically are concerned about how the most recent command you ran is always stored in your history. But as pomsky has said, that is the default behavior. By default, the only situation where a command is not stored in the history at all is if it begins with one or more spaces (which is a way of preventing individual commands from being recorded, provided that you know when you write them initially that you do not want them to appear).

I suppose it is possible that you were previously affected by a strange bug that happened to produce the specific behavior you actually wanted. If you can describe the behavior you want in more detail, then someone might be able to provide instructions on how to achieve it. For example, perhaps you only want commands omitted from the history if the command name--that is, the first word of the command--is not found. (In Bash, this produces an exit status of 127; programs can also return that as their exit code, but fortunately most don't.)

But the answer to your question, as you have asked it, is that the current behavior you are observing is the default behavior, and is considered correct.

1
  • "I suppose it is possible that you were previously affected by a strange bug..." or simply false memory, happens all the time!
    – pomsky
    Apr 1, 2018 at 13:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .