

Time-saving tips for Linux - thenicepostr
http://www.quora.com/Linux/What-are-some-time-saving-tips-that-every-Linux-user-should-know

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

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

~~~
klochner
I used cygwin for several years and always felt like a leper - nothing ever
works right out of the box.

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

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

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

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

~~~
davedavedave
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

~~~
X-Istence
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...

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

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

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

~~~
there
_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.

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

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

~~~
nupark
_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:

    
    
      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.

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

~~~
ominous_prime
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>

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

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

------
endlessvoid94
I found out about ack awhile back -- it's like grep on steroids.

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

~~~
gnosis
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?

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

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

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

~~~
maw
Yep, very handy. After finding a match, you can hit C-r again to find earlier
matches.

~~~
travisglines
I think you can keep hitting the up arrow to find earlier matches too

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

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

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

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

~~~
steve-howard
ctrl-u/ctrl-y is good if you only want to do that for one thing at a time.

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

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

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

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

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

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

$ stty stop undef

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

------
klochner
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/>

------
dreur
One thing to say: <http://cb.vu/unixtoolbox.xhtml> It has everything I ever
needed. When something is missing send patch.

------
known
<http://www.cyberciti.biz/faq/> also have some good tips

------
bingaman
Quick ssh and and start screen:

    
    
      function s() { ssh $1 -t screen -dRR }

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

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

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

~~~
cosbynator
You can overcome the visual indicator (at least in zsh, not sure about bash):
[http://unix.stackexchange.com/questions/547/make-my-zsh-
prom...](http://unix.stackexchange.com/questions/547/make-my-zsh-prompt-show-
mode-in-vi-mode)

I'm a recent convert. I don't like using control sequences for anything but
screen management.

