is a collection of command-line tools for Windows® operating systems. They are meant to make the shell (cmd.exe) more usable for scripting and other purposes. To the best of my knowledge, most of the tools provide functionality provided not present in any other freeware programs, if at all.

Each of those programs was driven by need: I needed to do something, looked around for freeware tools, yet didn't find any— for Windows, and that's truly usable. (For example, I wouldn't really consider 'head' & 'tail' from 'Cygwin' a viable choice… Cygwin on Windows is just notoriously slow!) So, I wrote my own— while teaching myself C++ for the first time, and without previous knowledge of C. Then, several years later, when I had the time to manage the hosting project, decided to share them in the hope they might help someone else someday.

Although they were built with a 32-bit compiler, they work just as well on 64- bit Windows. Furthermore, where applicable, 64-bit data types and seeks within files are used to handle files/sizes up to the theoretical limit of 9EB.

Each program has built-in extensive help, usage examples and exit codes to help with scripting.

Kawashti Tools is licensed under GNU GPL v3. However, since you can download any individual program you want, check its exact license version from the description below or the program's help.

Unless otherwise specified, all tools were developed on MS-VisualStudio 6 SP5.

Dr. Hatem Kawashti

30 Jul 2010

Kawashti Tools

Source Code

x86 Binary

KDir

KDir a no-nonsense alternative to the built-in DIR command. Because timestamps are of utmost importance to me, I wrote both KDir and SetFileTime. Together, they very much help me inventory and log into a database my library's files. KDir's output is exactly 4 tab-delimited fields. Those are: Size, Creatation timestamp, Last modification timestamp and finally file name. Size is large enough to hold 9EB (9 Exabytes.) Its field is right-aligned with width calculated dynamically at runtime to be the smallest one large enough to hold the largest size. Both timestamp fields are fixed-width formatted as Yyyy:Mm:Dd:Hh:Mm:Ss. File name is relative pathname from the given entry point directory. The latter can begin with a local, UNC network, NetBIOS, or DNS name, or an IP address.

KDir is unicode. To make it work despite the well-known problems of the Windows® shell (cmd.exe), it filters output to the shell so characters the latter can't display are shown as question marks. The real unicode output goes to a text file which KDir optionally launches notepad for when finished.

Since I have my entire library on a RAID5 on FreeBSD and Windows® boxes access it through Samba server, it made sense to write a Unix version of KDir. I did, but as a BASH script which goes even farther and eliminates symlinks which I use quite often. That's a feature indeed I miss in this KDir. I'll make a note here should I have the time and decide to publish my Unix tools collection.

License:  GNU GPL v2 or, optionally, any later version.

Click here for a screenshot.

Source Code

x86 Binary

SetFileTime

SetFileTime is, allegedly, the ultimate file timestamping tool. It is far too superior to the ubiquitous 'touch' command in the Nix* world. In addition to changing timestamps individually, or in any combination, it can also use another file as template, use system time, or offset to either. Even better yet, it can copy one timestamp from the file to the other 2 of itself. This last one is particularly important to me because Windows® has the nasty habit of setting the creatation timestamp to current time whenever a file is copied, or moved to a different volume, no matter what the method and modifiers used. For consistency, especially with my Book & Media library, I want creatation and modification timestamps to be exactly the same. SetFileTime /d:m path\to\file does just that: tells it to duplicate the modification timestamp to the other 2 in file. Indeed, KDir, SetFileTime and TreeSize are the cornerstones of my library management.

Version 2.0.0 was re-developed on MS-VisualStudio 2008. It can process an entire directory tree, not just a single file. Furthermore, it features pattern matching with wildcards for file, or even directory selection. Patterns can be negated to exclude matches. Up to 100 patterns can be used.

If you get the error "The system cannot execute this program" or similar, you need to install the lastest version of MS-VC resdistributable package (vcredist_x86.exe). Alternatively, the source code package contains a text file with simple instructions to coerce VC++6 Sp5 to build it.

License:  GNU GPL v3.

Source Code

x86 Binary

TreeSize

TreeSize make a tree-like representation of the given entry point directory. It shows every subdirectory and file on the tree. At any level in the hierarchy, for a directory it shows the total number of files underneath its branch, their total size in bytes, and as a decimal divided by the highest multiple of 1024 (kilobyte) truncated from the third digit after the decimal point.

TreeSize is unicode. As with KDir, to overcome shell problems, TreeSize saves its output to a unicode text file, upon which it launches notepad when finished and detaches itself from it. It is due to the shell's problems that TreeSize specifically doesn't support pipelining or redirection.

License:  GNU GPL v3.

Click here for a screenshot.

Source Code

x86 Binary

KCipher

KCipher encrypts, files using the 256-bit variant of the AES (Advanced Encryption Standard) algorithm. It uses a 256-bit SHA-2 (Secure Hash function v2) of the user's given passphrase as the key for the block cipher— AES— which operates on 128-bit blocks of input data. To strengthen the encryption, KCipher also compresses input using zlib before the encryption. KCipher optionally does a secure wipe of the source file after encryption has succeeded. At doing so, it meets or exceeds the "US Department of Defense Standard 5220.22-M/NISPOM 8-306 for sanitization of non-removable rigid disk." Naturally, KCipher decrypts files that were encrypted with it. To avoid possible futility, KCipher doesn't attempt to compress files which it knows are likely not to compress well. It lets you know about it. You can determine what will be skipped from help.

KCipher can, in theory, process files up 9EB in size.

KCipher is based on works of at least 3 other authors. The AES implementation comes from one, the SHA-2 from another, and then the zlib compression library from one or more. Authors of the first 2 claim their implementations to be FIPS-compliant (FIPS stands for Federal Information Processing Standard.) I'm not a cryptographer myself or even remotelty related to the field of cryptography. Therefore, I cannot attest to any such claims. Review their source files yourself if in doubt.

From the premises, if you contemplate making any modifications to KCipher, derivative works or so, be sure to review the 3 other licenses it entails.

KCipher has an extensive 2-level help pages, invoked by typing KCipher /? or /?? for the advanced. They're more like informational pages really, since its usage is very simple

License:  GNU GPL v2.1 or, optionally, any later version.

Click here for a screenshot.

Source Code

x86 Binary

Head

Retrieves the first n lines from a file or 15 as the default. Head also has a switch telling it to consider the input an email message, and therefore retrieves only the RFC822 headers' lines. It can also number lines as it prints them.

Head supports input pipelining and redirection.

License:  GNU GPL v3.

Source Code

x86 Binary

Tail

Retrieves the last n lines from a file or 15 as the default.

As with Head, Tail supports input pipelining and redirection. Yet, because of reads off the end of a file, and because of the possible pipelining, it has not way of knowing the input size in advance. Therefore, to make the code simple, Tail buffers the entire input in RAM. A limit of 256MB is set, in addition to 32MB for line address indexing. The former sets a cap on file size and the latter limits the maximum number of lines to 2^23=8,388,608. I suppose both are reasonable limits and their memory should be available on any modern system. However to change those, all you have to do is change 2 constants in the header and recompile.

License:  GNU GPL v3.

Source Code

x86 Binary

GetLines

GetLines surpasses both Head and Tail combined. You can skip from the start, the end, or both, or request a specific range of lines. To the best of my knowledge, a program with similar functionality doesn't exist even on Unix-like platforms, although on some of them it can achieved via several pipes.

• It supports input pipelining and redirection.

• Version 3 was a redesign on 2, and developed on MS-Visual C++ 2008. It also compiles seamlessly as-is on GNU GCC. That was tested on FreeBSD-7.1 and CentOS-5.4; it worked without so much as a warning.

This example I suppose best demontrates GetLines' usefulness:

dir path\to\dir | getlines 7,2

It removes first 7 and last 2 lines of DIR's output; in other words, the nonsense. Now the output is really usable by another tool, or even a 'for' loop in a 'stupid' batch program.

License:  GNU GPL v3.

Source Code

x86 Binary

GetEmailAddr

Extracts email addresses from a given RFC822/2822 header or all of them. It is assumed that you have access to the mail store where every message is in its separate file. Alternatively, and obviously only if there's a compelling need, you can copy and paste messages from your mail client to text files and use GetEmailAddr on them. Personally, I wrote it for automatic (scheduled & scripted) use on my mail system for antispam and statistical purposes.

• GetEmailAddr is standards-aware. Thence, it can extract up to a 100 addresses from a single header. It processes only RFC822 headers section of a message; that is, it stops at the first blank line.

• It supports input pipelining and redirection.

License:  GNU GPL v3.

Source Code

x86 Binary

ClockMe

As its name implies, it clocks a command's execution time. Additionally, it can return a datarate in units/s. For example, to determine the average data rate of a mass file copy operation across a network, this command should do the job:

ClockMe -r:b12345678M xcopy /h /i /s /e /c /o /k "\\server\share\Copy These Files"
x:\dest\path

The details of the xcopy itself are irrelevant here. However, -r:unit<number>unit tells ClockMe that it is to measure a datarate, for an input of size 12345678 bytes, and to report the rate as MB/s. Needless to say that ClockMe doesn't, and can't, know about every command it clocks. That's why you have to tell it the size if you want to measure a datarate and units for both input and reported rate.

To be able to clock a command like the above is exactly why I wrote ClockMe in the first place.

License:  GNU GPL v3.

Source Code

x86 Binary

ADSCheck

Visit the project's website.