)
A long answer to a short question: (This response by JdeBP to a question
by Chris Graham happened to be in the same mail packet as your question.)
_ _ _
CG>> Just a simple question: Why do we need yet another set of
CG>> command line utilities???? Ther are already ample freeware
CG>> and commercial ones available.
Indeed there are. And the OS/2 Command Line Utilities *version 1* is
amongst them. It was released back in 1993
Even if we discount the pedigree of the OS/2 Command Line Utilities as a
factor, the quality of some of the other free utilities floating around
is very often poor. Quite a few of the basic file and directory utilities
on Hobbes, for example, are 16-bit OS/2 utilities. Some of them don't
even support long filenames! Many quite obviously contain "DOS think"
assumptions in the code, and the author clearly hasn't thought about how
differently certain things operate on OS/2.
One of the reasons for the development of TREE in OS2CLU version 2, for
example, is that the TTREE command available from Hobbes fails with an
SYS3176 if the directory tree happens to be too deep. Don Woodall
discovered this when he tried to do a TTREE that just happened to include
his C:\OS2\Archives directory. It's obvious that the author didn't think
that just maybe OS/2 didn't have the 128 character filename limitation
that DOS does, and used a fixed-length buffer of 128 characters for
filenames, causing the program to scribble over its data and fall over
when used in an environment where the longer filename lengths available in
OS/2 happen to be used to the full
Even the OS/2 ports of the GNU utilities are shoddy in places. The GNU
`date' command, for example, has a Year 2000 problem! And, of course,
the syntax is different to that that people are used to with "standard" PC
tools. The GNU tools use "--help" for on-line help. The PC tradition,
such as it is, is to use "/?". Similarly, the GNU tools don't cope too
well with things that don't exist on UNIX, such as file attributes and
file sharing, whereas the PC tradition has for a long time supported such
things as /A options on commands such as DIR to allow users to select
files by attribute, and tools that use proper file sharing modes to be
network- and multitasking- friendly
So one of the reasons for OS2CLU is that I, personally, don't want to just
"make do" with such substandard and wrongheaded tools. I don't want to
limit my use of OS/2 to that which just happens to be compatible with the
DOS paradigm, just because the only tools available are quick, poor, ports
of DOS tools with all of the "DOS think" limitations in the code left in.
And I don't want to use tools that try to make OS/2 look like UNIX,
ignoring the many good ideas invented in the PC world
OS2CLU version 1.0 resulted from this. None of the tools in OS2CLU
version 1.0 contain egregious errors like 8.3 restrictions, fixed-length
filename buffers of 128 characters, and so forth. And several of them,
such as XDIR and XDEL, were modelled on utilities in DR-DOS. (DR-DOS's
toolset is a good model to imitate in many respects, since it was, and
still is, probably the flavour of DOS with the most coherent, powerful,
and friendly command-line user interface.
But all of the tools in OS2CLU version 1.0 were 16-bit, (I didn't have a
32-bit compiler at the time.) and besides the fact that 32-bit code is
"cleaner", there are a few neat system API tricks that one can do in
32-bit OS/2 that one cannot in 16-bit OS/2. So finally, after many years,
I got around to producing OS2CLU version 2.0, which I intended to be a
"purely 32-bit" suite of utilities
Along the way, several tools have been added. Some were added in response
to my needs and whims (I find FINDDUPS very useful, for example.), and
some in response to those of other people (such as Don Woodall's above
problem with TTREE, and the fact that the author of TTREE has disappeared
from sight).
Some were added because I got tired of waiting for IBM. For example, the
SORT provided by OS/2 is 16-bit, and has 64kB data size limitations as a
result, even though a 16-bit OS/2 program need not have such limitations
(I've written 16-bit OS/2 programs that didn't have.) -- yet more "DOS
think" legacies in OS/2 program designs! IBM's SORT was like this in OS/2
1.0, and it looks like it's never going to change, so I wrote a 32-bit
SORT. Ironically, despite what they say about 16-bit code not necessarily
being slower than 32-bit code (and I'm not disagreeing with this), my
32-bit SORT does seem to be faster than IBM's 16-bit one. One could,
therefore, regard its abilities to sort files greater than 64kB, to sort
files named on the command line, to recurse into subdirectories, and so
forth, as merely bonuses. (-
Unfortunately, few 32-bit OS/2 tools were ever written to operate properly
in this respect. Certainly the DATE and TIME commands built into CMD do
not. (But then, CMD, like SORT that I mentioned before, didn't change
much from OS/2 1.x, and is still 16-bit code.) And no C/C++ compiler
vendor bothered to do a decent port of its standard C library when it
produced a 32-bit OS/2 flavour of its compiler. Instead, the
implementations of time() and localtime() all work backwards, from local
time to UTC, and have major problems with DST ambiguity in the hardware
clock -- just like they do on DOS, even though they *don't have to* on
OS/2. Additionally, if this laziness and "DOS think" weren't enough, many
third party developers just called DosGetDateTime() to read the hardware
RTC directly, and so all of their programs try to make 32-bit OS/2 look
like DOS, ignoring the fact that it was "timezone ready", too
Hence we have a whole suite of tools in OS2CLU:
SAYDATE, a tool to display the current time, or a given time, in a variety
of formats, that behaves as a port of the UNIX `date' command to OS/2
*should* work. (The actual GNU port of `date' has a Year 2000 problem, as
mentioned. ...
DIGCLOCK and ANACLOCK to provide graphical clocks. (Neither the WPS clock
object nor the clock on the Warp Centre respect timezones, or daylight
savings time. But DIGCLOCK and ANACLOCK, since they operate like UNIX
tools do, change timezones automatically, at precisely the correct time of
year, without any need to alter the system clock. ...
SETDATE, a tool to set the current time from the time expressed either as
local time or UTC time (i.e. doing the other half of the work done by the
UNIX `date' command)
CALCTZ, a graphical calculator for the timezones and DST rules in the TZ
environment variable that uses the standard POSIX 1003.1 (ISO/IEC
9445-1:1990) format. (Rather than the idiosyncratic format that IBM, for
no good reason, invented for VisualAge C++, and that no-one else uses --
not even IBM itself on other platforms!
JdeBP
_ _ _
I believe Lance Hegamin still has the OS2CLU01 package available on his
CAMELOT BBS (310-204-6158). Messages can be addressed to JdeBP through
the FIDO OS/2 conference. U.S. participation in the beta testing of
OS2CLU02 is being coordinated by andy@shentel.net
cc: Lance Hegamin [LHegamin@mediaone.net]
=====================================================
To unsubscribe to this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-general".
For problems, contact the list owner at
"rollin@scoug.com".
=====================================================
<< Previous Message <<
Return to [ 13 |
March |
1999 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International
Business Machines Corporation.
All other trademarks remain the property of their respective owners.
