This work is licensed under the Creative Commons Attribution-ShareAlike 2.5 
License. To view a copy of this license, visit 
http://creativecommons.org/licenses/by-sa/2.5/ or send a letter to Creative 
Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA.

Originally written by Kynan Dent (http://kynan.org) for TWATech Radio
(http://twatech.org).

Welcome to TWAT radio for Wednesday, May the 3rd. This is Kynan with a short 'n
sweet Windows from the Command Line.

Today I'm going to talk about some of the command line tools that I schlep
around on my USB key. The majority of these are actually tools that originated
on unix-based OSs and have been ported across somehow. In fact, I've actually
got mostly the same set of basic utilities but split into two categories, those
that are compiled natively for Windows and those that rely on an emulation
layer.

Those in the former camp, thes tools compiled to run "native" to Windows come
from the "GNU utilities for Win32" page at http://unxutils.sourceforge.net/ (the
tinyurl is http://tinyurl.com/5a8rf). These tools are guaranteed to run so long
as they can find the file msvcrt.dll somewhere on the system (it should be in
%SYSTEMROOT%\System32 directory). This file is the Microsoft Visual C Runtime
DLL and I'm pretty sure it actually ships as part of the base OS so it's pretty
likely to be around. The second set, the tools that run on an emulation layer
are the famous Cygwin tools which you can find at http://cygwin.com.

Let's look at Cygwin first:

I'm pretty sure that someone (I think IronGeek in TWAT 64) has talked about
Cygwin before so I'm going to go over this pretty quickly and I'm not going to
cover Cygwin installation or anything:
Cygwin provides a port of common (and some not so common) GNU and other
open-source utilities and applications from Linux over to Windows. Basically, a
whole lot of functionality is built into a DLL called cygwin1.dll that emulates
the normal Linux APIs. This means you can compile your linux application on
Windows (with the ported GCC compiler) and it will make use of this DLL instead
of making the normal system calls and you'll have whatever you want from the
Linux/Unix world running on Windows!

Great news, yes? Well, mostly. This is OK when you're just installing Cygwin on
your desktop but if you want to take a subset of the tools out of the box then
you've got to do a little work. The problem with the Cygwin tools is that the
emulation layer works via the main cygwin DLL (cygwin1.dll) so straight away you
need at least one other DLL to make your utility work and it's quite possible
that a few others will also be needed, depending on the utility in question and
this can lead to the main portability issue - number of files and file sizes.

Let's look at gawk as an example. The gawk executable is only 278KB by itself,
awesome if that's all you need - but like I said, there's a bigger picture. One
of the non-command line pieces of software that lives on my USB key is a very
nice tool called Dependency Walker (which you can find at
http://www.dependencywalker.com/ or http://tinyurl.com/3s4rf). This will show
you all of the DLLs that an executable (or even another DLL) requires in order
to run. If we sick Dependency Walker onto gawk we find that we need:
*) cygwin1.dll which is 1.2MB
*) cygintl-3.dll which is 55KB
*) cygiconv-2.dll which is another 1MB

So for a 250KB tool we need to cart around an extra 2 and a half Megabytes of
DLLS!

That's the reason I originally carried around the UnxUtils tools - only one
dependency that you could always be sure would be available (and is only about
290KB anyway).

These days, with so much portable storage space available it's not so much of an
issue. When I first started using these tools I had them on a floppy and 2.5Mb
of overhead was not really an option there!

I carry around the following Cygwin utilities on my USB key. If you've installed
Cygwin then you'll finds all of these in the bin directory under the root of
wherever you installed it (C:\Cygwin by default I think):
ascii.exe (cygutils)
cat.exe (coreutils)
curl.exe (curl)
cut.exe (coreutils)
echo.exe (coreutils)
gawk-3.1.4.exe (gawk)
grep.exe (grep)
head.exe (coreutils)
links.exe (links)
less.exe (less)
od.exe (coreutils)
sed.exe (sed)
sort.exe (coreutils)
tail.exe (coreutils)
tr.exe (coreutils)
uniq.exe (coreutils)
wget.exe (wget)
whois.exe (whois)

Most of these came from the coreutils package with the exception of ascii, which
came from cygutils. curl, grep links, less, sed, wget and whois all have their
own packages.
Using Dependencsy Walker I worked out that I need seven DLLs to back up the
executables:
cygcurl-2.dll
cygiconv-2.dll
cygintl-3.dll
cygpcre-0.dll
cygssl-0.9.7.dll
cygwin1.dll
cygz.dll

Collect all of that and not only have you got a very handy little text
manipulating mini-programming toolkit but there's a text-based browser and a
couple of web-based troubleshooting utilites in only 5 and a half MB!

The UnxUtils toolset mostly duplicates all of the Cygwin utilites I mentioned
here but, because they've been gathered from all over the place the command
lines are not necessarily the GNU command lines that you're used to. Also the
tools haven't been updated for a long time now, the last update posted on the
page is 30 April 2004.

Given all of this, why would you use the UnxUtils instead of the Cygwin ones? TO
be honest, mostly I don't, but there are a couple of handy tools in there that
aren't part of Cygwin. pclip and gclip for instance are command line tools to
place text on the Windows clipboard and print the Windows clipboard to standard
out respectively. Also, because all of these tools are native to Windows they're
not expecting Unix style pathnames - generally the Cygwin tools are pretty good
at dealing with either Windows paths or unix-style paths but sometimes they can
get confused, for instance, the output of the Cygwin version of which, when I
run "which find" for instance returns "/cygdrive/c/WINNT/system32/find"
whereas the UnxUtils version returns C:\WINNT\system32\find.exe

Horses for courses. Since both of these collections together doesn't even push
10MB I just keep them both and if one doesn't quite fit, I'll use the other.

The other really handy set of CLI tools that I keep on the key are some of the
monitoring and investigative tools from Sysinternals. These can be found at
http://www.sysinternals.com/ or http://tinyurl.com/ho75 and are written by Mark
Russinovich and Bryce Cogswell. These guys have a phenomanal grasp of how the
Windows Operating System works at a very low level (check out "Microsoft Windows
Internals, Fourth Edition" if you want some really good info on how Windows
really works under the purty GUI covers). In the unlikely event that you've not
heard of these guys then I highly recommend heading over to the site,
downloading all the free tools and checking out what you can do!

Anyway, following the standard unix mantra, the Sysinternals tools tend to be
very small and very specialised. I actually have a mirror of the sysinternals
utilites page on my key because EVERYTHING on that site is useful. The tools I
keep extracted and ready to go are all part of the PsTools suite. PsTools is
currently at v2.33 and you can find it at http://tinyurl.com/aoor6. The PsTools
suite contains 13 tools, I'm going to mention five that I use a lot:

PSEXEC :- Allows you to execute processes on a remote machine, basically by
installing itself as a services and then connecting to the service, piping your
input for the duration of the connection. I use this ALL the time because it
effectively gives you a remote console but without having to jump through all
the GUI hoops of the Terminal Services client. If you've an admin account then
the command line is as simple as "psexec \\REMOTE_HOST CMD.EXE"

If all goes well then you'll be presented with a command prompt on the remote
machine! Note that you can't use Ctrl+C whilst PSEXEC is running and don't try
to kick of anything that brings up its own GUI like EDIT for instance. This is
only one of the many things that PSEXEC can do and it's well worth reading the
manual.

PSKILL :- Functions in a very similar way to the resource kit utility KILL.
Basically you supply a PID or a process name and PSKILL will kill it. The
advantage that PSKILL has over KILL is that, like PSEXEC, it can run on remote
servers as well. Very handy for offing recalcitrant services. Sometimes if you
can't kill a process via Task Manager (I get weird access denied messages) then
pskill will do the trick.

PSLIST :- is a command line version of the Windows Task Manager, but better.
Again, like all of the PS utilities it can run on a remote machine which is
always a bonus. What it does normally is display all the running processes on
your machine, with the -t switch it provides the same list but in a tree format
so that you can track down which process started other processes very easily. It
can also can run in "Task Manager" mode, refreshing every x seconds (you can
specify x). It supplies pretty much all the same information as Task Manager
with the exception of the username that owns the process, it can also display
memory usage as well as the standard CPU usage stats.

PSLOGLIST :- is a command line window into the Event Log. PSLOGLIST has copious
filtering options and an AWESOME "tail" functionality that puts it over the line
as tool of choice for command line EventLog watching!

PSINFO :- A cut down version of SYSTEMINFO. Handy for checking out exactly what
the basic specs of either a local or remote machine are. It can report things
like Uptime, Kernel version,Service pack, owner information and install date,
Activation status, IE version, CPU speed and type, amount of memory and disk
space and the video driver. This can be presented in both a human readable and
CSV format.

PSSHUTDOWN :- Does what it says, allows you to log off, reboot or shutdown the
computer from the command line.

It's worth noting that a lot of these utilities I mentioned that have remote
capabilites make use of the ADMIN$ and IPC$ shares to work their magic. If
you're running hardened boxes or you've got firewalls between you and the remote
boxes then it's unlikely that you'll be able to make use of the functionality
without copying the executables over.

Finally there's TCPVCON. TCPVCON will identify the process that is listening on
a particlar port for both UDP and TCP connections. This is actually the same
functionality provided by NETSTAT -n but since NETSTAT didn't get its -N option
until Windows XP TCPVCON comes in very handy on Windows 2000 whilst tracking
down processes listening on suspect network ports.

These are the main ones that use but I can't recommend enough that you spend
some time investigating the other tools that are available on the Sysinternals
website, you're bound to find something you could have used to fix a problem you
had!

The last CLI tool I want to mention is TCPDUMP. TCPDUMP is the networking tool
you wheel out when you really need to know what's going on at a pretty low
level. It was born on UNIX but it has been ported over to Windows and once
again, there're two main implementations - WinDump, which is open source and
freely available at http://www.winpcap.org and TCPDUMP from a company called
MicroOLAP and has to be paid for. You can find TCPDUMP at
http://tinyurl.com/ol3f9. It's a free and fully functional download that remains
free for personal use, there's a $60 registration fee for commercial use though.

So why have I picked a semi-commercial tool? Well, WinDump is nice but in order
for it to work you first have to install the WinPcap driver which is a pain in
the butt if you just want to us it once to troubleshoot a problem, especially if
you can't or don't want to reboot the box you're working on. TCPDUMP (from
MicroOLAP) is a 300K file that requires NO other files, it just works which
makes it well worth it for a portable toolkit that you use on a personal level.

That's all I've got for today, I hope you picked up something handy.

My name's Kynan and you've been listening to another episode of Today With A
Tech radio, on the web at TWATECH.ORG. Remember that TWAT is a community run
project - if you've got some information to share then why not record an episode
and send it in? We always need more episodes!

Thanks again to everyone working behind the scenes to keep TWAT up and running
and special thanks to Audacity for not crashing at all whilst I recorded this
episode.

Thanks for listening