Using Bash History More Efficiently
If you've used bash for a while you probably know that the commands you enter are saved in the file ~/.bash_history when you log out. Next time you log in, bash automatically loads these history commands from the saved file and you can then use the up and down arrow keys to browse your command history and find the command you want rather than re-entering it.
However, there are more effective ways to use bash's history: you can use Ctrl+R (Control key held down at the same time as the R key). This will display the following in your shell:
(reverse-i-search)`':
If you know type some substring found in the command you're searching for, for example "ls", bash will search for matching commands. For example, it might show:
(reverse-i-search)`ls': lsof -nP -p 3930
What it actually shows is going to be dependent on the commands you've previously entered.
When you do this, bash looks for the last command that you entered that contains the substring "ls", in my case that was "lsof ...". If the command that bash finds is what you're looking for, just hit Enter to execute it. You can also edit the command to suit your current needs before executing it (use the left and right arrow keys to move through it). If you're looking for a different command, hit Ctrl+R again to find a matching command further back in the command history. You can also continue to type a longer substring to refine the search, since searching is incremental.
Note that the substring you enter is searched for throughout the command, not just at the beginning of the command.
Cheng Renquan, Shenzhen, China
Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
| Trying to Tame the Tablet | May 08, 2013 |
| Dart: a New Web Programming Experience | May 07, 2013 |
- RSS Feeds
- New Products
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Home, My Backup Data Center
- A Topic for Discussion - Open Source Feature-Richness?
- Dart: a New Web Programming Experience
- Developer Poll
- What's the tweeting protocol?
- Trying to Tame the Tablet
- Reply to comment | Linux Journal
9 min 24 sec ago - Reply to comment | Linux Journal
1 hour 26 min ago - great post
2 hours 1 min ago - Google Docs
2 hours 24 min ago - Reply to comment | Linux Journal
7 hours 12 min ago - Reply to comment | Linux Journal
7 hours 59 min ago - Web Hosting IQ
9 hours 33 min ago - Thanks for taking the time to
11 hours 9 min ago - Linux is good
13 hours 7 min ago - Reply to comment | Linux Journal
13 hours 24 min ago
Enter to Win an Adafruit Prototyping Pi Plate Kit for Raspberry Pi

It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Prototyping Pi Plate Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- Next winner announced on 5-21-13!
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.



Comments
UNIX/Linux
more . bash_history
hs example caveats
The example find/rm commands are not bullet proof
if file names e.g. contain spaces. find and xargs
as well as the other alternative have ways of dealing
with that, so
"man find"and"man xargs";-)I wasn't suggesting the find/rm examples as models for best practice.
But defining an hs function can be handy, and you can put it
in an appropriate bash initialization file to have it available
automatically if you like.
BTW, this
http://tldp.org/LDP/abs/html/
link leads to a lot of good bash tips.
In bash, the history command
In bash, the
historycommand will listthe whole recorded history to stdout, so you can easily
pipe that to grep and search for an arbitrary pattern.
To make that more handy, you can define a function, e.g.,
hs (for history search, hg already existed for me ;-) thus:
[15:33 ~]$ function hs () { history|grep "$@" ; } # don't leave out spaces
Then, if you remember some complex command, e.g., involving
find and rm, you can do something like
[15:33 ~]$ hs 'find.*rm'
225 find .. -type f -iname '*swp' |xargs rm -iv {} \;
228 for f in $(find .. -type f -iname '*swp'); do rm -iv $f;done
533 hs 'find.*rm'
Hm, that command 228 was safer than 225. I remember using echo to
pre-test the action. Look for that:
[15:34 ~]$ hs 'find.*echo'
227 for f in $(find .. -type f -iname '*swp'); do echo "'$f'";done
534 hs 'find.*echo'
[15:34 ~]$
It pays to pay attention to detail if re-executing with
!nnne.g. the find above was below the parent directory at the time. It
won't be what you want to repeat from another place, most likely.
Your history will obviously yield different matches from mine.
BTW, do not arbitrarily remove .swp files!! They are vim's way
of protecting you from yourself ;-) Don't mess with them unless you
know for sure they are no longer needed! I only used that example
because most other commands in my history are trivial to retype.
In my humble opinion, there's only <C-R> useful.
In my humble opinion, there's only most useful.
Other commands like "!tail" starts with "!" are not useful just because I don't trust them only if I see and confirm the whole command. Commands like "!tail" are harmless that it never will destory something, but do you dare to execute "!rm" ? Do you know what will be removed if you don't remember the whole command?
Commands like "!tail:p" are also not very useful that it needs more key strokes. I use and "tail" to check the last commands contains "tail", it needs less key strokes.
Setup extra key bindings in ~/.bash_profile is really useful, for those want to customize something, I just only use the default Bourne-again shell.
Cheng Renquan, Shenzhen, China
Onw nice tip is to use
Onw nice tip is to use Up/Down arrows for forward/backward history search:
# a better up/down arrow key behaviourbind '"\e[A"':history-search-backward
bind '"\e[B"':history-search-forward
Now start typing a command (say - ssh) and hit Up arrow to search for all ssh commands.
Regarding history search with "!".
On July 8th, 2009 Anonymous
# !tail:p
One could:
$ !tail Alt+^which would complete the !tail command (in cases when you are not sure).
Great stuff
Thanks for the main article and the great comments. That is so cool.
Additional tip
Set up the following bindings in your .bashrc or .bash_profile:
# Setup and to act like vi for command line history searching
bind -m vi-insert \C-f:history-search-forward
bind -m vi-insert \C-b:history-search-backward
This allows for Control-B to search back through your history for lines matching the partial command you have already typed. Example:
$ history |tail -10
201 svn checkout -r 5267 .
202 svn update -r 5267
203 ls
204 cd build/
205 ls
206 doxygen Doxyfile 2>&1 | tee doxygen_R5267.log
207 grep c-b ~/.bash*
208 more ~/.bashrc
209 hist |last -10
210 history |tail -10
$ doxy
$ doxygen Doxyfile 2>&1 | tee doxygen_R5267.log
One limitation, it is for Vi-keybinding types.
save time searching through bash history
Good tip. I guess what I'm about to share is also related to this article and most importantly saves you a bit of time when combing through your bash history. In order to execute a command you used before, you can just enter an exclamation mark "!" before the command and it'll be executed.For instance if I ran the command 'tail -n 100' and I wanted to execute it again, instead of typing the whole command, i can just do:
# !tail
and my previous command will be executed. In some cases, you might just want to see the command but not execute it. Then you can do:
# !tail:p
Hope this is useful to someone.