HulaBats: A Toolkit For The CMD Shell


Batty (of the HulaBats)

Batty is our logo/icon. She is supposed to represent the Hawaiian Hoary Bat and is dressed in a grass-skirted Hula dancer's outfit. The orange backdrop is intended to represent the oh so incredible colors of Hawaii's sunsets, and, also, Halloween, which is our favourite time of year to be out snorkeling on the Big Island. So, with Batty in the spotlight, let the show begin ...

Recognized expert, Ben Okimoto, DVM, Zoo Veterinarian at the Honolulu Zoo in Oahu, has been quoted as saying, "Historically, the Hoary bat was the only land mammal here when the Hawaiians came". Here is a pix we found at "" (also, the source of the above quote) of a real Hoary bat ...

          Hawaiian Bat-Honaunau.jpg (81671 bytes)

HulaBats is a collection of UNIX®/Linux®-like tools
that we have hacked together over the past twenty or so years,
some from our early UNIX®/MS-DOS days, and others, more recently,
were created while porting Solaris® based software over to
Microsoft® Windows® 2000/XP platforms during the last six years.
Most recently, we have been working with
Windows® Vista and 2003 Server R2, as well.

Our goal has been to pull together all our utils into a package/book
and, ultimately, we settled on the name HulaBats, since that
describes what most of the commands are - .bat, .cmd batch files -
also, known as "dot bats".  The .bat extension was solely in use back
in the legacy MS-DOS days, the .cmd extension came about with the
introduction of the CMD shell under Windows® NT®, either one works.
These days we almost exclusively use the .cmd extension, and reserve
use of the .bat extension for "build.bat" wrappers around "build.xml"
Ant scripts that are doing wildcard installs of *.cmd scripts where you
do not want the build.bat itself included during the copying to the
target location.

HulaBats could be installed in: C:\progra~1\HulaBats
(or C:\Program Files\HulaBats).  Maybe with an override option
to go into places like:  C:\HulaBats (or C:\batch)
We could include instructions on how to use the 'ln.cmd' to make
a link (JUNCTION) to the default location.  But, we will probably
just release it in two .zip file(s) (,
with relative pathnames like .\HulaBats so you can extract it
wherever you so desire to put it, and then you can add
the absolute path to it on your search PATH as you see fit.
Java's jar.exe can be used to extract the .zip files easily, too,
or, the wzunzip.exe tool from WinZip, or Info-Zip's unzip.exe, or
PK's pkzip25.exe.

The core base utils will be standalone .bat/.cmd scripts that do not need
anything other than the basic Windows® 2k/XP/Vista system to work ok.
We will lean towards Windows XP and 2k3srv but we have started to port
to Vista, too.  Maybe a later edition can provide enhancements to the
Windows PowerShell (aka msh, Monad), someday.

Additional utils will either have dependencies on other's .exe's
or our own, or will just be our own or freely distributable (e.g.,
under the BSD UN*X license or something like it) .exe's.  See copyright.rem
used for .cmd files, and copyright.cpp used for C/C++/Java files.  Perl
is very useful and the user may be pointed to ActiveState or Cygwin®
for it, or we may be able to provide our own build that includes LibWin32
as a backup along with the source for our Perl version and 'dmake' on request.

A contest for the best package title?
HulaBats is a continuation of our original ideas for a developer book:
"Windows Shell Script Programming (for UN*X Geeks and Wannabees)".  We had
a lot of various titles for the book though along the way.  Such as:
"Windows Shell Script Programming (for the UN*X Literati)".  Or, maybe
one of these:

"HulaCmds: UN*X/Linux Tools for Cmd Shell Users"
"HulaCmds: UN*X/Linux Toolkit for the Cmd Shell"
"HulaCmds: A Toolkit for Cmd Shell Users (like UN*X/Linux Geeks and Wannabees)"
"HulaCmds: Yet Another Toolkit of UN*X/Linux Commands for Cmd Shell Users"
"HulaCmds: A Toolkit for Cmd Shell Users"
"HulaCmds: A Toolkit for Command Shell Users"
"HulaCmds: A Toolkit for Command-Line Shell Users"
"HulaCmds: A Toolkit for Command-Line Users"
"HulaCmds: A Toolkit for Cmd-Line Users"
"HulaCmds: Harstine UN*X/Linux Advocates Commands"
"HulaCmds: Harstine UN*X/Linux Applied Commands"
"HulaCmds: Harstine UN*X/Linux Associated Commands"
"HulaCmds: Harstine UN*X/Linux Associates Commands"
"HulaCmds: Harstine UN*X/Linux Applications Commands"
"HulaCmds: Harstine UN*X/Linux Applicable Commands"
"HulaCmds: Helpful UN*X/Linux Applications for Command-Line Users"
"HulaCmds: A UN*X/Linux Toolkit for Cmd Shell Users"
"HulaCmds: A UN*X/Linux Toolkit for Cmd-Line Users"
"HulaCmds: A CMD-Line User's Toolkit (for UN*X/Linux Geeks and Wannabees)"
"HulaCmds: A Command-Line User's Toolkit (for UN*X/Linux Geeks and Wannabees)"
"HulaCmds: CMD Shell Command-Line Toolkit (for UN*X/Linux Geeks and Wannabees)"
"HulaCmds: A Software Porter's Toolkit (of Cultivated Anachronisms)"
"HulaCmds: A Software Porter's Toolbox (of Cultivated Anachronisms)"
"HulaCode: A Glue Coder's Garden (of Cultivated Anachronisms)"
"HulaGlue: A Glue Coder's Tropical Garden (of Cultivated Anachronisms)"
"HulaGlue: A Glue Coder's Garden (of Cultivated Anachronisms)"

variously, alternating Bats for Cmds after Hula works, as well.

A contest for the best acronym?
While "Hula" of course refers to the native Hawaiian dance
that was once banned by the conservative Christian colonialists,
its Hawaii connotations for us are not to be discounted because 
we love Hawaii and want to move there someday to be nearer to our
sister, Sunny.  However, currently, we reside on Harstine Island
in Puget Sound, so the winner of the acronym contest that most
closely aligns to our own interests is ...

Hula = Harstine UN*X/Linux Advocates

This has a .org ring to it don't you think?

However, if/when we finally make it to Hawaii we can change
"Harstine" to "Hawaii" without changing too many references to it.

And, in the long run, the web site will, hopefully, be: or

but web hosting is so pricey and well, who has the extra time?

The runner-up was ...

HULA = Harstine UN*X/Linux Associates

But then there is only me, so that one makes little sense.

The contesting suffixes were ...

Bats = Batch files (dot bats, .bat's)   (HulaBats)
BATS = Business And Technology Software (HulaBats)
RATS = Research And Technology Software (HulaRats)

However, we found out someone in China has already claimed as their domain - even though they have no web site
that we can find.  So, we threw out the rats and stuck with bats
which led us to Batty, of course, and the Hawaiian Hoary Bat,
and the hula skirt.

Other prefix contest contenders were ...

HULA = Harstine UN*X/Linux Applications
HULA = Harstine UN*X/Linux Associated
HULA = Harstine UN*X/Linux Associates
HULA = Harstine UN*X/Linux Applied
HULA = Hawaii UN*X/Linux Advocates
HULA = Hawaii UN*X/Linux Associates
HULA = Hawaii UN*X/Linux Associated
HULA = Hawaii UN*X/Linux Applications
HULA = Hawaiian UN*X/Linux Advocates
HULA = Hawaiian UN*X/Linux Associates
HULA = Hawaii-lover's UN*X/Linux Advocates
HULA = Hawaii-lover's UN*X/Linux Associates
HULA = Heritage UN*X/Linux Apps
HULA = Helpful UN*X/Linux Apps
HULA = Helpful UN*X Lover's Apps
HULA = Have UN*X command-Line Apps (will travel)
HULA = Have UN*X Lover's Apps (will travel)
HULA = Have UN*X/Linux Apps (will travel)
HULA = Has UN*X Lover's Attention
HULA = Has UN*X-Like Applications
HULA = Has UN*X Logical Applications
HULA = Has UN*X/Linux Applicability
HULA = Has UN*X/Linux Aspirations (wannabe?)
HULA = Hot UN*X command-Line Apps
HULA = Hot UN*X Lover's Apps
HULA = Hot UN*X/Linux Apps

And two of our special favourites (as in "glue code") were:

Glue = God Loves UN*X Environs
Glue = God Loves UN*X Engineers

but we couldn't seem to fit the glue word in very well, and
HulaGlue sounds a bit sticky, don't you think?

Enough of that nonsense.  What about the toolkit?   It's mission in life...
The toolkit needs to be small enough to fit on a developer's USB flash drive
so they can carry it around in their pocket.  It must be as standalone as
possible.  It is designed to not require a big product installation (like
SFU/SUA, Cygwin, &c) and get the developer up-and-running faster, working
with familiar command-line tools, like on quick-and-dirty jobs such as fixing
your sister's or a neighbor's computer.  It needs to be easily customizable
for programmers, so they don't have to recompile things IOW.  That's
where shell scripts excel!  There are no dependencies on some big
fat DLL (like Cygwin has).  There is no need for a POSIX sub-system,
either (like SFU/SUA has).  It should be inexpensive (or "free" even).
It is designed for the Windows 2kpro/2ksrv/XPpro/2k3srv/Vista platforms.
But, there are associated components for WindowsCE/PocketPC, as well.

Security can be an issue when working short-term on other's systems.
They may not want you installing a big package like Cygwin or SFU/SUA.
It can also be an issue if you are part of a team and you tell the
other members that you need to add, say Cygwin, to the baseline.  Oh my.
There may be licensing issues, extra cost $$$.  Managers may not approve.
There may be reluctance to add software that may have come from one of
your enemies (USA, Russia, China, India, Iran, Palestine, Israel, ...).
It may leave a bad taste in their mouth if you try including GNU copyleft code.
The nice thing about what we are hoping to do here is that you have the
source code - heck, most of it is in CMD script.  You can pretty easily
read it to determine if it has been hacked.  The other tools?  Well, we will
make sure that you have the source code for them, and show you how to compile
them all yourself so you know where the .exe's came from.  There will be
no licensing issues that keep you from using HulaBats in whatever products
you choose (as long as you abide by our little quirks in the copyright
notice), or from leaving it hanging around on your mother-in-law's PC because
you forgot to remove it after you were done fixing up her system.

There is some precedence in UN*X systems, too, in having many commands
coded as shell scripts (or batch files in this case).  If you have ever
bothered to run the 'file' command on executables in /bin (or /usr/bin)
you might see that many of them are shell ('sh', 'csh') scripts.  So,
following in that tradition, our challenge has been: see how many UN*X
like scripts (or Windows batch files) you can code that emulate actual
UN*X commands.

Another part of the HulaBats mission, by implementing the 80:20 rule,
is to provide the most common options and capabilities that we normally
use all in a days work.  If you look at all the options that have
evolved over the years in most if not all the common UN*X commands
you will be astounded.  But, at the beginning, back to V7 UN*X and
before, life was somewhat simpler.  A few switches here and a few
options there, and you could get by and still do good things.  That
is the way these .cmd scripts have been implemented.  First come one
or two basic capabilities that are those most commonly used (80% of
the time) given about 20% of the effort (to "make it so" as Capt.
Jean Luc Picard used to stay in Star Trek Next Generation).  Then
over time, as time allows, add a few more here and there to make
them more complete (if Windows will let you find a way to implement
them that is).

Oh, and one thing more, there are to me many major annoyances about
Windows, that I have been searching for solutions or work-arounds
for over the years, and, whenever possible, another goal of HulaBats

is to alleviate some of these aches and pains.  A prime example of
this type of thing comes in the capability of these two commands:
    pgrep -v cmd.exe
    tty -v

I normally work on a desktop with 4, 5 or 6 shell windows mixed
in equal parts Windows cmd.exe and Cygwin bash shells.  I resort
to Cygwin for powerful features like a full 'find' implementation.
But as one of my goals is to improve on the HulaBats collection
I also try to work with cmd windows using the .cmd scripts to
stress them and tweak them a little each day.  Well, when you
do a 'ps' (or 'tasklist' or 'tlist' or 'pulist' (except for 'ptree'
which has disappeared since the Windows 2000 Server Resource Kit!))
you get lists of "cmd.exe", "cmd.exe", "cmd.exe",... with no way to
actually map them to any of your cmd shell windows.  IOW who is
this one's parent?  If I lock one up, like I sometimes do, I want to
just 'kill' it and move on.  But, I don't have a clue which is which!
Now I do!!  Run 'tty -v' in each cmd shell terminal window to get the
pid of each one.  Then when you do 'ps', or better, 'pgrep -v cmd.exe'
you can discern which is yours from the list.  This kind of mapping
makes life a lot easier for command-line programmers.  UN*X does
this by its very nature.  Windows lives in a GUI world that hides
the underlying reality from non-programmer users.  But that very
fact makes it so difficult for programmer types, especially old
command-line hands like me, to get along because oft-times the
abstraction gets in the way.

What other stuff should the package/book contain?
The package/book should contain meaningful commonly used examples.
Here are some examples of what we mean ...
   cpdir . c:                             (copy directory tree)
   grep -v "^@rem" script.cmd | wc -l     (count comment lines)
   grep -v "^#" script.ksh | wc -l        (count comment lines)
   grep -n "^.$" cat.cmd                  (squeeze out blank lines)
   rm -rf foodir                          (remove directory tree)
   tr -s [:space:] foobar.txt             (squeeze out spaces)
   tr -d [\r] messydos.txt                (delete carriage returns)
   pgrep -v cmd.exe                       (list PIDs of all CMDs)
   tty -v                                 (list PID of this CMD)

Our biggest gripe about other computer How-To books is that what
they show as examples are rarely useful to us in the real world.
And, often they depend on some quirky toolkit or another .dll or
environment or GUI that make it difficult to separate out just what
component we might use.  We want to particularly focus on providing
real world examples of how these tools are useful.

The package/book should discuss, hopefully, some of the many things
UN*X geeks really, really, really don't like about Windows ...

1) spaces in filename paths break 'find | xargs' (called: "space challenged") 
2) carat instead of backslash as the Escape char on the CMD command line
3) backward slashes instead of forward slashes as the file.separator
4) semi-colons instead of colons as the path.separator
5) \r\n (crlf) as the Text file type default EOLN translation
6) a wussy shell (CMD) with lottsa quirks, weirdnesses, and annoyances like
7) only %1 - %9 amount of argv[9] options to pass into .cmd, .bat scripts
8) drive letters A-Z: limit to mount points instead of a real mount command
9) the lack of an easy to use 'ln' command with hard and soft symbolic links 
10) no discussion of the atomicity of commands like move, ren(ame), &c.
11) WindowsCE/PocketPC mounts flash memory on mount points with spaces in them!
12) PocketCMD cannot pass filenamepaths with spaces in them down in argv %1 %2 
13) executability based on filename .ext(ensions) (with MIME-type mappings)
14) case insensitivity, copy a lowercase filename from a flashdrive UPCASES it 
15) re-uses process Ids (or pids) as soon as they are freed up - we HATE this!!
16) process table dumps do not show the whole command (ps -eaf) just "java.exe"

Installation and Configuration

Soapbox Tirade -------------- Speaking of what we don't like about Windows, here are some issues we don't like that pertain to Installation and Configuration, just to set the stage for discussing both of these important initial items ... (1) Blanks or spaces in pathnames! "C:\Program Files\", huh? Why not just "c:\programs", or even shorter yet "c:\prog"? Or, my favourite "c:\proggies" (it rhymes with "froggies"!)? (2) Microsoft or Microsoft Press or whomever (marketing?) keeps changing the default installation locations for the Resource Kit tools. Why can't they just pick one pathname and stick with it, huh? (3) Long pathnames "Windows Resource Kit", huh? Why? (4) No easy and consistent way to find out where the Resource Kit and Support Tools packages are installed. Registry pointers if used are probably changed just as often as the actual default disc locations. (5) Security through obfuscation does not work - so why be so obtuse? (6) Folks who still know how to "type" and like to use command-lines really hate long pathnames! When we encountered the Windows 2003 Server Resource Kit Tools installation and found that the old default installation location "C:\Program Files\Resource Kit\" which usually resolved 99 out of 100 times to "C:\progra~1\resour~1\" was now changed to "C:\Program Files\Windows Resource Kit\Tools\" which since there are umpteen packages that begin with "Windows" leaves one with no clue as to exactly what the short ('dir /x') name will resolve to, we threw up our hands and said "enough is enough already"! So, here's the deal. The onus is now on you the user to tell us where the heck you decided to install the Resource Kit and the Support Tools (assuming that you want to be able to use our commands that need to use some of their commands as back-ends that is). We are going to be nice enough to give you some advice, prejudiced though it may be from our perspective, still, we are going to give it to you never-the-less. We will give you some other options in case you already have them installed, too. Before we deal with the installation of HulaBats, we need to to deal with the installation of the Resource Kit and the Support Tools packages. Then we will look at HulaBats, itself. You might ask: "Why do they care as long as they are on the PATH?" Well, good question. Here is our answer: There are a couple of problems with that: (1) there might be other commands in other folders on your PATH with the same names that are resolved to first but which may not take input parameters or output results in the same formats which would mess up what HulaBats commands expect, and (2) it makes it harder to test for existence (if exist) and to control error messages (we can write them instead of whatever randomly happens if the needed lower level command is not found or arguments are not in the same order as expected, &c) to make things cleaner all around. That being said, there may be one or two HulaBats commands that do actually just blindly call out for the back-end hoping that it is on the PATH as a last resort or fallback position, but, in general, we try to avoid doing so. Resource Kit Installation and Configuration for HulaBats Use ------------------------------------------------------------ Unfortunately, you may have to purchase the Resource Kit from Microsoft Press to get it. Although, we have seen links on the web for downloading the old Windows 2000 Resource Kit for free. You can usually run these older executables on the newer platforms just fine (e.g., linkd.exe) if you cannot afford to get the newer one for your platform. Some of the commands we use from it may be found in Microsoft Visual Studio .NET 2003 if you own that particular compiler suite. See the section below which describes what files to grab from this package to copy to your c:\msreskit directory to fake a partial Resource Kit installation. If you have a choice where to install it, then please choose c:\msreskit and be done with it. If you have the Resource Kit installed already, you have two options * make a symbolic directory link (what uSoft calls a JUNCTION) using the 'linkd.exe' command to c:\msreskit The HulaBats script 'ln.cmd' has a '-d' option that does this but there is a chicken-or-the-egg problem in that it needs to find the Resource Kit linkd.exe to perform the feat. So, it is just easier, initially, to use 'linkd.exe' directly until 'ln.cmd' can find its location. * set a global environment variable to point to the directory where it is currently installed. E.g., MSRESKIT=c:\progra~1\resour~1 Three ways come to mind on how to do this depending on your preference - use the GUI under System Properties->Environment Variables (again, they keep changing where the GUIs are so you figure it out!). You will probably want to reboot after you set this. - use the 'setx.exe' command that usually comes with either the Resource Kit or with Windows itself as a native command (and you can figure out the syntax for using it yourself). This command 'setx.exe' is a perfect example of one that has been moved over the years. Under Windows 2000 Server it came with the Resource Kit and was usually found at c:\progra~1\resour~1\setx.exe but under Windows 2003 Server R2 it has become a native command that lives at %SystemRoot%\system32\setx.exe You will probably want to reboot after you set this. - edit the login.cmd script under the HulaBats bin directory and source it in or run it IOW from your cmd.exe command line before you execute any other HulaBats commands under that shell terminal. An example would be set MSRESKIT=c:\progra~1\resour~1 but your mileage may vary depending on where it is actually installed (use 'dir /x' to figure out the short names to use). This last one is our usual modus operandi BTW. Support Tools Installation and Configuration for HulaBats Use ------------------------------------------------------------- The Support Tools come on the media for the operating system under the "SUPPORT\TOOLS" directory. It can be installed by running its setup.exe or .msi file either in the file explorer or on a cmd.exe command line. Here you have choices similar to those above for the Resource Kit, except that the installation location and environ variable name is different. If you have a choice where to install it, then please choose c:\suptools and be done with it. If you have the Support Tools installed already, you have two options * make a symbolic directory link (what uSoft calls a JUNCTION) using the 'linkd.exe' command to c:\suptools The HulaBats script 'ln.cmd' has a '-d' option that does this but there is a chicken-or-the-egg problem in that it needs to find the Resource Kit 'linkd.exe' to perform the feat. So, it may just be easier, initially, to use 'linkd.exe' directly until 'ln.cmd' can find its location. If you already have MSRESKIT set in the environ or have the Resource Kit installed under c:\msreskit or have a JUNCTION made pointing to it as described above then you can use the HulaBats 'ln.cmd' command to perform this deed. E.g., ln -d c:\progra~1\suppor~1 c:\suptools * set a global environment variable to point to the directory where it is currently installed. E.g., SUPTOOLS=c:\progra~1\suppor~1 Three ways come to mind on how to do this depending on your preference - use the GUI under System Properties->Environment Variables (again, they keep changing where the GUIs are so you figure it out!). You will probably want to reboot after you set this. - use the 'setx.exe' command that usually comes with either the Resource Kit or with Windows itself as a native command (and you can figure out the syntax for using it yourself). Again, you will probably want to reboot after you set this. - edit the login.cmd script under the HulaBats bin directory and source it in or run it IOW from your cmd.exe command line before you execute any other HulaBats commands under that shell terminal. An example would be set SUPTOOLS=c:\progra~1\suppor~1 but your mileage may vary depending on where it is actually installed (use 'dir /x' to figure out the short names to use). This last one is our usual modus operandi BTW. Back-ends Used From The Resource Kit or Support Tools ----------------------------------------------------- Here is a (probably partial) listing of back-end programs used by HulaBats commands that historically were found in either the Resource Kit or the Support Tools (but which may be found under %SystemRoot\system32 in newer platforms or may have been renamed to something else or may even be OBE today). depends.exe - ldd.cmd uses this diruse.exe - du.cmd uses this linkd.exe - ln.cmd uses this oh.exe - fuser.cmd uses this (on Vista => openfile.exe) ptree.exe - ps.cmd may use this (but prefers tasklist.exe) pmon.exe - top.cmd uses this robocopy.exe - cpdir.cmd uses this sleep.exe - sleep.cmd may use this uptime.exe - w.cmd uses this windiff.exe - diff.cmd uses this for the -g option where.exe - find.cmd uses this whoami.exe - w.cmd uses this Here are other tools of special interest that may be used in the future... setx.exe - env.cmd may use this someday to set global environ vars timeit.exe - possible time.cmd may use this someday xcacls.exe - possible set/getfacl.cmds (like in Cygwin) may use this Alternate Locations Of Useful Programs -------------------------------------- Some of the back-ends used by HulaBats commands that usually come with the Resource Kit may also be found in Microsoft Visual Studio .NET 2003 if you own that compiler suite. This section describes what files to grab from this compiler suite that you can copy to your "c:\msreskit" directory to fake a partial Resource Kit installation. First, here is the location of the files in the compiler package C:\progra~1\"Microsoft Visual Studio .NET 2003"\Common7\Tools\Bin\ and here are the files you need to grab (assuming that you have done a 'cd' command to go to the above location) mkdir c:\msreskit copy Depends.* c:\msreskit copy Where.Exe c:\msreskit copy WinDiff.* c:\msreskit Another, useful tool (from DCE which we have our own version of, too) can also be found there copy Uuidgen.Exe c:\msreskit and it can be used to generate unique GUID keys and file names. How HulaBats Scripts Find The Resource Kit and Support Tools -------------------------------------------------------------- First, they check if "c:\msreskit" and "c:\suptools" exist, and look for the program they need under those locations. Second, they see if MSRESKIT and SUPTOOLS are defined, and look for the program they need under those locations. Third, they look for them under "%SystemRoot%\system32". In most cases an error will occur if none of the above work out. In some cases though, as we described above, the script might just act like it is on the PATH and run it blindly not giving a damn about the input parameters or output format compatibility, leaving the error to just happen if the command being called is not found on the PATH. How HulaBats Scripts Find Their Brother and Sister Commands ----------------------------------------------------------- Recently, we have begun to use code (like this code snippet lifted from ascii.cmd) in many of the HulaBats .cmd scripts set HULABIN=%~dps0 ^^^^^^ if defined HULADBUG @echo HULABIN=%HULABIN% set ASCIITXT=%HULABIN%ascii.txt ^^^^^^^^^^^^^^^^^^ when they need to find data files or other scripts in the collection. What the "%~dps0" does is expand to the full shortname path to the currently running script itself (the full path to argv[0] IOW). (And they used to always complain about how cryptic C and UN*X were!) Note that HULABIN ends up with a terminating '\' (backslash) so no extra backslash is needed between the %HULABIN% macro expansion and the rest of the file path value. We haven't yet fully decided how to point the manual scripts (like man.cmd, apropos.cmd, whatis.cmd, mkwhatis.cmd) to the man pages. We are leaning towards using HULAHOME with a HULAMANS override but we may fallback to the trick above and base the man pages relative to where the .cmds themselves are located. Here are some scratch notes we made earlier on about this subject... # We may need to add our root tree or bin dir to the PATH # PATH=%HULAHOME%\bin;%path% # We may need to set some environ variables to find stuff # Here are some possibilities... # HULAHOME=HulaBats installation tree root> # HULABATS= # HULAMANS= # MSRESKIT= # SUPTOOLS= # PERLHOME= # JSDKHOME= Here are two scripts that we use to configure our working environ: login.cmd - set up HulaBats working environ In this script is where any or all of the above environ variables can be set. mslogin.cmd - set up supplemental cl.exe compiler environ (like for building getppid.exe,...) Or, like some of our recent scripts that depend on Perl we could insist that the user add the directories where things we need reside to the global, system, machine environment PATH and be done with it. Then if they do not work - it is their fault to correct. We still may need HULAHOME to be able to find our data files relative to our scripts and executables (ie. man pages). But, that too can be added to the global, system, machine environs. Futuristically Speaking ---------------------- We may be able to use "assoc" and "ftype" to find out where things are installed? See the contents of the "file.cmd". This is a MIME-type style mapping which Windows XP uses to know how to "run" files (ie., .pl maps to a perl.exe somewhere). Use them like this to find where a Perl is ... F:\home\cal\bin>assoc .pl .pl=pl_auto_file F:\home\cal\bin>ftype pl_auto_file pl_auto_file=C:\h\coe\comp\perl\bin\perl.exe "%1" %*

Core .cmd commands with no depends other than native Windows apps

These are the core HulaBats commands that have no real dependencies on external applications other than those that come native with Windows itself... #----------------------------------------------------------- apropos.cmd - See Also: man.cmd, whatis.cmd, mkwhatis.cmd ascii.cmd - uses own location to find its ascii.txt data file basename.cmd - similar to UN*X 'basename' command cat.cmd - takes /dev/null, '-' filter option, 9 max file args clear.cmd - simple wrapper around 'cls' cp.cmd - wrapper around 'copy' cpdir.cmd - wrapper around 'xcopy.exe' diff.cmd - abbreviatable, line-numberable wrapper around 'fc.exe' dirname.cmd - similar to UN*X 'dirname' command du2.cmd - does not calculate sizes just lists dirs (See lsd, du) env.cmd - simple wrapper around 'set' with no args expand.cmd - expands tabs to spaces, nice filter tool (I hate tabs!) expr.cmd - basic calc subset, no parens or nested expressions yet false.cmd - similar to UN*X 'false' command file.cmd - 'assoc', 'ftype' provide MIME-type style mappings free.cmd - works on Windows XP/2k3srv/Vista (needs 'fsutil') fsize.cmd - displays the size of the specified file in bytes grep.cmd - simple subset works, uses 'findstr' and 'find' ifconfig.cmd - in ok shape read-only-wise, does not configure yet! kill.cmd - works on Windows XP/2k3srv/Vista (needs 'taskkill') l1.cmd - an 'ls -1' single column alias la.cmd - an 'ls -a' list all alias lc.cmd - an 'ls -c' list columnar alias less.cmd - simple (like 'more' and 'pg' does not go backwards) ll.cmd - an 'ls -l' long list alias logname.cmd - BSD UN*X, Cygwin equivalent: just echoes %USERNAME% ls_.cmd - basic 'ls' command if no better 'ls.exe' is available ltR.cmd - an 'ls -ltR' alias (newest files last) man.cmd - See: apropos.cmd, whatis.cmd, mkwhatis.cmd mkwhatis.cmd - See: man.cmd, apropos.cmd, whatis.cmd mv.cmd - simple wrapper around 'move' pg.cmd - simple wrapper around 'more' printenv.cmd - in great shape, can specify a particular environ var ps.cmd - uses 'tasklist' which is native on XP/2k3srv/Vista pwd.cmd - simple wrapper around 'cd' rand.cmd - simple one-liner, just 'echo %RANDOM%' rm.cmd - in ok shape, -i and -rf supported setfilec.{cmd,reg} - turns on CMD filename completion in the registry su.cmd - 'runas' wrapper (hack it if you change Administrator) tail.cmd - needs 'wc.cmd', does "-n #" and "-#" now, but no -f! touch.cmd - similar to UN*X 'touch' command true.cmd - similar to UN*X 'true' command uname.cmd - several options work ok fine now w/o MsResKit wall.cmd - works only if 'net' command works, needs more testing wc.cmd - line and byte/char counts work, word count doesn't what.cmd - needs some work, has leading @rem crapola in output whatis.cmd - See: man.cmd, apropos.cmd, mkwhatis.cmd which.cmd - in good shape (must specify .ext(ension) though) yes.cmd - in good shape (needs a '-t 5' delay-timer option) #-----------------------------------------------------------

.cmd commands with depends on HulaBats' own .exe's or scripts

One measure of how useful a particular piece of software is - is if it can build on itself, use pieces of itself, to create new and ever more useful components. Well, in that regard, this section lists tools that use other parts of the package to do meaningful work... #----------------------------------------------------------- cmp.cmd - wc.cmd head.cmd - ed.exe + mktmpnam.exe ln.cmd - link.exe + unlink.exe (+ linkd.exe from MsResKit) prnt.cmd - unix2dos.exe + mktmpname.exe + basename.exe + tolower.exe + fold.exe tail.cmd - wc.cmd tty.cmd - calls 'getppid.exe' (sort of similar to BSD UN*X, Cygwin 'tty') #-----------------------------------------------------------

.cmd commands with depends such as MsResKit, SupTools, Java, or Perl

Somehow those with depends need to detect whether they are present or not and if not just echo something about the user needing to install and/or configure for them to be able to work correctly. #----------------------------------------------------------- cmp.cmd - needs native 'comp.exe' and our 'wc.cmd' diff.cmd - -g GUI mode needs Support Tools 'windiff.exe' domainname.cmd + needs Perl with LibWin32 (see domainname.exe) dos2unx.cmd - needs Perl on your PATH du.cmd - needs 'diruse.exe' (See Also: du2.cmd, lsd.cmd) find.cmd - 'find' subset that uses the MsResKit where.exe fuser.cmd - uses oh.exe from MsResKit (SysInternals handle) (oh.exe is now openfile.exe on Windows Vista which broke this script - so it needs fixing!) head.cmd - filter, needs our 'ed.exe' and 'mktmpnam.exe' hostname.cmd + - needs Perl with LibWin32 ldd.cmd - needs 'depends' from MsResKit or Support Tools ln.cmd + link.exe + unlink.exe + linkd.exe - needs 'linkd.exe' from MsResKit lsd.cmd - list directories (See Also: du.cmd, du2.cmd) modinfo.cmd - needs 'drivers.exe' on 2k or 'fsutil' on XP mount.cmd + voltab.cmd + strrtrim.exe + printf.exe + findstr.exe + linkd.exe + subst.exe - virtual mount capabilities, needs linkd.exe nospace.cmd + - removes spaces from path file names, uses Perl pgrep.cmd - prefers 'tasklist' over the MsResKit 'ptree' ps.cmd - prefers 'tasklist' over 'pulist' or 'tlist.exe' pwd_pl.bat + - needs Perl with LibWin32 reboot.cmd + shutdown.exe - needs 'shutdown.exe' from MsResKit sed.cmd - needs Perl on your PATH, more work/testing! shutdown.cmd + shutdown.exe - needs 'shutdown.exe' from MsResKit or Vista sleep.cmd + - needs Perl with LibWin32 tlist.cmd - needs 'tasklist' (use when tlist.exe fails) top.cmd - uses 'pmon.exe' from MsResKit or Support Tools tr.cmd - very nice but uses Perl "tr/ / /cds" commands umount.cmd + findstr.exe + linkd.exe + subst.exe - unmount, needs linkd.exe unx2dos.cmd - needs Perl on your PATH unzip.cmd - needs Java 'jar.exe' or 'pkzip25.exe' voltab.cmd + shuffle.exe + findstr.exe + mountvol.exe - falls back to perl.exe w.cmd - needs MsResKit 'uptime.exe/whois.exe' where.cmd - needs MsResKit (or Vista native) 'where.exe' whoami.cmd + - needs Perl with LibWin32 whois.cmd + - needs Perl with LibWin32 zip.cmd - needs Java 'jar.exe' or 'pkzip25.exe' #-----------------------------------------------------------

.cmd commands that can act like true UN*X filters

Somewhere along the way it hit us that the Windows native '' command could be used as a silent filter to input data from stdin. If the data stream can be analyzed, and processed without an intermediate temporary file stage that is preferred because it is much faster and much more elegant. Otherwise, once the inbound data is redirected to a temporary file it can be post-processed and then the final product written on stdout. But then the temporary file must be removed during a final cleanup operation which is a time waster. Other Windows native commands that act like the 'more' filter although in some cases not as cleanly are: findstr.exe, find.exe Accordingly, we have been making an effort to add true filter capabilities to our scripts. Filters can take their standard input in one of two ways. The first way is what is called a pipe or pipeline as indicated by the pipe '|' symbol immediately before the filter command as in this example: cat foo.txt | head.cmd The second way is what is called a redirection of stdin as indicated by the '<' standard input redirector symbol immediately following the filter command (and its optional switches) as in this example: tail.cmd -n 5 < foo.txt The key here is that the data is coming in as an input stream without a known filename instead of by specifying a known filename that then must be opened and read for input. Sometimes it is a disadvantage to not know the filename that is the source of the incoming data. But, at other times it does not really matter at all. Pipelines are part of what UN*X programmers and power users know to be at the core of its power. You can string several commands and filters together to do many amazing things. What follows then is a list of those commands which have this filter capability to date. As we add filter mode to other .cmd scripts they will be added to this list ... #----------------------------------------------------------- cat.cmd - uses to read stdin expand.cmd - uses to read stdin head.cmd - uses to read stdin grep.cmd - uses findstr.exe or find.exe to read stdin tail.cmd - uses to read stdin what.cmd - uses to read stdin in a for loop #-----------------------------------------------------------

CMD Scripting Gems

In this chapter we will attempt to expose some kewl things that you can do in CMD scripts - some are vaguely similar to UN*X script coding. Also, covered will be some strangeoid annoyances that we have figured out work-arounds for along the way. The format is a Q/A format here. Q: Can we make a .cmd script act like a real UN*X filter? A: Yes. Here is what seems to work for me... First, for some background, read the section in this document titled: ".cmd commands that can act like true UN*X filters" if you have not done so already for more details on programming filters. If you are reading this document top down you should have already read it. Here is a code snippet from the HulaBats 'tail.cmd' script that shows how to setup the read from stdin that is being fed from a pipe ... :PipeTail @rem If no args at all are specified we are reading from a pipeline like: @rem grep char foo.c | tail @rem To make it work we have to write stdin to a tmp file using more>TEMPNAME for /F "usebackq tokens=1" %%I in (`mktmpnam tail`) do set TEMPNAME=%%I %SystemRoot%\system32\ /S>%TEMPNAME% ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Here then is the magic - use a command like '' that is a filter already setup to read from its stdin. You can pipe it to a tmp file like we had to do here in 'tail.cmd'. Or you can post-process it in an internal pipeline or as we show below you can even pipe data into a CMD 'for' loop that is reading from ''. There are other Windows native applications that are also filters like 'findstr.exe' and 'find.exe' which can be used instead of '' should you need or want to. Q: Can we pipe things inside a CMD loop construct? A: Yes. I finally discovered how to do it one day by looking at someone elses code. The trick is to use '^' (carat or hat) symbol(s) just before the '|' pipe symbol(s) to escape them like this... for /F "usebackq tokens=1* delims=" %%I in (`type foo ^| grep bar`) ... Q: Can we pipe things into a CMD loop construct? A: Yes. Here is what seems to work for me... Note: in the following code snippets we use a back-slash ('\') at the end of each line where we split up code that actually belongs all on one line. This is similar to the way you break up long #include macros in C and C++ code. We also indent the continuation code to make it sort of understandable what block it corresponds to. If you copy & paste or type in the code examples by hand be sure to remove the back-slashes and rejoin all the code together on a single long, long line. Simple example first, a two-stage pipeline: @echo off @rem "@(#)forloop.cmd - can we read stdin in a for loop in a cmd script?" echo bar | for /F "usebackq tokens=1* delims=" %%I in (`more`) \ do @echo off& echo %%I food Here is a more complicated code snippet from the HulaBats "what.cmd" script, a three-stage pipeline: %SystemRoot%\system32\findstr.exe /I /R /C:"^@rem" %1 \ | %SystemRoot%\system32\findstr.exe /R /C:"@(#)" \ | for /F "usebackq tokens=1* delims= " %%I in (`more`) \ do @echo off& echo %%J ^^^^^^^^^^^^^ The main gotcha seems to be to use "@echo off&" as the first thing that happens after the "do" in the "for" loop when you are running it in a pipeline just as you would make it the first line in your .cmd scripts. I took that to mean it was, basically, forking a new shell to run that part of the code. Please correct me if I am wrong here, somebody. The trick is to use the Windows native "" command as a filter to read from stdin. What I really wanted to do was use the "for" loop "file-set" syntax in a simpler loop like this to read from the stdin stream: echo foo | for %%I in (stdin) do echo %%I bar or better yet just be able to use a minus symbol to specify stdin like the UN*X 'tar' command does amongst others: echo foo | for %%I in (-) do echo %%I bar Unfortunately, Windows CMD is just not that sophisticated. So, "" suffices because it goes into filter mode and ingests stdin when there are no args and writes the results on stdout just like what we want to happen. In our "for" loop above stdout from "more" is being processed by the "for" statement and the fields are chopped up as you specify in the "tokens=..." value and finally output in the "do" section of the "for" statement using "echo". Note that the above use of the "for" loop is similar to how a UN*X script writer would use "cut -d' ' -f2" or "awk '{print $2}'" to print out a particular field at the end of a pipeline following a couple of "grep" calls. The ugly "for" loop syntax is not nearly as clean and as easy to remember off the top of your head as the "cut" syntax or even the "awk" overkill, but that is just a way to pick out particular fields with CMD. Q: How can we get rid of that annoying extra blank output line that appears after we echo the results to stdout in a .cmd script? A: This one I stumbled upon purely by coincidence. Here is what works for me ... @echo off setlocal @rem Do anything you want between "setlocal" and the ":EOFrame" label @rem and have all your goto statements jump to ":EOFrame" not ":EOF". echo Hello World& goto EOFrame @rem Now the last three lines of the .cmd script file... :EOFrame endlocal :EOF

.exe commands from our own, or BSD UN*X, or other "free" sources

One of our goals was to have as few .exe commands as possible. However, now and again we need to create a customized utility. The main idea was to have minimalistic .cmd scripts that can get the user up and running without compilers, or wrappers around freely available toolkits like the Java SDK or the MsResKit. These just flesh things out a bit. Grep and the link stuff are real nice, same with tail and head and sed ... Sed is probably the most important one of all of these! Some things you just cannot do with Windows commands or add-ons such as our 'getppid.exe', 'mktmpnam.exe', and 'strrtrim.exe' executables!! .exe commands require a ("free"?) compiler to build the .exe files. Many of us won't find that a big limitation. But, others, will. Here is our current list of .exe programs we find useful... #----------------------------------------------------------- arc.exe + arc src codes - arc521 banner.exe + banner.c - large bold banners stand out (like for motd) beep.exe + beep.cs - one of the few .NET compiled commands so far becho.exe + echo.c - a BSD UN*X style 'echo' command cal.exe + cal.c - your basic calendar command cat.exe + cat.c - type file to stdout or redirect elsewhere comm.exe + comm.c - compare and contrast two files cp.exe + cpbourn.c - original simple Bourne 'cp' command cut.exe + cut.cpp - needs to become a filter! date.exe + getctime.cpp - READONLY equiv of UN*X style 'date' command domainname.exe + domainname.cs - one of the few .NET compiled commands so far ed.exe + ed.c - the old ed editor, very useful, see head.cmd fold.exe + fold.cpp - BSD UN*X version (prnt.cmd uses this) getppid.exe + getppid.c - provides _getpid(), _getppid() via Win32 getlogin.exe + getlogin.c - getlogin(), does logname.cmd equivalent grep.exe + grep.cpp - better than grep.cmd based on findstr & find hd.exe + hd.cpp - hex dump is better than an octal dump (od) head.exe + head.cpp - BSD UN*X style 'head', cleaner than head.cmd hostname.exe + hostname.cpp - don't really need this since Windows has it hostname.exe + hostname.cs - one of the few .NET compiled commands so far link.exe + link.cpp - hard link files mktmpnam.exe + mktmpnam.cpp - makes a uniq TMPDIR filename (see prnt.cmd) paste2.exe + paste2.c - paste together side by side pg.exe + pg.c - another basic PAGER printf.exe + printf.c - C printf() in CMD scripts or on cmd-line readline.exe + readline.cpp - read a line of input (use set /P if you can) rev.exe + rev.c - reverses its input rm.exe + rm.cpp - remove file(s) sed.exe + sed.cpp - an old GNU sed hacked by me (GPL so bury it ASAP?) shuffle.exe + shuffle.c - shuffle text files like a deck of cards sleep.exe + sleep.c - take a nap strings.exe + strings.cpp - see strings.cmd Borland tdump wrapper, too strrtrim.exe + strrtrim.c - trims RHE of string arg, returns strlen tail.exe + tail.c - need the .exe to do 'tail -f' and +1 offsets techo.exe + techo.cpp - "tee echo" outputs to two places at once tee.exe + tee.cpp - pipe output through tee to two places at once test.exe + test.cpp - BSD UN*X style 'test' command tolower.exe + tolower.cpp - downcases its argv1 argument (see prnt.cmd) toupper.exe + toupper.cpp - upcases its argv1 argument tr.exe + tr.c - we use tolower or toupper in CMD 'for' loops uniq.exe + uniq.c - useful for 'sort | uniq' pipelines unix2dos.exe + unix2dos.c - need dos2unix to go the other way (see prnt.cmd) unlink.exe + unlink.c - unlink files unshar.exe + unshar.c - unravel a UN*X 'sh' shar archive vi(m).exe + help/conf files - some "free" version of the 'vi' editor what.exe + what.c - from SCCS, displays "what" strings which.exe + which.c - our old MS-DOS version (see which.cmd) xxd.exe + xxd.c - (Bill Joy's?) Tahoe BSD UN*X tool xstr.exe + xstr.c - (Bill Joy's?) Tahoe BSD UN*X tool yes.exe + yes.c - port from BSD UN*X (see yes.cmd) #-----------------------------------------------------------

Perforce (p4) RCS work-alike wrappers and tools

We like RCS. We are familiar with its simple commands. CVS is ok, too. But, when we were forced to use Perforce at work - well, needless to say, we weren't very happy for a while until we figured out how to do RCS-style command line equivalents. Here is our collection that gets us by today ... #----------------------------------------------------------- ci.exe + ci.cpp - checks code into the repository co.cmd - checks code out of the repository rcs.cmd - initially registers a new file into the repository rlock.cmd - checks if a file is currently locked #----------------------------------------------------------- Note: if you need a basic MS-DOS port of RCS I have done it. Probably can round up the source code somewhere for it to. Huhm, I might be interested in that myself for use here, too, come to think of it!

Miscellaneous Tools

A list of some miscellaneous tools worth mentioning... #----------------------------------------------------------- aliases.cmd - uses 'doskey' to setup command line aliases cc.cmd - Compile C (UN*X cc style) using the SDK compiler ccs.cmd - Compile C Sharp (cc style) using .NET Framework cjs.cmd - Compile J Sharp (cc style) using .NET Framework downcase.exe + downcase.cpp - chcase equiv? needs an upcase? use tr.cmd? This downcases all files in a directory? See Also: tolower.exe, toupper.exe they just change cases of their string args. bindump.exe + bindump.c - a binary dumper (like 'hd'?) deltree.cmd - missing MS-DOS 6.22 command (rm -rf equiv) older.exe + older.c - from K&R C book or the K&P book or the web? Found it on SysAdmin cdrom, provides the missing find -older option (the opposite of find -newer). prnt.cmd - wrapper around 'notepad', v2.0+ depends on: 'unix2dos', 'mktmpname', 'basename', 'tolower' and 'fold'. Used instead of 'lp/lpr' commands. uuidgen.exe + uuidgen.cpp - hacked out of "free" DCE code, generates GUIDs. I recently found one like this in Visual Studio. #-----------------------------------------------------------

Utilities that work with the "free" Borland C++ compiler utilities

Recently upgraded, the following .cmd scripts now depend on our BSD 'tail' port as well as the tdump.exe from the Borland "free" 5.5 C++ compiler suite. Actually, we just found out that the Windows 2003 Resource Kit includes a tail.exe that has the -f option equivalent so we can reimplement this for that platform w/o providing our own tail.exe if need be. #----------------------------------------------------------- nm.cmd - dumps details about .exe's, .obj's and .dll's nmgrep.cmd - 'nm ... | grep ...' equivalent in one simple command strgrep.cmd - 'strings | grep ...' equivalent in one simple command strings.cmd - a UN*X 'strings' command emulation #-----------------------------------------------------------

ccbsdlib - C/C++ library that builds with "free" compilers

This is our (cc=Cal Crowley's) BSD compatible library for compiling C/C++ code on Windows that contains BSD UN*X style code. This stuff is kewl if you are a C/C++ programmer, otherwise, you will no doubt want to skip it. #----------------------------------------------------------- flock() (& friends) - file locking stuff getppid() - get parent process id strcasecmp(), strncasecmp(),... - string stuff like these opendir(), readdir() (& friends)- directory reading routines #-----------------------------------------------------------

So what is Window's missing natively (besides a brain, hah!)?

Other Misc UN*X commands #----------------------------------------------------------- dirs - CMD has pushd and popd but no dirs, weird! chgrp - see our script (xxx=w32,cyg) chmod - see our script (xxx=w32,cyg) chown - see our script (xxx=w32,cyg) chsh - change your default login shell logger - a Solaris /usr/ucb/logger or BSD UN*X equivalent nice - run a command at a lower priority level sane - we used to be able to use the mode command for this stty - we used to be able to use the mode command for this sync - you can get this one from though #----------------------------------------------------------- Editors #----------------------------------------------------------- emacs - Richard Stallman's GNU Emacs editing environment microemacs - Dave Conroy's public domain MicroEmacs text editor with source and executables for DOS16, DOS32, Win32 and even Linux. ( jove - Jonathan (Paine)'s Own Version of Emacs vi(m) - our favourite editor, get vim at "" #----------------------------------------------------------- Shells (beyond CMD's limits) (vs. GUI shells like Explorer) #----------------------------------------------------------- ash - ash is in Cygwin, SFU/SUA, and other UN*X-like environs csh - tcsh is in Cygwin, SFU/SUA, and other UN*X-like environs bash - bash is in Cygwin, SFU/SUA, and other UN*X-like environs ksh - the real Dave Korn ksh is in UWIN pdksh - pdksh is in Cygwin, SFU/SUA(?), and other UN*X-like environs perl - perl is in Cygwin, and downloadable from ActiveState python - python is in Cygwin, and downloadable from ActiveState ruby - ruby can be found at "" sh - sh is in Cygwin, SFU/SUA, and other UN*X-like environs tcsh - tcsh is in Cygwin, SFU/SUA, and other UN*X-like environs zsh - zsh is in Cygwin, SFU/SUA, and other UN*X-like environs #----------------------------------------------------------- Mailers (missing common UN*X SMTP MUAs and MTAs such as...) #----------------------------------------------------------- elm - SMTP MUA exim - SMTP MTA fetchmail - POP3 mbox downloader mail(x) - SMTP MUA mutt - SMTP MUA postfix - Wietse Venema's mailer (alt.sendmail) pine - SMTP MUA sendmail - Eric Allman's SMTP MTA #-----------------------------------------------------------

UN*X-like commands Windows and CMD already have natively

CMD builtins #----------------------------------------------------------- cd mkdir popd pushd rmdir #----------------------------------------------------------- UN*X-like general utilities #----------------------------------------------------------- more pax (might be able to do a tar.cmd wrapper around this, and/or cpio.cmd?) sort #----------------------------------------------------------- TCP/IP utilities and services #----------------------------------------------------------- arp finger ftp hostname ipconfig (we wrap this with our i'f'config.cmd) lpq lpr nbtstat (is this a UN*X command though?) netstat nslookup ping rcp rexec route rsh telnet tftp tracert (we could wrap this with a traceroute.cmd) #----------------------------------------------------------- Optional UN*X-like "Features" ----------------------------- Under Windows Vista this is a list of the "Windows Features" that you can optionally install via "Control Panel"-> "Programs" ... "Installed Programs" -> "Turn on or off Windows features" Similar "features" should be available under earlier versions of Windows based on NT (2k/2ksrv/XP/2k3srv). [-] Internet Information Services (IIS) [-] FTP Publishing Service [ ] FTP Management Console [ ] FTP Server [+] Web Management Tools [+] World Wide Web Services Note: SMTP Services seems to be missing under the IIS pkg!?!? Which way did it go? [-] Print Services [x] LPD Print Service [x] LPR Port Monitor [ ] Ras IpRip (YTBD: this might be the RIP protocol (e.g., gated)?) [-] Services for NFS [ ] Administrative Tools [ ] Client for NFS [x] Simple TCPIP services (i.e. echo, daytime etc) [ ] SNMP feature [x] Telnet Client [x] Telnet Server [ ] TFTP Client Note: I added the Telnet Client and Telnet Server and it did not prompt me for the installation dvd. YMMV with the other features. When using Windows Vista Telnet Client to login to another Windows box running Cygwin's telnetd you may need to use the "-a" option or the login/password handshake may fail: C:\> telnet -a squally Password: This attempts to log you in on the target (squally) as the user you are currently on the source side (zephyr), but it does not allow you to specify a different user login. Configuring the Telnet Server on Windows Vista was a pain... Next I had to figure out how to launch the Service Control Manager GUI and set the Telnet Server to "autostart" and reboot. Then I still could not get past the Firewall so I had to open port 23 for telnet to have inbound access to the box. Finally, you have to add all your users (or at least yourself) to the TelnetClient group, which was not an intuitive thing to do BTW. I finally found that the easiest way to figure out how to do it was to go to Help and search for "TelnetClient group" followed by "Add TelnetClient group". I was amazed when I finally got it to work, and it worked as if I had a ~/.rhosts file with ogin/sword pairs in it and were using rlogin instead! If I was already the user 'winadmin' on hostA and telneted into hostB it put me right into a CMD shell prompt w/o prompting for the ogin/sword pair. But, what if I wanted to login as a different user to hostB, huh? Behind the scenes authentication must be taking place because I was already logged in on hostA as _that_ user and once that user is added to the TelnetClient group on hostB you are just good to go, it does save sending clear text passwords over the wire, but still, it makes me nervous to not be prompted for the usual ogin/sword pair, and like I just said above: what if I want to login as a different user? And, I know, I know, I should be using ssh instead but... this was with the new OS - Windows Vista - and there are no ssh's working yet because there is no Cygwin UN*X environs working yet on that platform - so going back to ftp and telnet was my only option. It just doesn't work/feel like UN*X during the setup phase, nor even at the ogin/sword hand- shake phase, and well, nor is CMD, bash either, for that matter. Still for an old UN*X hand, a CMD shell via Window's weird telnet is better than nothing to get you started using our HulaBats. Oh, and there was also some "best practices" advice about adding the 'chcp 1252' command to the "systemroot\system\login.cmd" file but that file I found was actually, %SystemRoot%\System32\login.cmd under Windows Vista. You might need to add this to support "English and Western European UN*X" for computers "running an internationalized version of UN*X". I have not yet determined if this includes Cygwin or not. To get an FTP Server running is even uglier than getting a Telnet Server up and running. You have to install/configure IIS first, and ???, then FTP Server. Because of the IIS wrapper there is a lot more work involved. To learn about all this search Help for "FTP services" which should lead you to topics like "Setting up FTP sites" (at least it did on Windows Vista). You may need to install all of IIS but only configure the subset you need to get the FTP Server up and running. I am kind of vague on this stuff because the Windows FTP and Telnet Server installation and configuration is such a nightmare that once I have Cygwin installed I usually just configure Cygwin and its inetd (e.g., inetd.conf) to launch and run its versions of these two servers instead of the Windows versions. However, since Cygwin is not released yet for Vista - you/I may have no choice in the matter depending on what you are up to.

Miscellaneous Topics

Color Terminals --------------- GUI: Upper left corner menu->Properties->Color tab-> (*) Screen Text R: 255 G: 255 B: 0 This is "light yellow" (or gold). Use this for all CMD shell foregrounds (fg) for fonts. Gold was the font or foreground color of the old HP command-line terminals. Studies have shown that this is the best combination (gold on black) for tired, old eyes. (*) Screen Text R: 0 G: 255 B: 0 This is "light green". Use this for all Cygwin bash (and rxvt) shell foregrounds (fg). Green was the font or foreground color of the old Wyse command-line terminals. Studies have shown that this is the 2nd best combination (green on black) for tired, old eyes. The "light green" color blends nicely with the ANSI default Cygwin prompt that uses plain "green" - which is a bit darker. (*) Screen Background R: 0 G: 0 B: 0 This is "black". Use this for all shell backgrounds (bg) with gold or green fonts (fg). Command-line: color /xy - sets bg and fg colors in CMD shell terminal windows: color /0e = "black" bg, "light yellow" (or gold) fg color /0a = "black" bg, "light green" fg

UN*X-like Alternatives You Can Get For Windows

We are reluctant to include this section because things change so fast. You can google the Internet for current information about these types of packages. We only add them so it gives us a soapbox to stand on so that we can relay our experiences and prejudices about some of them. No book about UN*X/Linux on Windows is complete without mentioning them. These are the biggies as we see them. This may be a gross over-simplification but it appears that in terms of full-blown UN*X work-alike systems for Windows there seem to be, currently, mainly four: Cygwin, UWin, SFU now SUA, and the various "MKS Toolkit for ..." (aka NuTCRACKER) products. The Hamilton C Shell and the various GnuWin32 products seem to be more specialized. #----------------------------------------------------- Cygwin - from RedHat, Inc. pros: Can access Win32 cuz it's built on top of it which allows you to get to things like gamer timers for faking nanosleep() while not interrupting the BSD UN*X setitimer() callbacks. Many things work in CMD shells if you add C:\cygwin\bin to PATH (ls!) although some things work only for one-liners. Includes X11R6 server (new: Xorg; old: XFree86). Has gcc or can use MinGW compiler for .exe's. Will work even if your security police remove the POSIX sub-system from Windows. Provides Redhat Linux compatibility for developers. cons: Loads a big DLL. GNU copyleft style license(s). Slower than SFU/SUA cuz its built on top of Win32. Cannot have more than one version active, IOW only one copy of the .dll can be loaded at a time - this causes integration headaches like when two different products have to go onto the same machine but each needs a different version of Cygwin to operate and may have a subset of Cygwin already included in their product. Had problems and did not work on Windows Vista, but I believe that new versions have fixes for it. Hamilton Csh - Hamilton C shell (Located in the Bellevue-Redmond-Kirkland triangle.) Does this work on Windows Vista? Got email out of the blue from the author, Nicole Hamilton, who has assured us it does work -- for both the Vista 32-bit and 64-bit versions -- and that it has been recently updated (as of my writing this 2009.08.06). Hopefully, it will work on Windows 7, as well? Ah, the times move on... MKS - Mortis Kern Systems, Inc. Did this used to be called MKS Trilogy? See Also: NutCracker 4 below NuTCRACKER - from DataFocus See Also: NutCracker 4 below NuTCRACKER 4 - now known as MKS Toolkit for Enterprise Developers Dunno much about these alternative products, anyone? From this site: it appears that there are several product offerings with different forms of the name "MKS Toolkit for ...". The above two products perhaps evolved into these? They support both 32-bit and 64-bit architectures. Do these products work on Windows Vista? Windows 7? pros: both MKS and the NuTCRACKER products have been around the block for quite some time. They have an X11R6 server product, too. cons: Costs you $$$. SFU/SUA - Interix (from Softway Systems), Interop, Microsoft pros: Add C:\SFU\common tools to PATH for CMD shells. v3.5.x is now free. You can use X11R6 server in Cygwin for free. Has gcc or can map cc to uSoft compilers. Faster than Cygwin cuz its built on top of HAL. It has its own POSIX sub-system. cons: Extra tools from Interop cost $$$. Hummingbird or other X11R6 Server cost $$$, but you can use the "free" Cygwin X server with it. Cannot or not easy to access Win32 like in Cygwin. Have had trouble using C:\SFU\common\ls.exe on Win2k3Srvr under JUNCTIONS from CMD shells. For ksh to be usable you have to disable beep.sys. Dunno if this works if POSIX is locked down because of DoD Security policies, but doubt it, so may not work if your security police remove or lock you out of all POSIX runtime executables. SFU 3.5.x does not work on Windows Vista. Keeps getting renamed so it is hard to track it and be loyal to the product (like you can with Cygwin or UWIN which haven't been renamed along the way) -- this also indicates some screwy Marketing department has too much "say" in it -- renaming also may cause future integration headaches if you have products with pathnames pointing to the locations of its files and directories and expect them to remain there. notes: SFU is renamed SUA and supposedly will be native on Windows Vista/Longhorn Server editions but not on the Ultimate or less functional versions. Actually, it turns out that only the core comes with them natively, but you have to use Add/ Remove Programs to add it as an extra Component. Then you still have to download/install the rest of it to get a usable, more complete installation. UWin - Dave Korn, AT&T Research, and WiPro from India pros: Has the very best ksh (thanx to Dave)! Has gcc or you can map cc to many other compilers. May have the purest AT&T UN*X IPC emulation? Site says most "of the UNIX API is implemented by the POSIX.DLL", but that programs "linked with POSIX.DLL run under the WIN32 subsystem instead of the POSIX subsystem, so programs can freely intermix UNIX and WIN32 library calls". cons: Costs you $$$. Loads a big POSIX.DLL dynamically. Dunno if this works if POSIX.DLL is locked down because of DoD Security policies, but doubt it, so may not work if your security police remove or lock you out of all POSIX runtime executables. Does this work on Windows Vista? Windows 7? GnuWin32 - GNU and the Open Source community pros: Works from CMD terminal shell command lines. Gnu's Not UN*X (does that mean it's better?). Free but with GNU copyleft style license(s). Very useful for providing UN*X tools that can be used during hands-off customized Windows installs. cons: GNU copyleft style license(s). Last time I checked it did not fit in with Vista. Have the Vista kinks been worked out yet? To me project(s?) is too scattered, unlike say Cygwin which is all in one location, a busy person has to read so many different things for clues as how best to proceed for an install and what exactly is needed. #-----------------------------------------------------

Free C/C++/C#/Java/J# Compilers you can get for Windows

Again, the big CAVEAT about anything based on the web. Things may not be found at the same place they were when we edited this section. So, YMMV, and Google and Yahoo are your friends... #----------------------------------------------------- A good starting point for searches for Free C/C++ Compilers is here: Borland's BCC55 OLD: LAST KNOWN LOCATION: - get the Version 5.5 Compiler and Turbo Debugger for the Windows Platform. - not the fastest, bestest resultant .exe's but we do find this to be the easiest to use to build source code that was originally written for different UN*X platforms. Also, you can build 'dmake' (needed to build 'Perl') with it, and you can build 'Perl' itself with it. - this works on Windows Vista BTW. gcc + MinGW in Cygwin - this did not work on Windows Vista last time I checked. - does this work on Windows 7? gcc in SFU/SUA - this may not work on Windows Vista, does it? - does this work on Windows 7? gcc in UWin - this may not work on Windows Vista, does it? - does this work on Windows 7? jdk1.[4,5,6].x_xx - from Sun Microsystem's JavaSoft division. - needed the 1.6.x.x early release or later for Windows Vista. - heard the 1.5.x.x series was eventually patched for Windows Vista. Microsoft's .NET Framework (C/C++/C#/J#) but, the last time we went there it redirected us to: You will also need the PlatformSDK which is freely downloadable for the include files like "windows.h". Microsoft's C/C++ Compilers in one of the free packages (C/C++) You may also need the PlatformSDK which is freely downloadable for the include files like "windows.h". MinGW standalone gcc - Has installation issues - kind of difficult to install. - Is this still being updated? -- cuz it did not work on Windows Vista the last time I checked. - We wonder if this works under Windows 7? Walter Bright's C/C++ Compiler (comes with D, too?) - Used to be Zortech C/C++, Symantec C++, &c &c &c - Does this work under Windows Vista? Windows 7? - Look at their DMDScript for a faster ECMA 262 v3 implementation (aka JavaScript, JScript). Watcom - We wonder if this works under Windows Vista? Windows 7? #-----------------------------------------------------

Free C/C++/Java Compilers for WindowsCE/PocketPC

Programming for the PocketPC is another world entirely. This section discusses some of the "free" or nearly so compilers/interpreters to assist you in that endeavor. #----------------------------------------------------- PocketGCC - this is the gcc that we use now - from Vitaliy Pronkin for the ARM/XScale processor (pgcc v1.5, gcc 3.2.2). Pros: nice cuz you can compile right on the PDA itself. Cons: a gcc.bat wrapper does not come with it. a newer gcc - also, from russia with love??? Pros: it has a gcc.bat wrapper, supposedly, but, ... Cons: dunno where to get it, cannot find it via Google. PersonalJava - but Sun no longer supports this, unfortunately Pros: free - if you can find it on the web somewhere. Cons: you have to compile .class files on a Solaris, Linux or Windows box and copy them to your PDA to build an app. Pre 1.2 Java (I use 1.1.8 on Solaris 8 to build our apps for it). No Swing support, only AWT. Sun dropped it, no longer supported. gcc cross-compiler for ARM from Debian Linux ??? Pros: you can compile on a pc instead of the pda. Cons: you have to compile on a pc instead of the pda. Microsoft eMbedded C/C++ compiler (some say this is free but we could not get the "free" one to work) Pros: has a studio type of IDE you may be familiar with. has emulators for different PDA platforms to test on. supports chipsets other than the ARM/Xscale Cons: have to install a lot of u$oft baggage for it to work. See Also: our manual build script tree and crt0 main() pre-processor workarounds. #-----------------------------------------------------

.bat commands and PocketCMD under WindowsCE/PocketPC

Another separate section in the book should be devoted to scripting .bat files and other useful tools for UN*X geeks hacking with PocketCMD. Like what PocketCMDs are out there anyway and where? What are their pros/cons? How do they compare to CMD? #----------------------------------------------------- cat.bat clear.bat cp.bat ls.bat mv.bat rm.bat pg.bat + pg.exe edit.bat + edit.class view.bat + view.class #----------------------------------------------------- NOTE: I finally gave up on PocketPC -- it is just too braindead. The fatal flaw is the limited battery life and its propensity for wiping out everything that you have installed when it reloads the base operating system from backup ROM when the battery dies and you forget to recharge it in time. That and the way HP mounts the SD and CF drives with embedded spaces in the mount point pathname. And, that CMD does not come installed natively. And, that the CMDs you can get and load do not grok spaces in the SD and CF drive pathnames and parse them correctly into the %1, %2, ... %9 position parameters. And, that PocketWord will not let you put your own filename .ext(ensions) such as .bat on whatever it is you are editing when you save it. And, that there is no easy free way to get an updated version of Java so you can have an alternate workaround for u$oft's idiodicies. Basically, just too many imbecilic things to try to workaround and to monitor to be worth it. I did like its alarm clock when we were out camping, and my wife used the calculator sometimes. I simplified my life -- bought an alumimum macbook pro and an iPhone. Now I can dual boot Leopard (my preferred UN*X platform these days), and Vista for maintaining HulaBats and doing genealogy with FTM, with BootCamp. I am as happy as the proverbial UN*X clam in sea water. Additionally, iNavX and AyeTides is awesome on the iPhone when Location Services are turned on for a portable backup to our old sailboat's aging Garman chart plotter. Now if I could just figure out how to set it up as an anchor alarm...

Redistributables (stuff it is legal to redistribute)

Since it is not advisable that we redistribute these things instead we will try to include URLs to where they might be found on the Internet. Otherwise, as always, Google and Yahoo are your best friends. Python #----------------------------------------------------- Python for Microsoft Windows See "ActiveState Python" just below. ActiveState Python Location of ActiveState Python products ... * which redirects you to ... * Then drill down to the "windows" folder from there. #----------------------------------------------------- Perl #----------------------------------------------------- Perl with LibWin32 See "ActiveState Perl with LibWin32" just below. ActiveState Perl with LibWin32 Location of ActiveState Perl products ... * * There are some scripts in Micrsoft's Support Tools that require specific version(s) of ActiveState Perl. Perl in Cygwin Location of Cygwin products ... Perl in SFU/SUA #----------------------------------------------------- Java #----------------------------------------------------- Sun's Java JRE GoTo URL: Sun's Java SDK (for jar.exe especially) GoTo URL: Sun's PersonalJava for PocketPC - it is not legal to redistribute this. See J# section below. #----------------------------------------------------- C/C++ #-----------------------------------------------------
Borland dll library in the free Borland C++ Compiler
NOTE: the last time I went there it was a redirect to
and the download file was "freecommandLinetools.exe". YMMV.

Express editions of the free Microsoft C/C++ Compiler
NOTE: the last time I went there it had Visual C++ 2008 Express Edition.

OpenWatcom free C/C++ Compiler

C#, J# .NET Framework
Microsoft .NET Framework and SDK

Microsoft J# redistributable

ToDo List

Here is a working to do list, todo... #----------------------------------------------------- cksum/sum - we need a crc getter like Josh's, look at l5/l6, Perl cksum. env.cmd - enhance to use 'setx.exe' to set global environ variables and, also, launch applications with a modified environ. find.cmd - enhance the UN*X find subset emulation using the MsResKit where.exe and options like isdir, fsize. fdata, ftime in forfiles.exe, too. E.g., -size +99999 for a hogs implementaion, and a -newer option, and maybe even a -older option. fuser.cmd - see if we can use findstr instead of grep.exe for this? This is broken under Windows Vista BTW! get/setfacl.cmd - try to emulate these Cygwin commands with (x)cacls.exe NOTE: xcacls.exe is unreliable on w2k3r2 -- DO NOT USE IT! NOTE: Vista has a new cacls.exe called icacls.exe -- MUCH MO BETTA. Also, icacls is available on w2k3r2. head.cmd - the -# option does not check if # is a number and blindly passes the # value off to 'ed' - look at how the newer tail.cmd does it using 'set' environ variable expansion where it first checks if the first digit of # is a number betwee 1-9 before actually grabbing the whole # to use. The way head.cmd does it may be faster than the way it is done in tail.cmd - a time test would be nice to do as well. At any rate, you can at least do some validation if you use the tail.cmd way instead of the head.cmd way. This code is needed for man.cmd for its -# option, too. Look at getargv.cmd as well - it is a command line parser test script we played around with for tail.cmd testing. ifconfig.cmd - in ok shape read-only-wise, but it does not configure yet! We might be able to call into some .js (or .vbs) script to also configure network stuff? How? Using DMTF's WBEM/CIM? Could be an entrance into a section on .js programming to challenge the .vbs hackers? man.cmd - see -# parsing discussion in head.cmd, tail.cmd and getargv.cmd tail.cmd - the -f option does not work yet, now it execs tail.exe to do it tar.cmd - might be able to do a tar.cmd wrapper around 'pax'? and/or cpio.cmd? E:\home\cal\bin>which pax c:\winnt\system32\pax.exe E:\home\cal\bin>pax /? The system cannot find the file C:\WINNT\System32\pax.exe. Optionally, use the Java tar code example to build a nice tar command in Java instead. Personally, we use jar.exe and pkzip25.exe and .zip files instead of .tar.gz bundles these days cuz jar.exe is everywhere we go, practically. time.cmd - look at using 'timeit.exe' to evaluate how long a command runs w.cmd - enhance to possibly include some data from 'tty.cmd' &c. wc.cmd - the -w word count option does not work yet, speed up -c (see fsize.cmd) yes.cmd - add a timer-delay-to-start option for use with: pause < yes -t 5 ftruncate/truncate - NOTE: cat.cmd now takes "/dev/null" as an arg to zero out existing files. tline - There is a MsResKit tool that works like this though (choice.exe?) and you can use 'set /P "Enter a command:" for one line prompts. chown.cmd - Vista has the new icacls.exe which may facilitate this? matchacl.cmd - I have a Cygwin bash script that uses get/setfacl to do this, but I would like a native .cmd script to be able to match the ACLs of a newly created directory to another extant directory sort of like how you can specify a touchfile with the UN*X "touch" command to match the date-time-stamp(s) to; must work recursively. #-----------------------------------------------------

This section is specific to Windows Vista issues and anomalies...

Some commands we use in the MsResKit are now native in Vista. Examples are: where.exe, shutdown.exe,... #----------------------------------------------------- fuser.cmd - oh.exe is now openfile.exe which broke our fuser script ls.cmd - ls.cmd had some Vista issues (see also: ls_vista_fix.cmd) reboot.cmd - this had some Vista issues (see also: reboot_vista_fix.cmd) shutdown.cmd - this had some Vista issues (see also: shutdown_vista_fix.cmd) #-----------------------------------------------------

NEW: a new special section for Windows 7 issues and anomalies...

Unfortunately, we have been too busy learning Python and starting a Python version of HulaBats, and working on other things like our genealogy research and family history web pages to actually load Windows 7 Beta and try out our code on it. Will do so as soon as time allows.

Disclaimer: on the street talk terminology...

References to Microsoft products are not written out in the formal way with all the registered trademark ® or copyright © marks after them and their full names are rarely used. Many products have "handles" such as "MsResKit", "SupTools" and are used instead of their full product names (e.g., Microsoft Resource Kit, Support Tools). Programmers, the intended audience for this stuff, will usually know what is meant. But, here are some translations for the abnormally braindead among you... uSoft = refers to the company: Microsoft® (stock ticker: MSFT) u$oft = refers to the monopoly: Microsoft® (stock ticker: MSFT) Windows = refers to Microsoft® Windows® (not the X11 Window (singular) system) Windoze = refers to Microsoft® Windows® (yawn) 2k = refers to Microsoft® Windows® 2000 Professional w2k = refers to Microsoft® Windows® 2000 Professional w2kpro = refers to Microsoft® Windows® 2000 Professional w2ksrv = refers to Microsoft® Windows® 2000 Server w32 = refers to Microsoft® Windows® Win32 API library XP = refers to Microsoft® Windows® XP Professional XPpro = refers to Microsoft® Windows® XP Professional 2k3srv = refers to Microsoft® Windows® Server® 2003 sp1 Win2k3Srvr = refers to Microsoft® Windows® Server® 2003 sp1 w2k3r2 = refers to Microsoft® Windows® Server® 2003 R2 Vista = refers to Microsoft® Windows® Vista Longhorn = refers to Microsoft® Windows® Server 2008 w7 = refers to Microsoft® Windows® version 7 (the Vista follow-on) Windows 7 = refers to Microsoft® Windows® version 7 (the Vista follow-on) WindowsCE = Windows® Compact Edition for PDAs. PocketPC = Windows CE Pocket PC v4.2 and above for PDAs. We still probably did _not_ get all the "®" strings in the correct places! Similarly, you can tell we have been around a while, because UNIX® is such a pain to write that programmers like us usually just use this instead: UN*X = which refers to UNIX® systems in general, both the license encumbered versions and the "free" ones. Linux® is either a trademark or a registered trademark of Linus Torvalds in the U.S and other countries. So, when you see "Linux" please translate that to "Linux®" in your head, ok? Linux = refers to the Linux® operating system (in all of its incantations) You know, the one with the the Penguin "Tux" icon? Solaris® is a registered trademark of Sun Microsystems, Inc., although the operating system itself has recently been "open sourced"... OpenSolaris - GoTo URL: Solaris = refers to the Sun Solaris® operating system Solaris - GoTo URL: Java = refers to Sun's Java Software Development Kit (JDK or SDK) Java - GoTo URL: BSD = refers to the University of California Berkeley's Berkeley UN*X Software Distribution, aka all BSD UN*X operating systems in general. Three examples of BSD systems for Intel and AMD devices are: FreeBSD - GoTo URL: NetBSD - GoTo URL: OpenBSD - GoTo URL: Cygwin = refers to the RedHat® Cygwin® project (GNU + Cygnus + Windows) and its releases of software. Cygwin - GoTo URL: Anyway, if you are a lawyer representing one of these august institutions in our industry and you are miffed about our terminology just send us email and we will be happy to fix whatever verbiage is bugging you. We surely don't intend on slighting anyone by the street talk, and we cannot afford a lawyer to deal with your idiosyncracies.

UNIX® is either a trademark or a registered trademark of the Open Group in the U.S. and other countries.

Solaris®,Sun®, and SunOS® are either trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries.

Linux® is either a trademark or a registered trademark of Linus Torvalds in the U.S. and other countries.

Windows® is either a trademark or a registered trademark of Microsoft in the U.S. and other countries.

Google® is either a trademark or a registered trademark of Google in the U.S. and other countries.

Yahoo® is either a trademark or a registered trademark of Yahoo in the U.S. and other countries.

Date Last Modified: 09 Oct 2014 (clc)