Hacker News Reader

Comment by jacquesm | Hacker News Reader

Not sure if it is a 'gem' but it certainly is useful:

Quick one liner to get a fix on who is currently messing with your server in ways that are 'counter-productive', also a nice way to show newcomers to unix how you can string together existing unix commands to create new ones on the fly.

As for start-up advice that would fit in one line:

A practical, bug ridden, bad implementation of something trumps a theoretical, perfect implementation of the same thing.

View on HN

To generalize that a bit: learn the unix cmdline utilities and how to use them together. Something as simple as

  grep "some pattern" * -R | cut -d' ' -f1 | 
    xargs sed -i -e 's/some_other_pattern/replacement/g'

will save you 15 minutes of painful searching and replacing through numerous files.

And keep a cheat sheet of the ones you've found really useful.

And always, always, always! test commands (or queries, for that matter) before executing them. For instance, my example would run 'sed' multiple times on files containing multiple matches of the string grep searches for. And it should have been cut -d':' -f1. Running it without the 'sed' command would have made both those things clear immediately. If you think you know for sure it does what you intend it to do, but you didn't test it, then it doesn't do what you think it does.

A good trick for that is to type in the whole command with 'echo' as the final one in the place of the command that actually makes changes. Then you replace the echo with the 'real' thing on the next run if the results where what you expected them to be. In the case of 'rm -rf $1. *' that would save you a lot of hunting around for backups ;)

This also works for SQL commands: use SELECT before UPDATE/DELETE with the same WHERE clause for sanity check.

This one is super important. I just got burned by this a couple of days ago. Sometimes I blow by the WHERE clause because I have a happy Enter finger.

It's also not a bad idea to do a quick mysqldump of the database you are working on, just in case.

I always thought the missing where defaulting to all records was a bug in the spec, and would have much preferred it if 'where true' was a mandatory thing on deletes and mass updates instead of the current default.

Yeah, I made it a habit to start entering a query by typing 'WHERE', before anything else.

I put my cheat sheet in a folder called ~/bin, which is in my path.

Care to share or put them on github or something? You don't need to comment them or anything. I find that looking at other people's scripts really helps me learn new ways to use the shell. Thanks.

Actually I just checked and there's only one in there -- I guess I use shell scripts a lot less than I used to. Here it is:

  #!/bin/sh

  # reform = re-format code to use different indentation
  # Usage:
  #    reform oldIndent newIndent source destination
  #
  # e.g. reform 3 4 fred.py fred1.py
  
  unexpand --tabs=$1 $3 | expand --tabs=$2 >$4

Incidently, this is typical shell script for me -- anything that requires loops or control structures, I do in Python. The predominance of comments over code is also typical for me.

I like to alias commands and put them in ~/.bash_profile for the ones that are useful. Then to see what you have saved you just type alias to get the list of all the current aliases. if there is one that could possibly do harm to your system and you dont want it to run you could do a alias possiblyBadCommand="0 && whatever command you want to save but never run." If you accidentally run possiblyBadCommand it will just exit out saying -bash: 0: command not found

    ... | sort -nr | head

...may save tail(1) some work.

I love this snippet. Awesome! Anything else you care to share?

Reply on news.ycombinator.com