Time-saving tips for Linux(quora.com)
quora.com
Time-saving tips for Linux
http://www.quora.com/Linux/What-are-some-time-saving-tips-that-every-Linux-user-should-know
88 comments
"Going back to Windows makes you really appreciate the speed of bash, vim and grep."
When I have to use Windows, one of the first things I always do is to install cygwin, so I can use bash, grep, etc.
When I have to use Windows, one of the first things I always do is to install cygwin, so I can use bash, grep, etc.
I used cygwin for several years and always felt like a leper - nothing ever works right out of the box.
I never liked cygwin much, though used it for a bit. For a long time I was a fan of portable ubuntu (http://sourceforge.net/projects/portableubuntu/) which allows you to run ubuntu as a service inside of windows. It was pretty good but it was still not the same as running linux natively or creating a VM that shares all the harddrives and you can ssh into by setting a static IP with your router.
There's a lot that does, though, and it's a huge set of functionality that windows doesn't provide natively. Even something as simple as:
Yes, ultimately it's still a windows box and cygwin's distribution definitely isn't on par with ubuntu or fedora. It's not going to be cutting edge and there will be difficulties integrating with hardware and the windows environment. It's generally not a good choice for running desktop apps or servers, and will probably require some extra work to set up a serious development environment.
But if you have other reasons to use windows (Outlook calendar, games, etc.), cygwin makes it a LOT more tolerable.
ipconfig | grep IP
Yes, ultimately it's still a windows box and cygwin's distribution definitely isn't on par with ubuntu or fedora. It's not going to be cutting edge and there will be difficulties integrating with hardware and the windows environment. It's generally not a good choice for running desktop apps or servers, and will probably require some extra work to set up a serious development environment.
But if you have other reasons to use windows (Outlook calendar, games, etc.), cygwin makes it a LOT more tolerable.
I don't think these tips are that great. Some random criticisms:
ifconfig is deprecated (use "ip" instead).
There is not much value in knowing vim if you know Emacs. If you want to edit something in your terminal, well, emacsclient -t to your Emacs session. Or use mg, which is a very fast and light Emacs workalike -- just enough for editing your /etc/apt/sources.list to get Emacs installed :)
ifconfig is deprecated (use "ip" instead).
There is not much value in knowing vim if you know Emacs. If you want to edit something in your terminal, well, emacsclient -t to your Emacs session. Or use mg, which is a very fast and light Emacs workalike -- just enough for editing your /etc/apt/sources.list to get Emacs installed :)
You don't think these tip are that great for you. But they're not written for Unix command-line ninjas. They're written for average users (like me) who run Ubuntu or some other flavor of Linux and just use the basic commands. I bookmarked the tips and will definitely be revisiting them regularly to improve my command line fu.
Sorry you didn't get anything out of it, but I suspect you don't need tips like "learn vim" and "be familiar with chown".
Sorry you didn't get anything out of it, but I suspect you don't need tips like "learn vim" and "be familiar with chown".
Functionally as a sysadmin, I've heard ifconfig is deprecated before yet I've never used ip. just 'ifconfig' on the command line tells me everything I need to know about what interfaces are up, their status and basic info.
'ip' just gives me the standard syntax description.
The power of the basic shell is that there's usually a few hundred ways to skin a cat. And just because there's documentation saying something is deprecated as often as not it's still so widely used that in practice, it's not.
'ip' just gives me the standard syntax description.
The power of the basic shell is that there's usually a few hundred ways to skin a cat. And just because there's documentation saying something is deprecated as often as not it's still so widely used that in practice, it's not.
ifconfig is deprecated, so probably a good idea to get out of that habit. Particularly if you are using it in scripts.
'ip addr' should give you all the information that 'ifconfig' does. You can also make the output a little less chatty by doing 'ip -o -4 addr' to get IPv4 addresses on one line per interface, or 'ip -o -0 addr' to get MAC addresses displayed similarly. This can make awking / cutting for addresses to use in scripts a little more elegant.
'ip addr' should give you all the information that 'ifconfig' does. You can also make the output a little less chatty by doing 'ip -o -4 addr' to get IPv4 addresses on one line per interface, or 'ip -o -0 addr' to get MAC addresses displayed similarly. This can make awking / cutting for addresses to use in scripts a little more elegant.
I didn't know about the one-per-line option, so thanks for that.
Commands I use regularly instead of using ifconfig:
Commands I use regularly instead of using ifconfig:
# link up/down
ip link set dev eth0 up|down
# add a new address
ip addr add dev eth0 172.16.43.124/24
# to clear all IP addresses from eth0
ip addr flush dev eth0
# delete an address
ip addr del dev eth0 172.16.43.124/24
# add default route
ip route add default via 172.16.43.254
And what is wrong with
This is the same reason as to why I hated that Linux decided to have an ifconfig for physical interfaces, an iwconfig for wireless interfaces. It seems redundant...
ifconfig eth0 up|down?
This is the same reason as to why I hated that Linux decided to have an ifconfig for physical interfaces, an iwconfig for wireless interfaces. It seems redundant...
> And what is wrong with
> ifconfig eth0 up|down?
Nothing, as long as it's working for you (your Linux distribution probably patched some of the remaining ifconfig problems themselves). You likely won't have a problem until you want to use network features that were implemented after 2001.
Nothing, as long as it's working for you (your Linux distribution probably patched some of the remaining ifconfig problems themselves). You likely won't have a problem until you want to use network features that were implemented after 2001.
Yep, I'm fully aware of ifconfig. I use "ip link" just out of habit, and, given that ifconfig is apparently deprecated, it might disappear some day.
Anyway, the point of my post was showing some basic things which can be done with ip, and how to do them.
Anyway, the point of my post was showing some basic things which can be done with ip, and how to do them.
> Edit: I fail at formatting
Really not you. It's one way this site is too minimal.
Really not you. It's one way this site is too minimal.
ip accepts shortened versions of it's commands
e.g.
ip a
ip addr
ifconfig doesn't show the additional IPs on an interface unless they are bound to aliased interface names (eth0:0)
true, but that's how we've always done it where I work.
We use chroot to support multiple web apps with their own ip/domain on a single box. real simple to just add a new /etc/sysconfig/network-script/ifcfg-eth#:# with the proper network config. We can then ifup and ifdown them as necessary, they come up on boot if the config is set...
Just always made sense :)
We use chroot to support multiple web apps with their own ip/domain on a single box. real simple to just add a new /etc/sysconfig/network-script/ifcfg-eth#:# with the proper network config. We can then ifup and ifdown them as necessary, they come up on boot if the config is set...
Just always made sense :)
This isn't really an argument for using ifconfig.
On RHEL and related systems, ifup, ifdown, and everything in /etc/sysconfig/network-scripts/ are all implemented with the `ip` command.
On RHEL and related systems, ifup, ifdown, and everything in /etc/sysconfig/network-scripts/ are all implemented with the `ip` command.
Wait, what? ifconfig is deprecated? Now I need to start typing ip on Linux , yet another variation from my BSD machines where ifconfig is definitely still in use, and Windows where I have to use ipconfig.
'ip' does a hell of a lot more than just list devices. It's really worth learning how to use it.
you also don't need root rights to use it for display - although ifconfig can be run as a regular user, it's not on the path by default so it usually won't show up.
you also don't need root rights to use it for display - although ifconfig can be run as a regular user, it's not on the path by default so it usually won't show up.
ifconfig is on the PATH by default for FreeBSD, Mac OS X, and OpenSolaris... to me it was always rather irritating that wasn't the case in Linux when I needed to find out the IP address of a machine.
I really don't understand why there is a need to throw out a perfectly good tool to replace it with something that is completely different and requires re-learning, and re-writing of scripts that are already using ifconfig.
I really don't understand why there is a need to throw out a perfectly good tool to replace it with something that is completely different and requires re-learning, and re-writing of scripts that are already using ifconfig.
'ip' is also much, much less portable than ifconfig.
I think you still need to be comfortable with basic vi commands as it is _the_ standard editor in Unix. Many a times I've found myself in situations when I had to quick-edit a config file on a new bare-bones server with only vi installed.
As for the quick Emacs workalikes - they are exotic and you can't always be expected to know the packaging commands of the odd Unix system you happen to be working with. And sometimes installing new packages is not an option.
As for the quick Emacs workalikes - they are exotic and you can't always be expected to know the packaging commands of the odd Unix system you happen to be working with. And sometimes installing new packages is not an option.
At first I thought you meant "use 'ipconfig' instead" and I was like, "Whaaaaat?!". Then I checked the man page for "ip". Thank you. It looks rather useful. I don't mess with routing or devices too much but I have in the past and only knew about ifconfig.
> ifconfig is deprecated
Deprecated by whom? Is there any source on this? Nothing is mentioned in the man page, and googling for it turns up a wikipedia article with a [citation needed], a reddit discussion from today linking to wikipedia, and this discussion.
Deprecated by whom? Is there any source on this? Nothing is mentioned in the man page, and googling for it turns up a wikipedia article with a [citation needed], a reddit discussion from today linking to wikipedia, and this discussion.
You can also use nano, which has similar key bindings and is often installed by default, which will do in a pinch until you can install emacs.
Or use mg, which is a very fast and light Emacs workalike
There's also zile, another mini-emacs (great if you run Linux on small embedded computers.) I haven't used mg yet, so I don't know how they stack up against each other.
I do have a creeping feeling I should some day bite the bullet and learn more than 4 vi commands, though.
There's also zile, another mini-emacs (great if you run Linux on small embedded computers.) I haven't used mg yet, so I don't know how they stack up against each other.
I do have a creeping feeling I should some day bite the bullet and learn more than 4 vi commands, though.
When I want emacs to be fast & light I just do emacs -Q.
Basic vi knowledge may not be needed if you only work in Linux, but in my job I can work on Linux, AIX, Solaris, and HP-UX, and vi is the only editor that you can find on all of them in their base installs.
Turn on sudo(8)'s "NOPASSWD" option for yourself (see sudoers(5)).
don't do that. if anything, lock it down even more by enabling tty_tickets.
don't do that. if anything, lock it down even more by enabling tty_tickets.
I wouldn't use NOPASSWD on a server or laptop, but for my personal workstation, security isn't as important as ease of use.
You can't make good security guidelines without regard for context.
You can't make good security guidelines without regard for context.
Why not? My servers have no passwords at all -- they either use SSH keys or kerberos.
Once you have access to a local shell, the game is over. Acquiring root is easy, between local exploits or simply piggybacking on (or sniffing) a valid, passworded sudo login.
Once you have access to a local shell, the game is over. Acquiring root is easy, between local exploits or simply piggybacking on (or sniffing) a valid, passworded sudo login.
Once you have access to a local shell, the game is over. Acquiring root is easy, between local exploits
uh, maybe you should work on that.
uh, maybe you should work on that.
Work on it how? Acquiring root locally is easy because local exploits are a dime a dozen, and once you have local access you can simply piggyback on valid authentication:
alias sudo="sudo and do something evil instead"
do you know how many web/ISP hosting providers are out there that give out non-root SSH access to their customers? or how many do shared PHP hosting that make it easy to run local commands on the server? do you really think all of those servers have been rooted? here are two free shell providers:
http://www.devio.us/ http://sdf.lonestar.org/
if your operating system has no local user security, you should really upgrade it or switch to a different operating system.
http://www.devio.us/ http://sdf.lonestar.org/
if your operating system has no local user security, you should really upgrade it or switch to a different operating system.
do you know how many web/ISP hosting providers are out there that give out non-root SSH access to their customers? or how many do shared PHP hosting that make it easy to run local commands on the server?
Yes. In the late 90s, I worked in security for a company that ran one of the largest (at the time) shared hosting providers.
do you really think all of those servers have been rooted?
If someone was interested enough to capture an administrator's user account, then yes, they have been rooted.
if your operating system has no local user security, you should really upgrade it or switch to a different operating system.
There's no such thing. The local user attack surface is just too large.
As related to sudo, it's silly to think that local OS security can protect you from someone with access to an administrator's shell -- even if using sudo requires a password.
Let me break this down into simple steps:
Scenario 1:
- I acquire access to your password.
- I log in as you, then use your password to sudo to root. Game over.
Scenario 2:
- I acquire access to your SSH key or an active terminal on your server. I do not have your password.
- Logged in as you, I notice that sudo requires your password.
- Since you use zsh, I add the following to your zshrc:
Once someone has a local shell -- especially an administrator's shell -- the machine is effectively compromised.
Requiring a password for sudo is at best a minor speed bump, not an obstacle, and it results in the propagation of password usage throughout your infrastructure. Many of those passwords, once acquired by an attacher, will likely grant access to other, possibly more critical systems.
Yes. In the late 90s, I worked in security for a company that ran one of the largest (at the time) shared hosting providers.
do you really think all of those servers have been rooted?
If someone was interested enough to capture an administrator's user account, then yes, they have been rooted.
if your operating system has no local user security, you should really upgrade it or switch to a different operating system.
There's no such thing. The local user attack surface is just too large.
As related to sudo, it's silly to think that local OS security can protect you from someone with access to an administrator's shell -- even if using sudo requires a password.
Let me break this down into simple steps:
Scenario 1:
- I acquire access to your password.
- I log in as you, then use your password to sudo to root. Game over.
Scenario 2:
- I acquire access to your SSH key or an active terminal on your server. I do not have your password.
- Logged in as you, I notice that sudo requires your password.
- Since you use zsh, I add the following to your zshrc:
sudo () { /usr/bin/sudo sh -c "echo \"pwned. Game over.\" && $==*" }
nupark@fish:~> sudo ls /var/cores
Password:
pwned. Game over.
tar-3493.core
nupark@fish:~>
Once someone has a local shell -- especially an administrator's shell -- the machine is effectively compromised.
Requiring a password for sudo is at best a minor speed bump, not an obstacle, and it results in the propagation of password usage throughout your infrastructure. Many of those passwords, once acquired by an attacher, will likely grant access to other, possibly more critical systems.
"Learn what the number inside something like ls(1) or perror(3) means."
you got me there, I don't know what it means and now I'm curious and can't find it on google
They're the man page sections. When something appears in more than one category, you need to specify the section in the `man` command.
$ man 1 ls
$ man 3 perror
$ man 1 printf
$ man 3 printf
Thanks, quite frustrating not having any keyword that allows you to google something
more info at: http://en.wikipedia.org/wiki/Man_page
more info at: http://en.wikipedia.org/wiki/Man_page
[deleted]
You can also do this:
$ man manI found out about ack awhile back -- it's like grep on steroids.
I'm a big fan of ack, I love the --output feature, which is super handy. Unfortunately it is hardly ever installed when I need it. It's considerably slower than the highly tuned GNU regex code, which only really matters when you're grepping through a ton of material.
Could you give an example of something useful one could do with ack's --output feature?
The manual's a little light on the details.
All it says is:
The manual's a little light on the details.
All it says is:
--output=expr
Output the evaluation of expr for each line
A Perl expression. You could use this for sed-like activities:
# Print included files.
ack --output '$1' '#include <(.*)>'
That's a great example. I just replaced it as the example in the Top 10 List on the front of betterthangrep.com. Thanks.
[deleted]
On Ubuntu, the package name is ack-grep. So use:
sudo -i aptitude install ack-grep
Don't go for ack, which is some Kanji character converter.
Don't go for ack, which is some Kanji character converter.
When first stumbling my way around the shell, after learning about tab completion I discovered the magic wizardry that is command reverse/history lookup (cntrl-r start typing command ... see last command you entered that matches)
Yep, very handy. After finding a match, you can hit C-r again to find earlier matches.
I think you can keep hitting the up arrow to find earlier matches too
The 'learn bash, it's available everywhere' really bit me when I moved from being a Linux Sysadmin to an AIX Sysadmin. Only ksh is available in this case. It took quite a few months to get used to.
Tell me about it. I've always worked with Linux, so was used to bash and its conveniences. Then I got a job where they use ancient Solaris systems with csh. Luckily, tcsh is generally installed which at least supports command line completion (after having to start it manually), otherwise I'd go mad.
Same thing happened to me a few years ago with Solaris and Irix. I used to use bash but the best shell available at work was tcsh. Now I have so much invested in tcsh that it is difficult to change back.
If you are halfway through typing a command but change your mind, hit Ctrl-A, add a # at the beginning to make it a comment, and press enter. You can then return to it later via command history.
A faster way would be to hit Alt-# (does the same thing with just one key combo).
A faster way would be to hit Alt-# (does the same thing with just one key combo).
ctrl-u/ctrl-y is good if you only want to do that for one thing at a time.
It's great seeing all of these commands and shortcuts, and seeing that you know a lot of them. These never cease to be useful.
Even though it seems simple to someone who knows Linux, you can always impress marketing/business people by flying through Linux with these helpful commands, shortcuts, and tips.
Even though it seems simple to someone who knows Linux, you can always impress marketing/business people by flying through Linux with these helpful commands, shortcuts, and tips.
You've got bigger issues if you've got marketing people looking over your shoulder while you're looking through grep's output. (And I doubt they care much about your Linux wizardry, that's why they're in marketing.)
Another trick that I don't see people mention(excuse me if somebody here already did) is the bash history completion:
\esc \tab
This will complete based on your history, argument wise. Very useful when tab completion itself doesn't satisfy you.
\esc \tab
This will complete based on your history, argument wise. Very useful when tab completion itself doesn't satisfy you.
"In bash, use Ctrl-R to search through command history."
Or, add these lines to your .bashrc to use Ctrl-p and Ctrl-n:
bind "\C-p":history-search-backward
bind "\C-n":history-search-forward
Or, add these lines to your .bashrc to use Ctrl-p and Ctrl-n:
bind "\C-p":history-search-backward
bind "\C-n":history-search-forward
Why? C-r and C-s already do each of these, and C-p and C-n are for going back and forward in history. (Personally, I use M-p and M-n so that bash in the terminal works like Emacs.)
One thing that's definitely missing from that list is the "undo" feature of bash which is bound to Ctrl-/ by default. It reverts the last edit you did on the command line. (The keybinding invokes the undo action also in emacs.)
quora appears broken at the moment . . . I was going to suggest:
in many shells (bash, tcsh, etc), !foo will execute the most recent command from your history that matches foo, for example:
[1] http://xkcd.com/149/
in many shells (bash, tcsh, etc), !foo will execute the most recent command from your history that matches foo, for example:
> grep -lots -of -options /complicated_regex/ ./some/path/* | /pipe/filter
# realize you are in the wrong directory
> cd /the/right/directory
> !g
[1] http://xkcd.com/149/
One thing to say: http://cb.vu/unixtoolbox.xhtml
It has everything I ever needed. When something is missing send patch.
http://www.cyberciti.biz/faq/ also have some good tips
Quick ssh and and start screen:
function s() { ssh $1 -t screen -dRR }It's odd that his 2nd tip is "Learn Vim" and then goes on to describe all the bash/readline keystrokes in Emacs mode.
$ set -o viI always found modal editing most valuable when editing and navigating through large bodies of text. I'm not quite sure that it makes sense on the command line, where you're rarely dealing with more than a few lines of text, and seldom need to rearrange those particular lines.
Nevertheless, I switched to zsh on Sunday, and with it, vi keybindings. It's getting better, but it still doesn't feel quite right.
Nevertheless, I switched to zsh on Sunday, and with it, vi keybindings. It's getting better, but it still doesn't feel quite right.
I agree. I'm a vim user and never took to emacs, but the non-modal "emacs" keybindings feel more natural on the command line.
Do you know anyone who actually does this? Even die-hard vi folks I know can't get used to modes on the command line.
I use vim almost pathologically, but I gave up on set -o vi. Since there's no visual indicator of which mode you're in, it's easy to make confusing mistakes and not the right feedback. It just wasn't worth it.
You can overcome the visual indicator (at least in zsh, not sure about bash): http://unix.stackexchange.com/questions/547/make-my-zsh-prom...
I'm a recent convert. I don't like using control sequences for anything but screen management.
I'm a recent convert. I don't like using control sequences for anything but screen management.
Sorry - I accidentally downvoted you.
I use vi mode in my shell all the time, and love it. It only took a day or so to get used to it. But then again, I am a die-hard vim user.
What I'd really like, though, would be a vim mode for the shell, not just a vi mode. Then I could use some of vim's more advanced features, which would make the mode even more useful.
What I'd really like, though, would be a vim mode for the shell, not just a vi mode. Then I could use some of vim's more advanced features, which would make the mode even more useful.
If you've set -o vi, then when you're editing a command line:
esc to get into command mode.
v (just the letter v) will open the current command line in a vi or vim session (depending on your default editor).
Now vim to your heart's content.
:wq will get you out of the vi/vim session, and execute whatever you did in your vi/vim session.
esc to get into command mode.
v (just the letter v) will open the current command line in a vi or vim session (depending on your default editor).
Now vim to your heart's content.
:wq will get you out of the vi/vim session, and execute whatever you did in your vi/vim session.
There's always Conque.
For about a year or two, I've had set -o vi in my .bashrc. It is just so much easier when you work in Vim more than half the time!
The modes still trip me up sometimes, but a quick <Esc> or <Ctrl+c> fixes that!
The modes still trip me up sometimes, but a quick <Esc> or <Ctrl+c> fixes that!
I always use set -o vi. It's in all my .bashrc files. Wish every CLI had it.
I can only speak for myself. Give it a day or two, and it will quickly become as transparent as your editing sessions. Once you cut over, you can forget about chording and arrow keys. Just one key: <Esc>.
I found myself using Emacs keybinding for line wise operation and movement in both vim and shell. It is just verbose to switch between editing modes sometimes.
Going back to Windows makes you really appreciate the speed of bash, vim and grep.