I would like to open a discussion that would accumulate your Linux command line (CLI) best practices and tips.
I've searched for such a discussion to share the below comment but haven't found one, hence this post.
I hope we all could learn from this.
You are welcome to share your Bash tips, grep, sed, AWK, /proc and all other related Linux/Unix system administration, shell programming best practices for the benefit of us all.
Use screen, a free terminal multiplexer developed by the GNU Project that will allow you to have several terminals in one.
You can start a session and your terminals will be saved even when you connection is lost, so you can resume later or from home.
SSH!
SSH is the god command--I think it's the most valuable over-all command to learn. The options can be pretty daunting, but it seems like I'm constantly learning to use new command-line options for SSH that I never thought would be necessary. I may have used them all at this point.
The more you use it, the more you learn about it. You can use it to do some AMAZING things.
Note: ALL these things are doable remotely with no setup on your server except to have ssh server running.
Mount a file system over the internet
search the net for SSHFS
Forward commands.
The SVN+SSH protocol is Subversion from a remote client to a server with NO DEAMON running on it! The SVN command starts the server through the ssh shell and passes the info back and forth through the existing pipe. The rsync program does the same thing, runs against a server with no rsync deamon by starting one itself via SSH. It's easy to write your own bash files to do similar tricks.
Chain to get through firewalls
I use this all the time to jump through my linux server at home to my mac.
Forward ports:
Seems only moderately useful until you realize that you can bounce through your home firewall and configure your router at home from work as though you were doing so from within your home network).
Forward X requests:
This is another amazing one. With or without an X server running on your remote system, you can run an x-windows program and the window will appear on your local screen. Just use the switch -X, that's all!
Since you don't have to have an X server running on your remote server, the CPU impact on your server is minimal, you can have a TINY Linux server that serves up huge apps to your powerful game PC running Windows and cygwin/X.
Of course VI and EMACS work over SSH, but when I'm running at home, sometimes I want more. I use ssh -X to start up a copy of Eclipse! If your server is more powerful than your laptop, you've got the GUI sitting right there on your laptop, but compiles are done on your server, so don't worry about system load.
Run in batch files
(meaning run a local batch file that "does stuff" on other systems):
Two things combine to make this one cool. One is you can eliminate password prompts by using (more secure) encryption keys. The second is you can specify a command on the SSH CLI. I've used this in some interesting ways--Like when a compile fails on the remote server, I would have it SSH into my computer and play a sound file).
Remember you can redirect the output from the remote command and use it within your local batch file, so you could also be locally tailing a compile running on your server.
Built in to Mac
Both server and client are built into both mac and linux. In the case of the Mac and Ubuntu, enabling a server is as simple as finding the right checkbox.
On a PC install cygwin or cygwin/X (cygwin/X will allow you to forward your x-window output from your Linux machine to your Windows PC--it installs an X server)
Important Tips/config file
Never use port 22 on your firewall. You'll get a lot of hack attempts, it's just not worth it. Just have your firewall forward a different port to your server.
There are extensive configuration options that allow you to simplify your ssh commands significantly. Here's an example of mine at work:
When I type "ssh home" (nothing else), it acts as though I had typed:
and then forwards my local port 1025 to my system "mac" at home. The reason for this is that I have another entry in my file:
so that once I've done an "ssh home" and still have the window open, I can type "ssh mac" and the computer at work here will actually try to connect to its own port 1025 which has been forwarded to "mac:22" by the other command, so it will connect to my Mac at home through the firewall.
Edit--cool script!
I dug up an old script I just love--had to come back and post it for anyone here who might be interested. The script is called "authMe"
If you have this script in your home directory and there is a host you can connect to (via ssh), then you can type "./authMe hostName".
If necessary it will create a public/private keypair for you, then it will ssh over to the other machine and copy your public key over (the ssh command will prompt you for a password...)
After this, the SSH command should not ask for your password any more when attaching to that remote system, it will use the public/private keypair.
If your remote computer is not always secure, you should consider setting a "passphrase" when prompted.
You may also want to configure the ssh server on the far end to not allow text passwords (only keys) for additional security.
I like to use
to switch to the previous directory. Very useful!
I've recently discovered the
pv
command (pipe viewer) which is like cat but with transfer details.So instead of
You can use
So instead of having no idea when your operation will finish, now you'll know!
Courtesy of Peteris Krumins
Rerun the previous command as root.
[The current top command on the site http://www.commandlinefu.com, a site themed along the lines of this question.]
The command line is a funny thing. I think that you can only learn so much on your own and the rest you learn by accident watching somebody else using a command line.
I was using the shell for years painstakingly typing in directory names by hand. One day I was watching a friend mess around on a system and he kept hitting the tab key. I asked "why are you hitting tab?". Answer: it tries to complete the directory or filename. Who would have guessed--tab completion! Type a bit of the file or directory, hit tab, and it will try to finish what you typed (behavior depends on which shell though).
One day, said friend was watching me on the command line and watched me type something like:
Who would have guessed!? He never knew about
popd
/pushd
. Guess we are even...Press Ctrl-R and start typing a command (or any part of it) - it searches the command history. Hitting Ctrl-R again will jump to the next match, enter executes the currently displayed command, and right-arrow (at least) will let you edit it first.
I had used Linux for something like 7 years as my main OS before learning of this, but now that I know it, it's quite handy.
Learn Vim.
It is (arguably) the best editor, but most certainly the best editor available on a bare Linux server.
When I want to make sure that I use actual command and not an alias, I use a leading backslash:
It is sometimes useful to leave a program running even after you have logged out. I've seen some solutions that use nohup or even screen for that purpose. The simplest I know of is:
You can also detach a running program: