RCB> I like very much WIZ, but I would say, 32bit. :)
 RCB> Your program WHICH is good but is dont but yet dont is a "wiz".

I've looked at the WIZ documentation, and there really isn't much there that
one cannot already achieve with FF and SUM from OS2CLU version 2.0 and a
little imagination.  The syntax is slightly different, true, but I'd argue
that the command-line syntax of WIZ isn't exactly regular and consistent with
anything else in the first place.  The OS2CLU utilities all have a regular
syntax that is not only consistent across all utilities but also reasonably
consistent with other text-mode commands such as DEL.

Dealing with the options that WIZ supports in no particular order:

þ -a (find only archives) and -x (find only executables and scripts)

        FF supports UNIX-style extended wildcards, which are a (slightly
improper) superset of the wildcards that WIZ supports.  WIZ doesn't have {}
wildcards.  FF does.  This immediately provides a much more flexible way of
searching for executable and archive files than WIZ does with its -x and -a
options.  With FF, one simply uses an appropriate wildcard:

        C:\>WIZ -a c:WIZ*

                becomes

        [C:\]FF /S c:WIZ*.{arc,arj,lzh,pak,zip,zoo}

                and

        C:\>WIZ -x c:WIZ*

                becomes

        [C:\]FF /S c:WIZ*.{exe,com,bat,btm}

        The advantage of using wildcards is that one can easily extend the
scheme. WIZ's set of archive extensions is hard-coded.  (It doesn't know about 
RAR or TAR.GZ archives, for example.  And it doesn't know about *.CMD script
files, either.)  But by using wildcards one can easily extend or restrict the
list of extensions that qualify filenames as "archives":

        [C:\]FF /S c:WIZ*.{arc,arj,lzh,pak,zip,zoo,rar,jar,tar.gz,tar.bz2}

                or

        [C:\]FF /S c:WIZ*.{zip,lzh}

þ -s (size qualifier) and -d (date qualifier)

        FF doesn't support these.  These are the only significant features of
WIZ that one cannot duplicate with FF.  But it's worth noting that FF has
selection by attribute, /A, which WIZ doesn't have.  So the comparison isn't
entirely one-sided here.

þ -v and -vv (diagnostics)

        FF doesn't support equivalents to these.  FF used to have an animated
progress display, but I found that it obscured the actual output when
redirecting to file or through a pipe to another program (such as MORE).  I
doubt that anyone seriously uses these in any case.

þ -p (omit date, time, and size) -pp (omit header and footer) and -y (summary
only)

        FF supports all of this functionality (and slightly more) with its /F, 
/U, /C, /Q, and /B options.

þ -q (limit to certain paths)

        FF doesn't need this because, unlike WIZ, FF allows path specifiers in 
wildcards.  So instead of

        C:\>WIZ c:WIZ*.* -q\utils\

                simply write

        [C:\]FF /S c:\utils\WIZ*

þ -e (display seconds in timestamps)

        FF displays seconds by default.  FF can also switch between local and
ISO 8601 display formats, and even display (where available) any of the last
modification, last write, and last access timestamps of a file (or even all of 
them at the same time).

þ -n (skip network drives)

        This option has no relevance in the first place.  WIZ reads volumes
directly, sector by sector, to search for files.  Whilst this may provide
speed benefits on DOS it's downright silly on OS/2.  For one thing, it
requires the program itself to duplicate the functionality of the filesystem
driver.  On DOS, WIZ only needs to understand FAT, but on OS/2 it would need
to support, and keep up with, *all* of the possible volume formats that one
can use on OS/2, from HPFS to FAT32, stopping at EXT2 along the way.  (And
notice that this vulnerability of WIZ to being made obsolete was even
demonstrated on DOS, when the author had to produce a new release to cope with 
the new >32MeB volumes in MS-DOS 4.) As I said, WIZ may have used this
technique for DOS, but by far the most sensible design for an operating system 
such as OS/2 Warp is to leave understanding the filesystem structures to the
filesystem drivers (whose job that is) and to leave optimising disc accesses
and minimising head travel (which software cannot reliably do for SCSI and ATA 
discs *anyway*) to the cacheing subsystem(s) (whose job that is).  This is
what FF does.

þ -g (go to directory)

        This option is impossible to duplicate, because this particular quirk
of DOS simply doesn't exist outside of DOS.  Changing the working directory of 
a different process (such as the command interpreter that runs a program) is
impossible on most well-designed operating systems where processes are
insulated from one another, including OS/2 Warp.

þ -m (more)

        FF is designed to be used in situations where it *should not* assume
that its output is being sent to a console device.  It can be used in a
command window in EPM, for example, or as a TTY application in Take Command
for OS/2, or in a command pipeline, or even in a detached session.  As such,
it has no foundation for assuming that it can determine the number of lines to 
display on each screenful, since its output need not actually be a screen in
the first place.  To display the output of FF one screen at a time, as if
piped through the MORE command, simply pipe it through the MORE command!  It's 
not as if one is using an operating system such as DOS, where one doesn't have 
real pipes where both ends can run in parallel.  (-:

þ -l (look inside archives) and -b (look at ordinary files as well)

        FF scans archives for matching filenames, too.  It allows fine-grained 
control of which archives to look inside with its /ARC, /ARJ, /LZH, /PAK,
/RAR, /ZIP, and /ZOO options, and has the /DIR option to match WIZ's -b
option.  All of the options can be followed by either '+' or '-'.

þ -r (don't skip over PC-Tools's SENTRY directory)

        This doesn't apply to OS/2.

þ -rr (print CRCs)

        This is what I would class as an "army knife" option.  It's an attempt 
to make one tool do too many jobs by bolting on features.  Like the parts of
an "army knife" that aren't specifically related to its core function of
_being a knife_, it pales in comparison to a tool specifically designed to do
the relevant job.  FF doesn't print checksums.  OS2CLU version 2.0 has the SUM 
command for calculating all sorts of checksums, from CRC-32 to MD5.

þ -c (run command)

        This is another "army knife" option.  Again, a far better approach on
OS/2 is to pipe the output of FF through a second command, that reads each
line of its input and acts upon it.  I posted a FOREACHLINE.CMD REXX script,
that does exactly that, in the OS2REXX echo a couple of weeks ago, which one
can quite easily use to achieve what WIZ achieves with its -c option.  (I'm
sure that some enterprising REXX programmer could modify my script into an
XARGS.CMD if one wanted to reduce process setup and teardown overhead, too.)
So instead of

        C:\>WIZ WIZ* -c"erase *"

                write something like

        [C:\]FF /C/U/B /S/E WIZ* | FOREACHLINE DEL

        (Substitute "SUM /U" for "DEL" in the above and you even have the
equivalent of WIZ's -rr option.)

        The advantage of using the pipe is, of course, concurrency.  FF can be 
busy searching for more filenames at the same time as FOREACHLINE is executing 
the DEL command to delete the file.  With the approach taken by WIZ (and
because of the constraints of WIZ being a DOS tool that runs on DOS), no such
concurrency is possible.

According to the documentation, at any rate, this covers all of the features
that WIZ has.  As you can see, with all bar two of the features of WIZ (-s and 
-d to specify ranges, and -v for diagnostic output), either the feature
doesn't apply to non-DOS systems or one can do the equivalent with FF or SUM
right now.  

If you have a particular usage of WIZ that I haven't covered above, post it
for everyone to see, and either I or the others in this echo will help you to
find a way of doing the same thing with native OS/2 tools.

 ¯ JdeBP ®

--- FleetStreet 1.22 NR
114/441