LlamaLabs

First, see what’s in the cache:

$ dscacheutil -cachedump
DirectoryService Cache Overview:
AAAA Queries  - Disabled (link-local IPv6 addresses)
Buckets Used  - 31
Cache Size    - 16

Entry count by category:
Group  - 2
Host   - 11
User   - 3

Flush:

$ dscacheutil -flushcache
$

All gone:

$ dscacheutil -cachedump
DirectoryService Cache Overview:
AAAA Queries  - Disabled (link-local IPv6 addresses)
Buckets Used  - 0
Cache Size    - 0

Entry count by category:

Please see the previous post to see how to clear the DNS cache on OS X Tiger http://llamalabs.com/2007/04/18/how-to-flush-your-dns-cache-on-os-x/

Here’s another rpm command I can never remember. This lists all installed packages, and sorts the list based on installed size.

rpm -qa --queryformat '%{SIZE} %{NAME} %{VENDOR}\n'  | sort -n

The -qa flag specifies that we wish to query all packages. The –queryformat flag specifies how we want each result to be formatted. See below for additional items you can put in your query format string. The -n flag for sort tells us to perform a numerical sort (rather than alphabetical). Try it without the -n to see how the output looks.

Here’s an example to see the 10 installed packages that take up the most space:

[user@host ~]$ rpm -qa --queryformat '%{SIZE} %{NAME} %{VENDOR}\n'  | sort -n -r | head -10
195644952 VMware-server VMware, Inc.
113550744 jdk Sun Microsystems, Inc.
66639973 glibc-common CentOS
52098364 compat-gcc-34-c++ CentOS
51851071 festival CentOS
45929176 libstdc++-devel CentOS
41768729 libgcj CentOS
41719064 MySQL-server-community MySQL AB
41653082 frysk CentOS
38859091 firefox CentOS
[user@host ~]$

There are many options that you can specify in your query format. Try this command to get a list:

[user@host ~]$ rpm --querytags
HEADERIMAGE
HEADERSIGNATURES
HEADERIMMUTABLE
HEADERREGIONS
HEADERI18NTABLE
SIGSIZE
SIGPGP
--snip--

Geoffrey Grosenbach, author of the nuby on rails blog, wrote an article titled Useful Shell Shortcuts.

He talked about the Using csh & tcsh book and gave some examples of some shortcuts. I remember using those shortcuts for a while but eventually forgot them all.

What I really found interesting were the CLI tools for interfacing with the clipboard in Mac OS X. I was surprised to see that those utilities existed. See the man pages for pbcopy and pbpaste for details on those tools.

I figured i’d mention a couple of useful commands that I use on a regular basis.

The first is Ctrl+L to clear the screen. Old habits can die hard, but there’s no reason to type ‘clear’ and hit enter to clear the screen if your shell supports Ctrl+L. I’m not sure when this feature came about, but it seems to work on tcsh 6.12.00 and bash 2.05 and 3.

The second thing I use frequently is history along with the !n shell shortcut (where n is the history id). History shows an integer next to each command. If you wish to run the command with the number 42 at the beginning of the line, you simply type !42 at the prompt.

The other benefit of using history is in a shared server environment. You’d be surprised at what you can learn by looking at the commands that other people run.

For a long time I had been using lsof to track down which process was listening on a particular port, and I know i’m not the only person to find it that way. The -p flag for netstat helps out by showing the pid of the process that owns that listening socket. Here are the flags I use when doing a netstat:

-p, --program
  Show the PID and name of the program to which each socket belongs.
-a, --all
  Show both listening and non-listening sockets.  With the --interfaces option,
  show interfaces that are not marked
--numeric , -n
  Show numerical addresses instead of trying to determine symbolic host,
  port or user names.

This gives a nice output like this:

[root@host ~]# netstat -anp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address  Foreign Address  State  PID/Program name
tcp        0      0 0.0.0.0:22       0.0.0.0:*     LISTEN      10587/sshd
tcp        0      0 0.0.0.0:80       0.0.0.0:*     LISTEN      16872/httpd
tcp        0      0 0.0.0.0:21       0.0.0.0:*     LISTEN      26698/proftpd
tcp        0      0 0.0.0.0:25       0.0.0.0:*     LISTEN      2209/sendmail

It can be a lot faster using the netstat -anp method on heavily loaded systems.

Adjust your call to dd to get the size you want.


[root@host ~]# dd if=/dev/zero of=/swapfile bs=1024 count=1048576
1048576+0 records in
1048576+0 records out
[root@host ~]# sync
[root@host ~]# mkswap /swapfile
Setting up swapspace version 1, size = 1073737 kB
[root@host ~]# swapon /swapfile
[root@host ~]# echo "/swapfile swap swap defaults 0 0" >> /etc/fstab


It’s often useful to provide some sort of output when a script is waiting for something or running a loop that take a while to complete.  Instead of writing a bunch of output and running the risk of scrolling useful information off the page, I like writing out a single ‘.’ every once in a while, just to let me know the script hasn’t hung.

The problem with just writing a ’.' is that most terminals/operating systems use a feature called “buffering”.  When you write to a file (or terminal/stdout) the operating system doesn’t immediately flush that output to where you are writing.  It will wait until a sufficient amount of data has been written, and then flush it all out at the same time to save on resources/system calls.  A single ‘.’ is nowhere near enough data to signal the OS to flush that output, so you’ll end up seeing a bunch of them all written when the loop completes, or worst yet, nothing until the script is finished.  For example:

#!/usr/bin/env ruby
20.times do
putc('.')
sleep(5)
end

On first glance, you’d think this script would print 20 dots on a line, one every 5 seconds, but it doesn’t! When run, it sits there for a full minute without outputting anything, and then spits out 20 dots right before quitting. We need to turn off write buffering on $stdout by turning on sync mode:
$stdout.sync=(true) if not $stdout.sync

If you add that line to the top of the script, each dot is written to the terminal right away.

Lately I’ve been entranced by Amazon’s EC2 and S3 systems, but it has brought up some good ideas to share here. This one came in handy when writing a shell script to automate installation of Debian in a loopback file mount, and I needed the script to write another script itself. I’ll get around to posting that sometime later, but for now…

#!/bin/sh
# ... other stuff ...
sudo cat > $CHROOTMNT/tmp/chroot.sh <<'CHROOT'
#!/bin/bash
cd /usr/local/
unzip /tmp/ec2-api-tools.zip
ln -s ec2-api-tools* ec2-api-tools
chmod -R a-w /usr/local/ec2-api-tools/
rm /tmp/ec2-api-tools.zip
cat >> /etc/profile <<'EC2APIPROFILE'

export EC2_HOME=/usr/local/ec2-api-tools
export PATH=$PATH:$EC2_HOME/bin
EC2APIPROFILE
# ... other stuff ...
CHROOT
sudo chmod a+x $CHROOTMNT/tmp/chroot.sh
sudo chroot $CHROOTMNT /tmp/chroot.sh

I was having trouble before finding this.

Disabling parameter substitution permits outputting literal text. Generating scripts or even program code is one use for this.

Without disabling parameter substitution, it was expanding "$PATH" to my current $PATH, instead of writing "$PATH" like I wanted. Sure, I could have unset it before running the script, but this is much more useful.

Have you ever done a commit and then realized that the message you put wasn’t quite right? It is possible to change those messages using the Subversion admin tools.

From the Subversion book: Commit Log Message Correction

Example:

[admin@svn]$ echo "Here is the new, correct log message" > newlog.txt
[admin@svn]$ svnadmin setlog myrepos newlog.txt -r 388 --bypass-hooks

It’s not often that I need to do this, but I always end up looking it up.

From the command line:

sudo lookupd -flushcache

And just for fun, you can examine your resolver configuration using:

lookupd -configuration

I had been using cat /dev/null > /path/to/file for a long time. Whlie reading through a friend’s shell script for creating Amazon EC2 images I found out another way of erasing the contents of a file.

> /path/to/file

That results in the open system call being called with the O_TRUNC flag.

open("/path/to/file", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666)