lightweight file copier?

[Ivan X]

I'm looking for something that can copy ProDOS files -- ideally, including subdirectories, though if not then ok -- but that can run politely from BASIC.SYSTEM, so I can use it with VSDRIVE.LOW, and not take up a ton of disk space.

I'm only really aware of the "heavy" programs, e.g. Copy II Plus or System Utilities. Any alternatives out there?

[Riccardo]

Il giorno lunedì 22 luglio 2013 08:47:11 UTC+2, Ivan X ha scritto:
> I'm looking for something that can copy ProDOS files -- ideally, including subdirectories, though if not then ok -- but that can run politely from BASIC.SYSTEM, so I can use it with VSDRIVE.LOW, and not take up a ton of disk space.
>
>
>
> I'm only really aware of the "heavy" programs, e.g. Copy II Plus or System Utilities. Any alternatives out there?

Copy II Plus should work by VSDrive.low (it see all drives real and virtual) on Virtual disk or Real disk. Or you can use FILER.sys (very light and powerful), it can use same by virtual or real disk and work with VSDrive.low (it see all drives).



-Ric.

[Benoit0123]

Hello,
There are numerous utilities file based copy programs which have been
published in the past in Apple // magazines (from M. Sandy Mossberg or Ken
Manly among others).
My own versions are included within the disk archive
http://bgilon.free.fr/apple2/P8Merlin_Utils1.do
The COPY external command runs happily under ProDOS BI and even allow for
"some bells and whistles" (like only copy when source file is more recent
than possible destination file).
AppleWorks docs are included so that you can refer to it in case you are
curious about EOCs (for External Overlay Commands).

HTHATS,
Benoît

[Bill Buckels]

"Ivan X" <iv...@ivanx.com> wrote:

> I'm looking for something that can copy ProDOS files

Like me, if you are familiar with Unix and/or the C programming language you
may wish to consider 2 alternatives to tricycles with training wheels:

1. The Aztec C Unix-Like Shell for ProDOS (SHELL.SYSTEM) has a built-in
command called cp, which copies files and their attributes. SHELL.SYSTEM
also provides shell-scripting (exec files). The cp command will accept
wild-cards.

For example, to copy all the c source files from the FOOBAR directory to the
current directory:

cp /FOOBAR/*.c .

The Aztec C pdf documentation provided by the late Paul R. Santa Maria
contains a synopsis of the cp command in the utilities chapter, and a full
chapter dedicated to SHELL.SYSTEM.

2. Aztec C itself can also be used to obtain fileinfo, read ProDOS directory
blocks, and everything else that one needs to write a custom copier for raw
ProDOS or alternately a utility for SHELL.SYSTEM, of any complexity that
will run without the need or desire of BASIC.SYSTEM assuming that one is
proficient in the C programming language.

The BASIS for such a utility can be reviewed by downloading from the link
from a recent post I made in here (see below):

Note: Disk images with SHELL.SYSTEM are provided so you can experiment to
your gentle heart's desire with this stuff. Source Code that can be modified
to build what you are asking for is both here and in the AppleX distribution
of the Aztec C 3.2b compiler which I updated a little earlier this year...

x--- snip ---x

Newsgroups: comp.sys.apple2
Sent: Monday, July 15, 2013 4:25 PM
Subject: Announce: Aztec C Shell Utilities including No Slot Clock Examples


Available for Download at the Aztec C Website at the following link:

http://www.aztecmuseum.ca/UTL.zip

This zip file contains a number of Apple IIe Utilities written in Aztec C
that run under the ProDOS Aztec C Shell.

Some of these utilites make use of the Apple IIe's No Slot Clock.

Within this folder are subfolders that contain the source code and compile
environmnet for these and working disk images that group these in a topical
nature. Hopefully they will prove both useful and informative.

The following is a brief synopsis of these utilities as they are grouped on
disk. The Source Code comments should prove quite informative, and some
documentation is also provided.

CHANGE.DSK

CHMOD - change file permissions
CHTYPE - change file types
TOUCH - change file dates

CLOCK.DSK (Aztec C Shell)

D8 - Gets and Sets ProDOS date and/or time.
TD - Display Date and Time - Y2K Fixup Revision

CLOCKPRO.DSK ("raw" ProDOS)

TD.SYSTEM - Same as above but for "raw" ProDOS

SHELLUTL.DSK (previously released)

CLS - clear text screen
LCASE - lower case filter
MORE - text file pager filter
SORT - sort filter
UCASE - upper case filter

LIST.DSK

FI - List ProDOS 8 file info (try it)
LM - List Multiple Files (try it)

All of these are part of a larger collection that will include DOS 3.3 Shell
Utilities as well as ProDOS Shell Utilities, but since that work has been
coming slowly, I am releasing what you see here in advance of the larger
collection.

The Aztec C Shell offers wildcards and other Unix-like features which are
supported by some of these utilities.

I hope that you will find what I have here so far useful and informative.
Especially read the source code and try these for more details.

Regards,

Bill Buckels
bbuc...@mts.net
July 2013

[Bill Buckels]

"Ivan X" <iv...@ivanx.com> wrote:

> I'm looking for something that can copy ProDOS files

[Bill Buckels]

"Ivan X" <iv...@ivanx.com> wrote:

> I'm looking for something that can copy ProDOS files

[Bill Buckels]

"Bill Buckels" <bbuc...@mts.net> wrote:

> Blah, Blah, Blah

And the news server that I am using at aioe.org seems to have gone haywire
and posted several duplicates... my original post plus 3 dupes pinged back
to me. I have no idea why this happened but it has never happened before and
rest assured that this was not deliberate, and if it continues to happen, I
will refrain from posting through this server in the future.

If you get multiple copies of this post as well, I am truly sorry. And if I
get multiple copies I will be refraining...

Bill

[David Schmidt]

On 7/22/2013 11:43 AM, Bill Buckels wrote:
> "Ivan X" <iv...@ivanx.com> wrote:
>
>> I'm looking for something that can copy ProDOS files
>

> [...] The Aztec C Unix-Like Shell for ProDOS (SHELL.SYSTEM) has a built-in

> command called cp, which copies files and their attributes. SHELL.SYSTEM
> also provides shell-scripting (exec files). The cp command will accept
> wild-cards.

That was pretty cool - SHELL.SYSTEM dealt with both vsdrive and
vsdrive.low admirably at least through df operations (querying
filesystem size/space). vsdrive.low got clobbered when cp'ing files, as
cp probably uses buffers that stretch into its memory space, not
respecting HIMEM set by ProDOS. vsdrive (high) seemed to ultimately be
successful in copying files to the virtual drives (even running
shell.system from the virtual drive), but some goofy things started to
happen and everything eventually crashed. But that can probably be
chalked up to the virtual serial going over virtual Ethernet on a
virtual machine...!

[Bill Buckels]

"David Schmidt" <schm...@my-deja.com> wrote:

> That was pretty cool

I think so too...

Like I said though, we can also do the same thing in an Aztec C sys program
and just put a memory hole in the SYS program for a buffer like I do in the
SHR examples and most of my other Aztec C stuff to avoid mallocation...
fragmentation... clobberization...

However, we could also redirect a file list in the Aztec C Shell through a
filter of some sort that writes a cp shell script from the redirected
output... lots of stuff a guy can do in shell scripts.

> - SHELL.SYSTEM dealt with both vsdrive and vsdrive.low admirably at least
> through df operations (querying filesystem size/space).

Yeah but it's just a ProDOS getfileinfo call or reading the Volume
Information Block... we can do that in a SYS program too... blah blah blah.

> vsdrive.low got clobbered when cp'ing files, as cp probably uses buffers
> that stretch into its memory space, not respecting HIMEM set by ProDOS.
> vsdrive (high) seemed to ultimately be
successful in copying files to the virtual drives (even running shell.system
from the virtual drive), but some goofy things started to happen and
everything eventually crashed.

HIMEM is respected in some respects I am sure but I can't comment... except
to say this is a goofy hobby full of 30 year old bugs. I find that globing
of wildcards in the shell overwrites a running program when expanding too
large a set. So I cap my own programs at about 60 files and peel them off
**argv right at the start...

I'd love to have the shell.system source code.

> But that can probably be chalked up to the virtual serial going over
> virtual Ethernet on a
virtual machine...!

Probably nothing wrong with your code. but whose to say... there's more than
one one way to peel an apple or a banana tho'.

If I could I would opt for a shell solution just for the funnery of it
rather than use some lame old BASIC program that make ML calls. Or an Aztec
C SYS program simply because that would be a little bit elegant. To me
anyway.

Bill

[Bill Buckels]

"Bill Buckels" <bbuc...@mts.net> wrote:
> an Aztec C SYS program simply because that would be a little bit elegant.

Or an Aztec C Shell Utility because its tinier...

Here's a snippet from the one of the programs that I posted which builds a
list from a folder. This could also be a copy script writer for the shell...
so cp could be called one file at a time to just do the work. Not likely to
blow-up then.

It wouldn't take me long to knock this together either if there were any
interest in using the shell... I mean when you look at all this it's pretty
trivial... at least when you compare it to the stuff you guys are doing...
and why anyone who works in some kind of unix would be happy with a BASIC
interpreter is beyond me...

int fixlist(pathname)
unsigned char *pathname;
{

unsigned char oldpath[65], workpath[65],
filename[17], *ext = NULL, *f=NULL, *ptr;

int i, j, err = INVALID;

if (pathname[0] != 47) return INVALID;
for (i = 1, j = 2; pathname[i] != 0; i++, j++) {
if (pathname[i] == 47) {
/* get last slash */
if (pathname[j] == 0) err = SUCCESS;
}
}

/* not a prefix so process as a file */
if (err == INVALID) return INVALID;

/* now returning success to avoid processing
any bogus prefix as a file */

/* save current prefix */
if (getprefix (oldpath) == -1)return SUCCESS;

/* try to set to new path - it might be bogus
and if it is so what! ...at least we didn't
add nonsense files to our list */
if (setprefix (pathname) == -1) {
/* safety play */
setprefix (oldpath);
return SUCCESS;
}

/* use a working copy of the prefix */
strcpy(workpath,pathname);
f = (unsigned char *)&workpath[0];

/* add files to our list if any */
if (findopen(f) > -1) {
while (findnext(0, ext, filename, &ff) == 0) {
/* skip sub-directories */
if (ff.type == 15) continue;
strupr(filename);
ptr = fnames[numfiles];

/* copy prefix to filename array */
strcpy(ptr,pathname);
/* concatanate "short" file name to prefix */
strcat(ptr,filename);

fdates[numfiles] = ff.mod_date;
ftimes[numfiles] = ff.mod_time;
faddrs[numfiles] = ff.address;
flens[numfiles] = ff.size;
ftypes[numfiles] = ff.type;
faccess[numfiles] = ff.access;

numfiles++;
if(numfiles < MAXFILES) continue;
break;
}
findclose();
}

/* restore original prefix
and carry-on */
setprefix (oldpath);

return SUCCESS;
}

[Bill Buckels]

"David Schmidt" <schm...@my-deja.com> wrote:

> That was pretty cool

If you think that was cool (he was just being polite I think), here's
something you can download that should do the trick without crashing
(hopefully):

http://www.aztecmuseum.ca/CPLIST.zip

It uses redirection to file in the Aztec C Shell to build a copy script from
one or more prefixes, and afterwards you run the script to copy the files.
This can be expanded upon (I can be co-erced to play requests if someone is
going to use this stuff) but first let's see if it works with all this other
stuff you virtual guys have happening. We could also expand it to write a
shell script to duplicate a directory structure from one volume to another,
and stuff like that.

Anyway, read the source, run the utility, etc. One more thing... the script
it writes will not overwrite a file without prompting and will abort if the
volume is full and no more files can be copied. This can also be modified.
One more more thing... this is a command line utility.

ReadMe for cpd (copy directory)

This is a single purpose utility program for the Aztec C ProDOS Shell.

It is used to write shell scripts that can later be run to copy files to the
current directory.

This may not seem like much (it isn't) because it's a test program.

Here's how it works:

cpd /PREFIX1/ /PREFIX2/ /PREFIX3/ > my.script

The above creates the script. To run the script in the shell, simply type-in
the script name and press RETURN.

That's all folks.

Bill Buckels
July 2013

[Hugh Hood]

Ivan,

Much like the programs Benoit discussed, Glen Bredon's PROCMD package of
BASIC.SYSTEM external commands includes a COPY command.

The package is here:

<ftp://ftp.apple.asimov.net/pub/apple_II/images/gs/utils/PROCMD.po>

The docs are included in a text file on the disk, BTW.

I've used it in some of my BASIC programs to allow/force a user backup.
Heck, it even works with stuff run through the Beagle Compiler.

OTOH, it doesn't have the 'bells and whistles' of Benoit's stuff, and it
won't do directories.

Regards,





Hugh Hood



in article cb09afd6-010f-4201...@googlegroups.com, Ivan X at
iv...@ivanx.com wrote on 7/22/13 1:47 AM:

[James Davis]

The <ftp://ftp.apple.asimov.net/pub/apple_II/images/gs/utils/PROCMD.po> address has changed. Currently, there are two different versions of it at: <ftp://ftp.apple.asimov.net/pub/apple_II/images/programming/basic/ProCMD v1.13.dsk> and <ftp://ftp.apple.asimov.net/pub/apple_II/images/programming/basic/ProCMD v2.21.po>.