Fish 'n' More 2/fishmore-publicdomainlibraryvol.ii1991xetec.iso/disks/disk374.lzh/Mat/Examples.DOC

Text File | 1990-10-08 | 12KB | 288 lines

                  Example Command Scripts using Mat
                  _________________________________

Included in this package are some example Shell scripts that demonstrate
some of the ways in which Mat can be useful.  You might even want to put
some of them -- or variants thereof -- into your own S: directory.
I've  had to omit one or two of the ones I use most, because they're
rather too dependent on ny own environment to be portable (or of interest
to anyone but me!).

There are scripts that emulate (with advantages) the AmigaDOS commands
PrintFiles and Search, one that does almost any kind of multiple file
renaming you might want, a utility for file counting, and so on.

Following are descriptions of the scripts and instructions for their use.
Look at the scripts themselves as well to see how they work.  Most of them
are fairly commented.

I will assume you are using the (AmigaDOS 1.3) Shell (or equivalent) to
execute the scripts as commands.  They all have the "Script" bit set.


PR      --  Print files with matching names

    This is a simple script that is in some ways more versatile than the
    PRINTFILES program supplied with the Workbench in that you can use
    pattern specifiers as well as plain file names (though -- unlike
    PRINTFILES -- you can only run it from the shell).  It runs in the
    background, sending the specified files to the printer (PRT:),
    separated by form-feeds.

    For example, to print all .DOC files in the current directory:

                PR #?.doc

    You can include up to five filename specifiers in the command line.
    These can include directory paths which in turn can contain patterns.
    To look through all the directories at the top level of df1: and print
    any files with DOC or README in their name:

                PR df1:#?/#?(doc|readme)#?


    Let's use this PR script to demonstrate some of the added features of
    Mat pattern matching.  (All these remarks and cautions about patterns
    and file specifiers apply to the other scripts as well.)  For a start,
    if you prefer "*" to "#?", Mat allows that instead (provided it is not
    inside quotes, where EXECUTE will misunderstand its meaning):

                PR *.doc

    If you want to print out all the files in the current directory that
    are NOT .INFO files, use:

                PR #?~(.info)


SCH     --  Search Text files for strings

    This script is a reasonable facsimile of the AmigaDOS SEARCH, except
    that it is much faster!  (The difference isn't quite as great as if
    you used Mat directly, due to the overhead of script decoding, but
    it is still usually a factor of two on reasonably long files -- the
    difference may be overwhelmed by disk access on shorter ones.)  It
    doesn't have all the switch options of the 1.3 SEARCH command, but it
    does attempt to reproduce the 'ALL' switch; the format of the output is
    different, though, and it can only handle five levels of directories.
    Note the use of the redirection character '>' as an option argument;
    unlike shell redirection, though, you MUST have a space between the
    character and the destination filename.

                SCH #?.DOC something

                SCH > result SEARCH something FROM df0: ALL


REF     --  Search Text files for strings

    REF is a slightly different approach to the SEARCH concept: the matched
    strings are highlighted. It runs in the background, and prints out
    everything at once when done.  [The script as supplied writes to a
    temporary file 'T:Ref_List'; you can look at this again with 'MORE' or
    something, but you could also easily change the script to make a more
    permanent record.]

    REF expects a simple string as the argument it is to search for (not a
    pattern).  You can use patterns in your file specifier to specify which
    are to be searched (as in SCH); up to three specifiers are allowed.
    All lines found that include the string anywhere within them are
    displayed, with the actual match section highlighted.  It assumes no
    upper/lower case distinctions are wanted. If you want different
    assumptions, use Mat directly (or rewrite REF). Don't forget to put
    quotes around your string if it contains spaces.

            REF "string search" #?.DOC

    would highlight all occurrences of the words "string search" in all
    the .DOC files in this directory.


MREF     --  Search Text files for patterns

    This is exactly the same script as REF, except that the string-search
    argument to Mat is omitted.  This means a) it can search for patterns
    as well as simple strings, and b) it is VERY slow!

    One example out of the endless possibilities should suffice:

            MREF "(pattern|string) match" #?.doc

    will find all the lines that contain "pattern match" or "string match"
    in all the .DOC files in this directory.

    Remember that the difference in speed between REF and MREF is due
    to the "triage" that the first one does with a string search for
    candidate lines, before matching and slicing.  You can write your own
    variant to suit your needs; for example you could have more flexibility
    by allowing separate string and pattern arguments, or you could add
    line numbers to the output.


REN     --  Global rename with pattern matching.

    This script I use a lot, but it needs more knowledge of Mat's pattern
    matching features than the previous ones.  The thing is that when you
    have the freedom AmigaDOS gives you in naming files (compared to
    certain operating systems on certain other machines that we will
    ignore...) you need much more than the "ren *.c *.bak" convention
    that suffices for those primitive systems; we have no "root names" and
    "extensions" to be treated as indivisible units.  To provide a general
    renaming facility we have to introduce concepts like "slices" and
    "templates".

    As an example, suppose I have some text files that all end in '.txt',
    and I want to rename these to, say, '--.txt_OLD'.  It happens though
    that they all have associated icons '--.txt.info' which will have to be
    renamed too, and if they are to remain WorkBench-accessible the ".info"
    string must stay at the end of the name.  So, how do we do this with
    REN?  Like this:

            REN #?.txt^#? AS ^0_OLD^1

    Yipes!  Whad'all'dat?

    OK.  So I jumped in at the deep end.  Be brave.  Let's look at the
    pattern first: it's fairly standard except for the little "^" that
    crept in after "txt"; this is a "slice mark" that indicates where we
    want to split up the matched string.  Each resulting match can be
    referenced in two parts: 1) everything up to ".txt", and 2) everything
    after that (this could be empty).  By the way, that mark is NOT
    produced with the CTRL key: all references to "^" here mean the actual
    caret character (aka "circumflex" or "hat") -- "SHIFT-6" on your
    keyboard.

    Then there's that very strange second command argument (the keyword
    "AS" is optional); those slice marks seem to crop up here again.  Only
    -- sorry -- this time they're not slice marks: this is a "template",
    and they -- with the character immediately following -- are
    "selectors".  The template indicates exactly how the matched string is
    to be rearranged (the script itself extends this considerably to do the
    actual renaming job, but don't worry about that here).  Breaking the
    template up, the first two characters are "^0"; this means "use the
    part of the match before the slice mark". Following this, "_OLD" is the
    literal string we want inserted at that point. Finally, "^1" means "use
    the rest of the match".

    As a result of this command, then, we would see this sort of renaming:

        myfile.txt          becomes     myfile.txt_OLD
        myfile.txt.info        "        myfile.txt_OLD.info
        any other.txt          "        any other.txt_OLD
        any other.txt_oops     "        any other.txt_OLD_oops

    That last renaming operation mightn't be part what we wanted, so in
    that case we would extend the previous command:

            REN #?.txt^(%|.info) ^0_OLD^1

    which would ONLY rename files that ENDED either with '.txt' or with
    '.txt.info'.

    Another common sort of renaming is not to add, but to change, a segment
    of the name:

        myfile.txt          -->     myfile.OLD
        myfile.txt.info     -->     myfile.OLD.info
        ...and so on

    For this, we need TWO slice marks:

            REN #?.^txt^#?  ^0OLD^2

    In this case "^0" refers to the match up to the ".".  "^1" is the piece
    between the first and second slice marks -- i.e. "txt".  It doesn't
    appear in the template this time -- it is discarded and replaced by
    "OLD".  "^2" is now the remainder of the match following the second
    slice.

    Of course the renaming job is often simpler than this.  For example to
    move all your '.c' files to an existing subdirectory 'old', just use:

            REN #?.c old/^F

    "^F" is the selector for the original file name, so this just prefixes
    "old/" to it.  And you can always reduce to the basics:

            REN myfile yourfile

    (The script detects that there are no template markers, and simply
    calls the RENAME command.)

    All simple now?  ..It gets easy with a little practice.  For the whole
    story on slicing and templates, read Mat.DOC.


FILECOUNT

    This script will either count all the files matching a specifier:

                FILECOUNT work:test/#?.c

    or -- with the first argument representing a selection pattern --
    count both the number of files matching the selection pattern and
    the total number of files searched:

                FILECOUNT #?.c work:test/#?.(c|h)

    In this second mode (but not in the first, because of key identification
    problems) you're allowed up to five specifiers.


LINECOUNT

    This reports the number of lines in each file matching the spec.
    (It uses a bit of a kluge -- a nonsense pattern that should never
    match -- to do it.) Again you can have up to five specifiers.

                LINECOUNT work:test/#?.c


PATHS

    "Path Save"  -- Creates an executable script file (by default named
    "re-path"; a parameter to the command will be used as the name if
    supplied) that when invoked will reset the path to what it was when
    PATHS was executed.  This script also uses a PIPE: (though it could
    work only slightly less conveniently with a temporary file).  Notice
    how Mat's negated match ability is used to prevent unwanted addition of
    "C:" and "Current Directory".


SASS

    "Save Assigns" -- creates a script file that will re-assign all
    NON-System Assigned Devices to what they were when SASS was executed.
    (Any existing, non-conflicting assignments are left undisturbed when
    the script "re-assign" is executed.)  Normal system assigns -- like
    "SYS:" and "C:" will not be recorded in the script (again managed by
    Mat's negated match).  Again too this uses PIPE:s, but also is the only
    script that requires an auxiliary program, "ElideS", to be on the path.
    This program is a trivial space compactor that lets us bypass Mat's
    difficulty with variable spaces.  For your own interest you might want
    to convert this into a script that UN-Assigns all non-system
    assignments (left as the proverbial "exercise for the reader"...).


MAKEDEP

    You may find this one useful if you write C programs.  It scans
through the set of source files represented by the specifier, and creates
a set of target dependencies (for the headers included in each file) in
the form usually required by the "make" utility.  It is not as smart as
some of the custom programs that do the same job, in that it won't look
at "includes of includes" -- you'd have to do that bit by hand -- but
it's adequate for a lot of needs.  Like SCH, it uses the redirection
character '>' as a keyword argument to redirect the output to the
appropriate file (it just displays it if omitted).  It assumes that all
the files it is to search have names ending in ".c"; you can leave the
extension part off if you like, and it will be added:

                MAKEDEP > makebase my#?.c

                MAKEDEP > makebase my#?


                            %%%%%%%%%%%%%%%%%