Live data from Hacker News

Understanding Bash History

symkat.com

11–20 of 28 posts

Re: Understanding Bash History

#11

Heh. This is funny timing, as .bash_history made me feel like an idiot just yesterday morning. I was sitting here between queries and I thought 'y'know, all I ever do with history is grep for things. I wonder what else I can do?' When I want to learn about something quick, I usually start with the built-in help; so I did history --help The built-in help for history, unfortunately, is woefully inadequate; this was the…

The built-in help for history, unfortunately, is woefully inadequate; this was the output:

i always wondered whether linux had such terrible man pages because nobody read them, or whether nobody read them because they were so terrible.

Re: Understanding Bash History

#12
post #9

I used Linux for years without knowing about the bash history file (though I knew about hitting the up arrow). As soon as I discovered this file, I looked up how to set it to save all my history forever without rollover - what a good resource it would be to have all the commands I've ever used! Anyone know of a utility for saving annotations about the bash history lines? (Date, comments, current directory, etc.?)

http://stackoverflow.com/questions/945288/saving-current-dir...

Re: Understanding Bash History

#13

Heh. This is funny timing, as .bash_history made me feel like an idiot just yesterday morning. I was sitting here between queries and I thought 'y'know, all I ever do with history is grep for things. I wonder what else I can do?' When I want to learn about something quick, I usually start with the built-in help; so I did history --help The built-in help for history, unfortunately, is woefully inadequate; this was the…

A heart surgeon once told me, surgery is not about how good you are at staying out of trouble, but how good you are at getting out of trouble. Eg, shit happens, the survivors are the ones who can deal with it.

*nix hacking ~ heart surgery? Who knew.

Re: Understanding Bash History

#14
I like mapping page up and page down to history-search-backward and history-search-forward in /etc/inputrc or ~/.inputrc. It works much like the bang commands. Ubuntu and Debian have the appropriate lines commented out; other distros might enable such a mapping by default (Mandriva did when I used it last).

  "\e[5~":        history-search-backward
  "\e[6~":        history-search-forward
Some other useful entries:

  # ctrl-left, ctrl-right
  "\e[1;5C":forward-word
  "\e[1;5D":backward-word
  "\e[5C":forward-word
  "\e[5D":backward-word
  "\e\e[C":forward-word
  "\e\e[D":backward-word

Re: Understanding Bash History

#15
post #11

Heh. This is funny timing, as .bash_history made me feel like an idiot just yesterday morning. I was sitting here between queries and I thought 'y'know, all I ever do with history is grep for things. I wonder what else I can do?' When I want to learn about something quick, I usually start with the built-in help; so I did history --help The built-in help for history, unfortunately, is woefully inadequate; this was the…

The built-in help for history, unfortunately, is woefully inadequate; this was the output: i always wondered whether linux had such terrible man pages because nobody read them, or whether nobody read them because they were so terrible.

Well, since 'history' is a shell builtin, the thing to do would be 'help history', which actually gives a pretty thorough explanation of it. (And it's also explained pretty fully if you look at the actual man page for bash.) What the grandparent commenter saw was in fact just the brief "you invoked this command wrong" synopsis message, since '--help' isn't a flag recognized by the 'history' command (assuming his version of bash behaves similarly to mine).

Sure, there are some more obscure, less-commonly-used commands that are poorly documented, but for the basic stuff (and yes, that includes bash), I've found man pages to generally be a pretty good source of information.

Re: Understanding Bash History

#16
I learnt something handy in BASH recently - operate-and-get-next (Ctrl-o). If you type:

  $ echo one
  one
  $ echo two
  two
  $ echo three
  three
Then up-arrow back to 'echo one'. Then press Ctrl-o instead of enter it will execute the command and display the following one in your history ('echo two' in this case).

Very handy for replaying a series of commands.

http://www.faqs.org/docs/bashman/bashref_101.html

Re: Understanding Bash History

#17
I use history a fair amount, and I've noticed an issue that none of these articles mention.

For history to be useful, you need to be able to reuse previous commands without giving them much thought; in the time it takes to think in detail about a command, you usually could have typed a new one without using history. As a result, commands that are reused via the history mechanism need to be "safe", with no hidden pitfalls.

For example, I use "find" a lot. A normal thing to do with "find" is to get a list of files to delete. Now, I could do that with "find ... -exec rm" or "find ... xargs ... rm", but that leaves me with an unsafe "find" command in my history, just waiting to bite me when I try to reuse it. If, some time later, I type "!fi" without thinking much about it, I might end up deleting some random files. Not good.

My solution, in this particular case, is never to do "find ... rm" on a single line. To remove a list produced by "find", I do "find ..." and then "rm `!!`". That runs the "find" command twice, of course, but the second time, everything has been cached, so it's very fast. (The real disadvantage is that the delay -- for the first "find" -- occurs in the middle of what is conceptually a single operation: after I've typed the "find", but before the "rm".)

So, has anyone else run into this issue? Thoughts? Other ways of dealing with it?

Re: Understanding Bash History

#18
post #15
post #11

Earlier quoted context omitted.

The built-in help for history, unfortunately, is woefully inadequate; this was the output: i always wondered whether linux had such terrible man pages because nobody read them, or whether nobody read them because they were so terrible.

Well, since 'history' is a shell builtin, the thing to do would be 'help history', which actually gives a pretty thorough explanation of it. (And it's also explained pretty fully if you look at the actual man page for bash.) What the grandparent commenter saw was in fact just the brief "you invoked this command wrong" synopsis message, since '--help' isn't a flag recognized by the 'history' command (assuming his vers…

Yes, the actual linux documentations are actually very good. I live on a server with hacked-together shell commands that are badly-documented, so I'm in the bad habit of doing the --help thing (the default around here).

The man pages are indeed very good. It's also worth noting that the Gnu people tend to prefer info pages - and 'history' is traditionally a Gnu-maintained command (as part of binutils) - so you'll get the absolute best documetation I know of (long explanations, interesting permutations, obscure hacks) if you do:

info history

Re: Understanding Bash History

#19

Here are some of my other favorites: ^foo^bar replaces the foo in the last command with bar example: less setup.conf, ^less^vim alt+. recalls the last argument of the last command (in emacs mode, anyway) example: less setup.conf, vim alt+. As mentioned, Ctrl+R is great for history searching. Repeatedly pressing Ctrl+R goes to the next result, and you can use the arrow keys to edit. cd - goes to the last directory. It…

As far as these little shorthands go, you've left out the one I use most all day long; the ever-handy !:-, which means 'the last command minus the final argument':

$ cat ~/my_huge_dataset.csv | tr '\|' ',' >> testing.csv

$ !:- for_real_this_time.csv

>> cat ~/my_huge_dataset.csv | tr '\|' ',' >> for_real_this_time.csv

$

This is really, really handy for me - particularly in two situations: first, when (like above) I'm testing a command by outputting to a random off-server file first; and second (the more often) when I'm running the exact same process on a dozen different files, just pasting the filenames onto the command line. It's really handy to be able to use !:- all the way down for every one.

Oh, and theres's also this: !! - which means 'the last command exactly.' That can be handy, too:

$ rm /usr/lib/libutil.so

>> m: cannot remove `libutil.so': Permission denied

$ sudo !!

$

Re: Understanding Bash History

#20

I use history a fair amount, and I've noticed an issue that none of these articles mention. For history to be useful, you need to be able to reuse previous commands without giving them much thought; in the time it takes to think in detail about a command, you usually could have typed a new one without using history. As a result, commands that are reused via the history mechanism need to be "safe", with no hidden pitf…

find ...

!! -delete

Post reply on HN