atari email archive

a collection of messages sent at Atari from 1983 to 1992.

Give a man enough rope...

(1 / 1)


    For those of you who like to screw up more than one file at a time,
here's a way to have a real orgy.  NO WARRANTIES EXPRESSED OR IMPLIED,
NOT RESPONSIBLE FOR CONSEQUENCES ARISING FROM USE OF THIS PRODUCT.  THIS
TOOL IS GUARANTEED NOT (repeat NOT) TO WORK AS ANTICIPATED, AND WILL
(GUARANTEED) SCREW UP AS MANY FILES AS POSSIBLE.  This is a product of
Murphy's Awfullest Designs, guaranteed (only) to drive you M.A.D.

    Now that the disclaimers are out of the way, let's proceed.

    There are occasions to do batch processing (even on DEC computers) of
a number of files.  I have written a command file to parse a wildcarded
file specification, and iteratively process each file matching the spec
for those commands where wildcards are not appropriate.

    An application example:

    Recently it was rediscovered (by several people) that DECNET does not
support STREAM-LF files (the only kind C likes).  (The bad news is that
it will continue to not support them, even in version 4, coming to a vax
near you sometime in 1985.)  DECNET requires major revisions for this, and
Dave & I are not able to supply these changes as patches, so until DEC fixes
the source code, C and DECNET won't like each other.

    The good news is that there is a workaround.  When you EDT a stream-lf
file, a variable-length/cr file is created for output.  DECNET LIKES these
files  (I can't speak for C programs from practical experience).  So, a
mass conversion was needed.

    The example:

    First, a file was created (say EXIT.EDT) containing the line "EXIT" only.
Then the symbol PROCESS was defined to be "EDIT/EDT/COMMAND=EXIT.EDT".  At
this point, we can say in dcl, "$PROCESS file" to change said file from
stream-lf to variable.  Now "$@SYS$SYSDEVICE:[UTILITIES.COM]DOFILE *.OL"
is executed, which will PROCESS each .OL file (the latest version only).

    I have a symbol defined for this, but you may not want to do that because
of how dangerous this could be.  You can be assured that the command file
(DOFILE, that is) checks to make sure that PROCESS is defined.  However, once
you define it, it stays defined until you log out or do a $RESTART.  So if you
convert *.OL, for example, and then (accidentally) $DOFILE *.*, you will have
a real mess.  Avoiding the symbol definition for DOFILE is one way to make this
possibility even more remote.

    DOFILE is not limited to "doit toit" commands.  For example, a mass
rename or copy might be done by a command file, and PROCESS be equated to 
"@commandfile" in order to provide the linkage.  The command file might
then contain "$COPY 'P1' LQ0:".  Incidentally, don't experiment with this
particular example.

    There are some other potentially destructive command files that I might
release if this one doesn't come back to haunt me.  It is potentially very
useful as well as disastrous, and I leave the protection against yourself
entirely up to you.

    As always, should any of your files be caught, or killed, the backups will
disavow any knowlege of your data.  Good luck, user!

sas
Message 1 of 1

Dec 21, 1984