Time-saving tips for Linux | Hacker News Reader

Time-saving tips for Linux

quora.com

242 pointsthenicepostr85 comments

The learning curve of vim was pretty steep, but once over the hump you get some massive benefits. That said, I bet I'm only using 1% of the available commands.

Going back to Windows makes you really appreciate the speed of bash, vim and grep.

"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.

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:

     ipconfig | grep IP

Not possible in windows. Then there's the rest of the userland tools unix people take for granted like rsync, screen, diff, tr, wget, etc. The standard shells and scripting languages all work. Plus I always set up an ssh server to run on localhost, so that I can use putty as my terminal rather than the windows' crummy cmd.exe.

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.

You don't need to give up vim and grep on windows. gVim works great and since vim has the built-in vimgrep command, you can use that. You do lose the awesomeness of a shell like bash or zsh.

Thanks for vimgrep. I didn't know about that.

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 :)

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.

Personally, not a fan... but at least it's the default on Debian.

I hate nano with passion. The key bindings makes absolutely no fscking sense and resemble nothing else. Just learn vi and emacs basics.

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.

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.

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 :)

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.

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.

I didn't know about the one-per-line option, so thanks for that.

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

Edit: I fail at formatting

> Edit: I fail at formatting

Really not you. It's one way this site is too minimal.

And what is wrong with

  ifconfig eth0 up|down?

Why would I want to type more to accomplish the same task?

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...

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.

> 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.

ip accepts shortened versions of it's commands e.g.

    ip a

can be used instead of

    ip addr

Even shorter than ifconfig!

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".

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.

When I want emacs to be fast & light I just do emacs -Q.

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.

'ip' is also much, much less portable than ifconfig.

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 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.

> 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.

http://lartc.org/howto/lartc.iproute2.html#LARTC.IPROUTE2.WH...

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.

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.

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

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"

Once an attacker has local access, you've lost. It's a short leap from there to root. What's more, by requiring that users supply passwords to use sudo, you're practically guaranteeing that they will reuse passwords that thy use elsewhere, exposing your network to further compromise should those passwords be acquired from a compromised server.

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.

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.\" && $==*" }

- You log in, and run some innocious sudo command. You enter your password, and then get a surprise:

  nupark@fish:~> sudo ls /var/cores
  Password:
  pwned. Game over.
  tar-3493.core
  nupark@fish:~>

Under what scenario will the password requirement protect you? If the attacker can't take advantage of the situation immediately, they can just as easily leave a landmine that you won't notice until it's too late, if ever.

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

http://en.wikipedia.org/wiki/Man_page

Thanks, quite frustrating not having any keyword that allows you to google something

more info at: http://en.wikipedia.org/wiki/Man_page

You can also do this:

  $ man man

I 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:

  --output=expr
     Output the evaluation of expr for each line

What expression are they talking about? A regular expression? If so, how is that different from a normal grep?

A Perl expression. You could use this for sed-like activities:

    # Print included files.
    ack --output '$1' '#include <(.*)>'

You could presumably do much trickier things as well, since the --output argument can contain any Perl expression.

That's a great example. I just replaced it as the example in the Top 10 List on the front of betterthangrep.com. Thanks.

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.

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).

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.

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.

"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

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.)

Doessn't that just do the same thing as the built-in Ctrl-r and Ctrl-s? Also, Ctrl-p and Ctrl-n are already used to cycle through previous commands.

You usually can't use C-s because it's bound to stop.

$ stty stop undef

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:

   > grep -lots -of -options /complicated_regex/ ./some/path/* | /pipe/filter
   # realize you are in the wrong directory
   > cd /the/right/directory
   > !g

and similarly, !! is the most recent command, which comes in handy for "sudo !!"[1]

[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 vi

I 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.

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.

Sorry - I accidentally downvoted you.

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 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.

There's always Conque.

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.

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!

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.

Reply on news.ycombinator.com