C-Kermit 7.0 Case Study #05

[ Previous ] [ Next ] [ Index ] [ C-Kermit Home ] [ Kermit Home ]

Article: 10896 of comp.protocols.kermit.misc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Case Study #5: Directory Recursion
Date: 11 Jan 2000 22:11:47 GMT
Organization: Columbia University

Today let's look at another new C-Kermit feature: directory recursion.

What's recursion? "In order to understand recursion, first you must understand recursion." (That's the joke that CS professors always use to introduce their first lecture on recursion.) As far as directories are concerned it's the familiar idea of thinking of some particular directory as the root of a tree, and then having a way to refer to (visit, list, send, ...) all the files in all the directories within the tree. For example, as we do in DOS with "DIR /S", in Unix with "ls -R", or in VMS with "dir [...]".

Now C-Kermit can do this too. To see directory recursion in action, start C-Kermit 7.0, CD to a directory that has some subdirectories (which in turn might have their own subdirectories, etc), and give it the following command:

  directory /recursive

This, by the way, illustrates not only directory recursion, but also C-Kermit's new built-in DIRECTORY command, and the idea of "switches", or command modifiers. In this case "/recursive" is a switch. The DIRECTORY command has lots of other switches too; type "dir ?" to see what they are, and "help dir" for a short description. As with any C-Kermit command, you can abbreviate keywords (and switches are a kind of keyword) to any length that distinguishes them from any other keyword that can appear in the same position (and you can always get a list with "?"); for example:

  C-Kermit>dir /r? File specification;
   or switch, one of the following:
   /recursive  /reverse
  C-Kermit>dir /rec

Try "dir /rec" from different directories to see how it works. The key idea of recursion is that it repeats itself indefinitely until it runs out of things to do; in this case, until it runs out of subdirectories to visit.

The most important application for directory recursion in Kermit is file transfer. C-Kermit's three main file-transfer commands -- SEND, GET, and RECEIVE -- each now include a /RECURSIVE option (switch), among many others. When you include it, you can send or receive entire directory trees, rather than just one or more files from a single directory.

Some of you might be wondering: "What's the big deal? I could already do that by making a Tar or Zip or Backup (etc) archive and transferring it." True, but in general this only works between compatible platforms, and Kermit always likes to handle the general case and promote and embrace diversity :-)

When moving text files between different platforms, it is usually necessary to convert their record format and/or character set. Zip (but not Tar or Backup) can take care of record-format conversion if you tell it to, but there is usually no good way to mix text-files-to-be-converted and binary-files-NOT-to-be converted within an archive. No known archiving or file-transfer method besides Kermit handles character-set conversion, but this is important to anybody who writes in any language besides English (or Dutch or Latin) and needs to move files between platforms that use different character sets, such as Windows and Unix.

In yesterday's posting we saw how C-Kermit can go through a group of files and automatically switch between text and binary mode for each file. You can test this feature without transferring any files with the command:

  directory /xfermode [ filespec ]

This adds a notation "(T)" or "(B)" to each file whose name matches a Text or Binary pattern, and therefore will be sent in the corresponding mode; the rest are sent in the prevailing mode, which is binary unless you changed it. Now when you give a SEND /RECURSIVE command, C-Kermit sends each file, switching between text and binary mode automatically. When it encounters a directory, it enters the directory and sends files from it; when sending files from a lower directory, the pathname (relative to the original directory) is included in the name that is sent to the other Kermit; the process repeats for all directories in the tree. The other Kermit uses the path information to replicate the original directory tree. This works if each of the two Kermits is C-Kermit 7.0, Kermit 95 1.1.17 or later, or MS-DOS Kermit 3.16 (currently in Beta test), and it works between any combination of Unix, DOS, Windows, OS/2, or VMS. File dates are preserved and, except in DOS-like file systems, so are file permissions (within reason). I think this is a first.

By the way, just because you include the /RECURSIVE switch on a file-transfer command doesn't mean Kermit has to transfer ALL the files in the directory tree. Of course you can give a filename or wildcard (or list of them) to select certain files, and there are also lots of new file-selection criteria available on each end; files can be selected by date, size, etc, and checked against exception lists. For a quick idea of what's possible, here's a list of the new SEND switches:

 C-Kermit>>send ? Filename, or switch, one of the following:
  /after:         /except:        /nodotfiles     /recursive
  /array:         /filter:        /not-after:     /rename-to:
  /as-name:       /filenames:     /not-before:    /smaller-than:
  /before:        /larger-than:   /pathnames:     /starting-at:
  /binary         /listfile:      /print:         /subject:
  /command        /mail:          /protocol:      /text
  /delete         /move-to:       /quiet
  /dotfiles       /nobackup       /recover
 C-Kermit>send

You can combine all this with the SET FILE COLLISION feature at the receiver to achieve all sorts of effects. Perhaps the most useful in this regard is SET FILE COLLISION UPDATE. This lets you run the same transfer periodically (say, every day, week, hour, whatever) and transfer only those files in an entire directory tree that changed since last time; thus synchronizing two directory trees, even if they are on incompatible file systems, even if they contain a mixture of text and binary files, even if the text character sets are different.

Well, this was a bit long, but even so it only scratches the surface. For more on this topic, see the C-Kermit 7.0 Supplement:

- Frank

[ Top ] [ Previous ] [ Next ] [ Index ] [ C-Kermit Home ] [ Kermit Home ]


C-Kermit 7.0 / Columbia University / kermit@columbia.edu / 11 Jan 2000