jafischer@lily.waterloo.edu (Jonathan A. Fischer) (03/04/88)
I'm posting my copier program, called 'ct'. Complete description is
in the documentation below; however, in brief:
- maintains timestamps from source to destination file.
- copies directory trees
- performs selective backup
- handles wildcards (i.e., can be called from the desktop or from
within a program like 'Flash').
- works on all STs (well, I don't have a Mega to test with, but if it
doesn't work on one then I'd be really surprised), in all
resolutions.
---------------- Cut here ----------------------------------------------------
Mar 4 01:18 1988 ct.doc Page 1
You may have noticed that when you copy files with the Desktop (by
dragging icons), the new files created by the copy have a timestamp equal to
the current date and time, rather than the timestamp from the source file.
For many situations, this is not a problem. However, it is often
useful to maintain this timestamp when copying. Since many command-line
copying programs (typically named 'cp' after the Unix command) for the ST are
also plagued with this problem (the ones supplied with "Gulam" and Beckemeyer's
Micro/MT C-Shell being exceptions), I wrote my own, and called it CT, for
'copy with timestamp'.
It wasn't until after I wrote CT that I discovered that Gulam and the
MT Csh had solved my problem. So why bother continuing to update and improve
CT, you ask? Mainly because of the additional capabilities that I've added
since the original version, namely:
- now copies whole directory trees with the '-r' option.
- allows selective backup of files with the '-b' option. (e.g.: you're
working on a ramdisk, and saved all your files to floppy 20 minutes
ago. Before you run your test program, you want to save all the
files have changed since you last saved them to floppy.
"ct -b * a:\" will do this.)
- can request user verification if the destination file exists
**** - accepts wildcard file specifications, so that CT may be called up
from the Desktop. (Or from the Megamax graphical shell, or from
within Flash, for instance). (** See description of wildcards,
below).
- also, if called from the Desktop, waits for a keypress before
exiting.
Now, Gulam does have a '-r' option; however it doesn't seem to copy the
actual directory structure, but only the files themselves that are contained
in the directories. With CT, if you specify
ct -r a:\{bin,lib,work} c:\
then the 3 directories themselves, as well as their contents, will end up on
c:\ (just like it works on the desktop when you drag folders).
GEMDOS BUG 'FIXED': You may also have noticed (if you work with
floppies a lot from command shells) the following problem: you are working
from a ramdisk directory, and you want to copy a file from a floppy onto the
ramdisk. You remove the floppy that is in the drive, and insert a new floppy.
Then you type, "cp a:\folder\file.nam c:\" or some such thing, and the copy
fails, with "can't open a:\folder\file.nam". If you then type "ls a:\" and
repeat the copy command, it will work. This problem is fixed in CT. GEMDOS
for some reason won't access files in subdirectories when a disk is changed,
_until_ it has a look at the root directory on the new floppy. I basically
force it to do this if I can't open the file.
CT is also fairly robust:
- when expanding wildcards, CT can handle up to 2000 files in total.
When copying directories, CT can handle up to 2000 files rooted in
one directory. This limit may easily be increased by modifying
a #define in the source.
- will allocate a very large buffer (I have it #define'd to try for
500K). This really helps when copying from a: to b: with one
drive (although be warned: there are still a couple of swaps per
Mar 4 01:18 1988 ct.doc Page 2
file).
- if you are working under the MT Csh and you want to use CT in the
background, then you can specify the '-m' option, to restrict CT
from hogging all available memory.
- when performing a recursive directory copy, CT checks for stack
overflow.
- if a file is not successfully copied, CT deletes the destination
file.
Wildcards:
==========
* - match with any string of characters.
? - match with any single character.
[] - match any one character within the brackets. Ranges of characters
may be specified as follows: [a-zA-z] meaning any lower or upper
case alphabetic character.
{} - match any of the specified groups of characters, e.g.
{word1,word2,word3} will match with 'word1', 'word2', and 'word3'.
Some examples:
a:\{bin,lib,include}\*.c
- matches with all '.c' files in a:\bin, a:\lib, and
a:\include
*
- matches with all filenames, with or without extensions.
c:\work\*.[ch]
- matches with all '.c' and '.h' files in c:\work
[d-q]*
- matches with all files beginning with the letters 'd'
through 'q'.
Interesting tidbits:
====================
(more than you care to know, probably, but hey, this is my moment on the
soapbox so let me enjoy it...)
- In testing CT, I created a directory tree containing around 2,000
files of zero length, strewn among several directories. CT handles
this fine, thank you, but GEMDOS just died disgracefully when I
tried to delete these folders. Not even a warm boot would
resuscitate the ramdisk!
- An easy (but not flawless) way to determine if a program has been
called from the Desktop is simply to check if argv[0] is an empty
string. Most ST shells (msh, Gulam, MT Csh) will set argv[0] equal
to the program name, i.e., "ct". However, if a user is, er, 'using'
a command shell that doesn't follow this standard practice, CT will
assume that it is being called from the desktop, and will wait for a
keypress before exiting.
- If you go through the source code, you can't miss the inelegant
method I use to allocate as large a buffer as possible. It's very
evident that I'm not using the standard Malloc(-1L) method. Why?
Apparently (from all I could tell) you simply cannot mix Malloc()
and MWC's malloc() routines in the same program. As soon as Malloc()
is called, malloc() will refuse to allocate any memory. Since
Mar 4 01:18 1988 ct.doc Page 3
I doubt that Malloc() will perform 2000 allocations (I think that
the fixed limit is well below that), I'm forced to use malloc().
- Cconws( NULL ) seems to print one backquote ("`").
- When run from the desktop as a .ttp program, the first tab printed
doesn't seem to behave itself. Just try running ct.ttp with no
params, and you'll see what I mean. (Although I have some very
old ROMS, so it your mileage may vary).
- Fread() doesn't seem to return an error code. Even if I get the
"Data on the disk in drive A may be damaged..." alert box, I don't
get a negative return code from Fread().
EMail suggestions or bug reports (not that there _are_ any :o) ) to:
Usenet: jafischer@lily.waterloo.edu (until May 1988)
or: ...{ihnp4,allegra,decvax,utzoo,utcsri}!watmath!lily!jafischer
Compuserve: 76626,210
NOTE: CT is in the public domain.
DISCLAIMER: (just to be safe) I shall not be held liable for any
damages incurred through use or misuse of CT. There.
- Jonathan Fischer.
------------------------------- end of file ----------------------------------
--
- Jonathan A. Fischer, jafischer@lily.waterloo.edu
...{ihnp4,allegra,decvax,utzoo,utcsri}!watmath!lily!jafischer
"My computer understands me."
- Old button of mine.