Black Box 4

home *** CD-ROM | disk | FTP | other *** search

/ Black Box 4 / BlackBox.cdr / fileutil / cf.arj / CF.DOC next >

Wrap

Text File | 1991-02-18 | 66.6 KB | 1,226 lines

CF VERSION 0.9X CF - A PROGRAM FOR COMPARING DIRECTORIES ======================================== NOTES ----- (a) The key assignments have been substantially altered in this version - see the short help file (CF.HLP) for the latest list. (b) The version history is now in a file called CF-HIST.DOC and the order of the entries has been reversed. (c) I'd like some feed-back. If you use CF, then tell me! Otherwise, development of it will stagnate and no bugs will be fixed. (Mind you, if you DO drop me a line / fax / call / poke-in-the-eye, brevity is appreciated.) (d) See the disclaimer at the end. (Warantee? What warantee? HOW much did you pay for this? Unless you've been ripped off, the answer is "sod all"...) INTRODUCTION ------------ CF is a program that will compare the date, time and file sizes of a number of files in different directories (or "file sets") and highlight the latest (and, possibly, the earliest) file. It can do this comparison between different machines that are NOT net-worked. Towards the start of 1990 I purchased (not "invested in"; why do otherwise normal people, when buying a computer to play with, have to "invest in" it, rather than BUY it?) an NEC PowerMate SX. One of the programs that I wanted to write was a directory comparing program. Luckily, before I started development, I came across the free PC-Magazine utility, DirMatch. It quickly became apparent that it didn't do everything that I wanted - although DirMatch compares directories perfectly well, my requirement was to be able to compare directories on DIFFERENT machines - in a development environment, it is common to have many people, using different machines, working on the same system. Clearly, it is desirable that they work with the SAME set of program sources. As system integrator and generator of release versions of our software, it was imperative that I use only the LATEST versions of each module. Hence, I wrote this program, "CF". So, how can I easily compare program sources on different machines? The obvious answer is too copy a complete set of the sources on the second machine and use DirMatch. But, our system comprises well over five mega- bytes of source in nearly 300 modules. So, what can we do? Well, most PC uses have come across the MS-DOS command, "DIR". So what's wrong with redirecting the output from DIR to a file, and compare a like file from MY machine? The hard part (find out which files are different, and which is the latest version), is left to CF. It quickly became apparent that it would be nice if programs, other than DIR, could be used for the directory compare. So, since the process of recognising the different formats was a simple matter, I laid my hands on as many programs that I could, that produce DIR-like output, and put in code to recognise them. The current list is as follows: SUPPORTED SOURCES ----------------- Program Version Author/Publisher Directories MS-DOS 3.3 Microsoft DIR MS-DOS 3.3 and 3.2 Microsoft DIR OS/2 1.0, 1.1 and 1.2 Microsoft DIR 4DOS 3.0 and 3.02 J. P. Software DIR DR DOS 5.0 Digital Research ARC 5.12 and 5.20 System Enhancement PKARC 3.6 PKWare PKPAK 3.61 PKWare PKZIP 1.01, 1.02 and 1.10 PKWare PKZFIND 1.00 PKWare XTREE 2 Executive Systems XTPRO 1.0 and 1.1 Executive Systems XTGOLD 1.3 and 1.44 XTree Company SWEEP 1.0 Strange Software FV 1.16, 1.28 and 1.32 Vernon Buerg FF 4.5 Peter Norton FI 4.5 Peter Norton HDIR 2.1 Overfield/Woeger MAGELLAN 2.0 Lotus Development Corp FASTBACK 1.01 and 2.10 Fifth Generation Systems NBACKUP 1.1 Peter Norton DSBACKUP 2.4f Design Software PCTOOLS 6 Central Point Software LHARC 1.13c Haruyasu Yoshizaki XDIR 1.41 (DR DOS 5.0) Digital Research CF Current Yours truly... Notes: (a) CF will identify PKARC listings as "PKPAK" since the file layout is the same. (b) Likewise, CF will identify MS-DOS 3.2 DIR output as "4DOS". I implemented 4DOS recognition before obtaining an MS-DOS 3.2 DIR listing. I assume that the 4DOS DIR command emulates MS- DOS 3.2 output because it was written before MS-DOS 3.3 was available. (c) CF only accepts the single or double column layout from HDIR and the 4DOS version of DIR. (d) With ARC, only the "V" option is supported since the "L" option listing does not include the time. Also, ARC does not give file locations. If ARC output is appended to another program's output, the location of the ARC files will be wrong. If the ARC output is in a separate file, however, it will be correct (that is, missing), since the location is set back to a "?" each time a text file is opened. (e) See the note later on using CF output as input. (f) CF will only accept output from MAGELLAN if the options have been set to use a date format where the YEAR comes FIRST. CF can cope with both time formats. (g) PKZFIND is a bit of a strange beast. Like MAGELLAN, just to make things as awkward as possible, it has variable column layout. However, with MAGELLAN, I KNOW that the output is from MAGELLAN because part of each file path is in the same column. Unfortunately, with PKZFIND, I cannot do this since it sometimes leaves the leading drive letter out. Thus, the PKZFIND recognition is not as good as that for the other programs. Since I cannot RELIABLY detect PKZFIND "funny layout" output, I have decided to ignore any PKZFIND lines that do NOT have the date, time and size information in the "default" columns. In other words, CF will ignore PKZFIND output if the file path names are too long. (CF will give NO warning if this happens.) For the same reason, I cannot detect the path strings if PKZFIND is used in the "ZIP only" (-Z) mode. The paths come out as a "?". Finally, in the (default) mode of "all files" (that is, not -Z and not -N), CF will include the size of any .ZIP files, along with the sizes of all files contained therein. For example, if you PKZFIND a .ZIP file of 100k, that contains 300k of files, CF will report a total file size of 400k - it adds ALL of the sizes together. I can only recommend that if you have any OTHER program that you can use, to produce input for CF, then USE it. PKZFIND produces singularly un-helpful output, as far as CF is concerned. Sorry, but it's the best I can do. (I suppose you could blame PKWare for this. Mind you, they more than redress the balance by giving the world .ZIP files, don't they?) (h) Do not take a program's appearance in this list as a recommendation for use - it might be in this list, but this DOESN'T mean I either use it or recommend it. For example, there is no way I'd use ARC in preference to PKPAK or PKZIP - ARC is there merely because somebody, somewhere may STILL be using it. (Yes, it DOES seem unlikely, doesn't it?) CONCEPTS -------- The parameters may be in any order. They are case insensitive, and come in three flavours: file "sources", local parameters and global parameters. At start up, all of the parameters are processed, and all global parameter actions are performed. Therefore, global parameters do NOT have to come before the other types. Global parameters are preceded by a minus sign or a slash (what a surprise). They may NOT be strung together - each must have it's own minus or slash. Local parameters only apply to the following file name or directory name. For example, with the -D option (descend directories), only the next directory name will be recursed - thereafter, directories will NOT be recursed unless they, too, have a -D before them. Finally, all other parameters are considered to be either the names of MS-DOS directories, or text file output from other programs, or re-directions of same. In fact, there are two parameters that fall half-way between a global parameter and a local parameter. These are the file name "filtering" parameter, -F, and the parameter redirection facility. The -F applies to ALL of the following file sources, but any further -Fs will override all earlier ones. More on this parameter later. The second exception is parameter redirection. This allows you to specify a file that will be scanned and have the contents placed into the parameter list. These may be nested to a depth dependant upon the number of files that MS-DOS will allow you to open and the amount of free memory you have. The syntax is simple; if you want to load parameters from FRED.TXT, use something like "CF @FRED.TXT C:". You may put an entry like this into your .INI file. (See see the CONFIGURATION section for details of the .INI file.) For example, if you'd put "PARAMETER @FRED.TXT" into your .INI file, the previous command line could read "CF C:". The .INI will be scanned and the redirection automatically applied. If the redirection file cannot be found where it was specified and it is a bare file name WITHOUT a path, CF will search in the start-up directory. In the following discussion, I use the term "file set", to mean a collection of file details that will be compared. Thus, if you want to compare, say, the files in your current directory, with those of the parent directory, there will be two file sets. One will be the set of files "*.*", and the other will be the set of files "..\*.*". An example, if you want to do the above comparison, you could use: (1) CF . .. Simple enough, eh? (But see the BUGS section for details of a CF problem in this area.) Of course, this example would be better off done using DirMatch - it's a smaller program, it uses less space, and it runs faster. However, what if you want to compare all of the files in your local directory with the same files on another machine? The answer is, you could use CF. First, a DIR would have to be done on the other machine, and redirected to a file, X.CF, say. Then, transfer it to your machine on a floppy and use CF: (2) CF . A:X (Note that, from now on, I have assumed that CF will automatically recognise that you want "X.CF", say, when only "X" is specified. To find out how to make CF do this, see the CONFIGURATION section.) This would produce a display showing the file names and two columns (that is, file sets) of dates and times. The latest of each file will be highlighted in red. If the files have the same date and time, then NEITHER will be highlighted. (Note that this is opposite to the action that DirMatch takes - DirMatch would highlight BOTH files.) If you want to have CF combine the output of several different text files into ONE file set, use the local parameter, "+", between them. (Spaces either side, please.) For example, if, in the above example, the directory listing on the second machine was redirected into two separate files, X.CF and Y.CF, the command line would have to be: (3) CF . A:X + A:Y Any combination of file names and directory names can be used. For instance, this is a legal CF command line: (4) CF X + Y + Z A + B + C . + .. This would compare the file sets comprising the files in X.CF, Y.CF and Z.CF, the files in A.CF, B.CF and C.CF and the files in the default directory and it's parent. CF deduces the source program that produced the listing on a line-by-line basis. Thus, in example (3), above, the two files could have been concatenated on the second machine BEFORE transfer to a floppy disk. In fact, the output in a single text file can come from any combination of the programs mentioned above. Thus, a DIR listing could be appended to the output from PKZIP and then submitted to CF. NOTE: Since I wrote the last paragraph, I've found that the layout of PKZIP has changed between versions 1.02 and 1.10. (The order of the day and month fields has been swapped.) The difference is *NOT* detectable on a line-by-line basis. To cure it, I added code to detect the PKZIP sign- on message, and this saves the version number for later use. Therefore, if you are submitting PKZIP input to CF, make sure that it is preceded by the sign-on waffle. If no sign-on is detected, CF will use the last PKZIP version it came across. At system start-up, it defaults to "1.10". Besides the date and times of the files in each file set, CF lists file name (that helps...), and the file "number". This number is just a record number for your reference - when displaying selections of the files in your file sets, they may not be consecutive and, indeed, large gaps may exist. At any time, one file in one file set is highlighted with a large "cursor". This cursor can be moved to a different file name using the up and down arrow keys, or to the same file in a different file set using the left and right arrow keys. You will see, as the cursor highlights a different file, that, near the bottom of the screen, the size of the file, it's date and time, and it's "location" will be displayed. (More on the "location" of a file, later.) After the date and time of the file, you may see another entry enclosed in parentheses. This is the size and time difference between the current file and the "latest" one found. If there IS no entry, the size and time match the latest. By the way, if you are viewing the duplicate entries, the difference is between the latest duplicate (that is, the one you would normally see on the screen) and the currently viewed duplicate. Try it out - I think you'll get the idea. If the file only differs in size, there will just be a number enclosed in parentheses. If the size difference is positive, this indicates that the file is LARGER than the "reference" file and vice versa. If the time also differs, the size difference will be followed by the time difference in (possibly) days, hours and minutes. As well as the difference fields, in the extreme bottom right-hand corner of the screen is an indication of WHICH duplicate you are viewing. The second number (after the slash) is just the total number of duplicates for this file. The first number indicates which is on view - a value of one indicates that this is the latest of the duplicate set. (That is, the field will hold the value one when the normally displayed record is selected.) The cursor can be moved through the file list using the keys you'd expect - home, end, ctrl-home, ctrl-end, page-up and page-down. It also wraps around, both vertically and horizontally. At the top of the screen, you will see the version number of CF, and the list of files that were the source of each file set. In example (4), you would see the strings "X.CF+Y.CF+Z.CF", "A.CF+B.CF+C.CF" and ".+..". (During the loading phase CF displays a count, of free DOS and EMS memory, in this area of the screen.) They will be truncated if the date and time field width is too small to hold the complete string. For each file record, the file sizes either will, or will not, be displayed, the date will be in either long or short format and the cursor will be either locked or free. The default date size and whether the file sizes are included, or not, depend on the number of file sets loaded - the more sets, the less information that can be displayed about each file. They can be changed, however, but CF does NOT check for line overflow - "caveat user", as it were. If the cursor is locked, then this means that it will NOT be permitted to highlight a none-existent file. In other words, if one file name does not appear in one of the file sets, the cursor will skip to either the left or right. Under the CF version number text, you will find the current the "selection mode" displayed. CF only displays the files that qualify, depending on this mode - if no files qualify in a particular mode, then that mode will not be represented in the list. The default, unless over-ridden with a global parameter, is "All". In other words, all loaded files are displayed. "Same" means that only files that exist, and are the same date and time, for all file sets, will be displayed. "Different" files are those that are, for some reason, different - either it does not exist in one or more file sets, or the sets disagree about the date and time, and so on. When CF is loading the file details, it may find that it already has details of a file with the same name. In this case, it makes a decision, based on the date, time and size of the files, and picks the latest (or largest) file. This file would then be considered to have been a duplicate, and the mode "Dup" displays only those records where one of the file sets has a duplicate file in it. Select mode "Only" is for files that exist in at most ONE file set and "Name" is the opposite of "Only" - it selects the files that appear in at least two. Finally, the last three select all files that have a "low-lighted" file, all files that have a high-lighted file and all files in a particular file set, respectively. (DirMatch has an equivalent for only three of CF's modes - "Same", "Different" and "Name".) High-lighted files are those with the latest date and time - if more than one file has the latest date and time, then more than one will be high-lighted. (CF uses the date, time AND file size to determine the "latest" file. The size is ONLY used if the date and time are the same. The larger file is considered the latest.) Note that the seconds field is not used - many programs do not list the seconds in their output. Low-lighted files have the earliest date and time. Note that low-lighted files are only displayed if at least three different date and times are represented - otherwise, with only two file sets loaded, EVERY file would be high-lighted or low-lighted. In order to use the "all in this file set" mode, you must FIRST place the large cursor on a file in the set you require (it does NOT have to be over an existing file - that is, it can be over a blank space). THEN use the tab key, or whatever, to get into "this set" mode. CF will then only display records that have at least one file in the selected file set. Also, note that the selected file set has it's source string high-lighted at the top of the display. Right, earlier I mentioned "locations". This is NOT the same as the "source" of the file set. In example (1), the sources are "." and "A:X.CF+A:Y.CF". However, the LOCATION is the directory in which the file resides on it's "home" machine. For example in (1), I assumed that the files existed in directories of the same name, but on DIFFERENT machines. Hence, the SOURCES are different (one comes from the floppy text file, the other from the MS-DOS directory), but the LOCATIONS are the same. (Instead of trying to explain it - try playing with CF. I'm sure you'll get the idea.) PARAMETERS ---------- Ok, I think it's time to list the parameter options. The "type" field is 'G' for a global, 'L' for a local and is neither for the -F option. Remember that a "/" can be used instead of "-", if you like. Type Param Meaning ---- ----- ------- G -SE Sort by extension instead of root name G -SL Sort output by location (sets -B) G -TD Switch date display mode G -TS Switch size display mode G -TC Switch default cursor lock mode G -TO Use colours for a monochrome screen G -TK Enable key-board buffering G -TB Batch mode - intended for re-direction G -IL Inhibit storage of location strings G -IM Inhibit use of EMS memory G -IX Inhibit use of XMS memory G -ID Ignore dates when high-lighting records G -IT Ignore times when high-lighting records G -IS Ignore sizes when high-lighting records G -IE Ignore file extensions G -IU Ignore details of duplicate files L -C Don't store file details - read contents L -P Pause until key-press L -D Descend directories L -W Switch day/month fields of next source n/a -F<pattern> File name "filter" pattern G -Y<filename> Make <filename> the temporary file name G -M<letter> Switch start-up selection mode (<letter> is one of A,S,D,U,O,N,L,H or T; if the letter is 'T', then a file set number can follow) G -V<mode> Change to specified (decimal) video mode L + Directs files into the previous file set L {<number> Loop until following '}', <number> times L } Loop terminator The -SE option forces CF to store the files in extension order. That is, it uses the three characters, in a file name, that appear after any dot in the name. The batch option, -TB and -SL, should be used when the inter-active part of CF is to be skipped. The -SL option is the same as the -TB option, except that if a single file set is listed, the output comes out in LOCATION order. This is much slower than the ordinary -TB, but if this file is subsequently loaded back into CF, it loads quicker and can save a significant amount of memory. In batch mode, CF does not display the interactive screen, but just prints the screen out to standard output so that it can be re-directed to a file, or something. Each file, in the batch output, is flagged, after the file date and time, with an asterisk, dot or space. The latest file is flagged with an asterisk and the earliest is flagged with a dot. Other files just have a space instead. If the line contains any file that has an asterisk or a dot instead of the normal space, then the first character of the line will be an "arrow" (in fact, a greater-than symbol) so that they are easy to pick out if the majority of files in the output have the same date and time. Note that the output from CF can only be read back into CF if it was produced with only ONE file set loaded. Note that, at present, duplicate file details do NOT appear in these listings. The -M option just allows the user to specify what mode CF will change to after loading the files. It should be used with -TB to get a listing of a particular format. Note that the form -MT<number> can be used; this will start the system in "all in this file set" mode, using file set <number>. If <number> isn't present, it defaults to the first file set. The display mode parameters, -TD and -TS, affect the start-up display mode of the the date and size fields respectively. Note that the DEFAULT display mode, toggled by the -TD and -TS parameters, depends on the number of file sets that are loaded. Use the -IL option if you are getting short of memory. CF will NOT store the location strings and thus save memory. The -IM option was included in case the detection of EMS caused any problems. Also, CF should, in theory, run a little faster if EMS is disabled. Of course, using this option will increase the amount of DOS memory used. The -IX option was included for the same reason as the -IM parameter - to ensure that you could still use CF if the DETECTION of a facility, that you didn't have, caused your system to crash. By the way, of the three types of XMS memory (High Memory Area, Extended Memory Blocks and Upper Memory Blocks), CF only uses the UMBs. The "switch cursor mode" option was included for completeness. After all, - TD and -TS were there; why not -TC as well? I added the -ID and -IT options just because it was easy and I found a use for them; I'd recompiled our system, and generated the .EXE file and all of the overlays. The program was a few hundred bytes bigger and I wanted to know why. Since I'd kept an old copy, what I REALLY needed was a version of CF that ignored dates and times (since the last system I generated would always be the one high-lighted), and only used the SIZE of the files. In this way, I could see where the increase in size had come from. (Finding out by inspection was error prone - we have fifty overlays in our system.) So, I slapped the -ID and -IT options into CF. The -IS option was a natural extension of this idea. If you do not explicitly select the monochrome colour scheme, via the -TO option, CF will decide for itself whether to use mono colours, or not. The normal colour scheme is red for the latest file(s), blue for the earliest file(s) and normal video for other file(s). The settings colour, at the bottom of the screen, is in green. For monochrome, the "colours" are high- intensity, underlined, normal video and high-intensity, respectively. While on the subject of video modes, a few words on screen size; I would have preferred to have supplied ONE copy of CF that coped with ALL screen sizes. However, until I manage to brow-beat JPI (the Modula-2 compiler writers) into supplying libraries that automatically take care of screen size, I have to supply CF.EXE (25 lines), CF43.EXE (43 lines) and CF50.EXE (50 lines). Unfortunately, the present JPI libraries have the value, for the number of columns on the screen, buried in the depths of some assembler code. While I could alter this code, I'd rather just limit CF to 80 columns, for now. (I MAY convince JPI, yet - we are a beta-test site for their compilers, and, in the development of out project we, too, required our code to run on ALL screen sizes (well, up to 200x100, anyway). So, I patched a few of their library sources to do this. In long run, this not a desirable scheme - every time they release a new version of their compiler, I'd have to re-convert any new libraries. If JPI see our product, maybe, just maybe, they'll decide that it would be a good idea to alter THEIR copies of the libraries.) NOTE: As you may, or may not, have noticed, I HAVE altered the JPI libraries to cope with any screen size from 40 x 25 up to 200 x 100. However, since I still feel that JPI ought to adopt this scheme, I've left the above comments in. By the way, you must already BE in the video mode that you want to use - CF will NOT change mode for you. The -D should be used when you want CF to traverse sub-directories to find files. For example, the source "-D \" would all files on the current disk. Note that this is a LOCAL parameter. Some programs take notice of the country code, or other flag, to decide on field order for dates. For example, in the USA, the normal order is MM-DD- YY, whereas here in the UK it is DD-MM-YY. Since CF has no way of knowing the format used to CREATE a text file (rather than the CURRENT date format), I've added the -W switch. Setting this local parameter will make CF switch the day and month fields of all files in any text file read. CF does NOT do this swap if reading directly from an MS-DOS directory. The provision of this parameter is a kludge - CF still won't be able to cope with output in YY-MM-DD order, if it normally expects it to be in USA or UK format. (Note that CF works fine with the country code set to "UK", of course, because of the environment under which I develop the program.) CF does NOT buffer keys unless the -TK option is selected. The trouble with buffering keys is that, if you keep your finger on, say, the page-down key, and you see a file go by that you want a closer look at, releasing the key will do no good - DOS will have buffered up 16 down-pages and you'll just have to back up. The "ignore file extensions" option, -IE, was added, like the -ID and -IT options, because I had need of it when trying to save space on my hard disk. I have a directory, \OVL, with nearly 300 object (.OBJ) files, and another, \MOD, with a similar number of source (.MOD) files. The question is, is there a .OBJ for each .MOD? If there is no corresponding object file, then that module isn't being incorporated into out system when it is built. If there is no source file, either the object file is from a library module, or we've removed the module and forgotten to delete the old object file. There is one little problem when using the -IE option. The "name mode" only looks to see if there is more than one file in the current record. When NOT using the -IE, this is ok, because all of the file sets, in a given record, have EXACTLY the same name. However, when using the -IE option, this is no longer true - in the above example, one could be, say, P2.OBJ and the other P2.MOD. These definitely do NOT have the same name, although the "root" (the bit before the dot) IS the same. For now, I've elected to do nothing about this problem, other than add code to make CF warn you when you select this combination of mode and option. If you find that CF has detected duplicate file details, you can use the RETURN key to cycle through the ones that didn't make it to the screen. (That is, they weren't the "latest".) In order to save space, you can use the -IU option to instruct CF to ignore duplicate details. The files will still be highlighted as duplicates, but you won't be able to view the other file details, because CF will not have stored them. CF can now accept wild-card file names. Normally, with DOS programs, there is no ambiguity involved. But consider the file name "*.CF". If CF sees this, should it log the details of the .CF files, or should it READ the .CF files and log the CONTENTS of them? I have coded CF to default to the former action, but you can use the -C option to make CF take the latter course, instead. Note that -C is a local option. For a discussion of the -SL option, see the text above that describes the -TB option. Using the -P option makes CF pause, after displaying a suitable message, until a key is pressed. Use this before multiple logs of a diskette drive, while inside a loop. The use of the + option is explained above - just place it between all sources that should contribute to the same file set. The looping parameters are primarily intended for logging multiple diskettes. For example, if you want to log four floppy disks, into separate file sets, in order to compare them, use something like this: (5) CF {4 -P -D A:\ } If you don't use the -P, of course, CF will give you no chance to change diskettes, and will re-log the first diskette four times. Loops can be nested to a depth of ten (I think). The loop count must be greater than one. The -F option allows you to specify a file name "filter" that CF will apply to ALL file names as they "logged" into its data-base. Although CF can accept wild-card names as file sources, there may be a requirement to vet the names CONTAINED in those sources, as well. For example, say I want to load all .CF files, on the current drive, but only log .DEF and .MOD files FROM those .CF files. This is how you would do that: (6) CF -F*.MOD;*.OBJ -D -C \*.CF This is broken down, thus: the last item selects the files to be read, and the -C makes sure that the files are READ rather than having their details logged. The -D makes CF descend all directories, from the root down. The -F option says that only the .MOD and .OBJ files are to be logged from the .CF files. Note that if a file name pattern is preceded by a minus sign, this has the effected of EXCLUDING files. For instance, if, in the above example, I didn't want to see the files that started with an 'M', I would alter the command to read: (7) CF -F*.MOD;*.OBJ;-M*.* -D -C \*.CF Note that CF does NOT use the same "language" for the patterns as DOS. For example, "-Fc*r.*" would select all files that started with a 'C' and had an 'R' before the dot. DOS, if you supplied this to DIR, would merely give you all files that STARTED with a 'C'. (I notice that 4DOS doesn't, though - it gets it "right".) There is one slight "funny" - if you enter "CF *", then ALL files will be logged. You need to use "CF *." to get all files with no extension. (The code that does this pattern matching is provided by calls to a JPI library. I use Str.Match() on the file name strings. If you want to know EXACTLY what the syntax and semantics are, consult the JPI documentation or library source code.) When CF accesses archived files (.ZIP, .ARC, etc.), it runs one of the archiving utilities and re-directs the output to a temporary file. If you want the file to go anywhere other than the current directory, then use the - Y option to over-ride the default name. There must, of course, be no white space between the '-Y' and the file name. The reason for the provision of this parameter, was to speed things up when listing an archive off - redirecting output tends to "rattle" the disk drive somewhat. In my case, I use -Y to make the temporary file reside on my RAM disk. The -M option allows you to alter the default selection mode. If, for example, you want to start in "different files" mode, enter -MD as part of the parameter list. This would normally be used in conjunction with the "batch mode" options, -TB or -SL. If you want to customise the video mode, while CF is running, use the -V parameter. At present, the only option is to change to a mode and, if you do NOT use the no-screen-clear exit path (see the KEYS section), change back just before exiting. For example, to change to the super-VGA 132x43 mode, use "-V84", as in "CF . -V84". Graphics modes will NOT work because the JPI (TopSpeed) supplied windowing library writes directly to the video memory. CF OUTPUT AS A SOURCE --------------------- CF can accept it's own output as input. The idea is to allow you to use CF to dump the directory structure off of a remote machine, and have CF load it back on your local machine. You can use the -TB option to get the loadable output format and re-direct it to a file, or use the "create list file" key (see help). In order to create a file that CF can read back in, you must have only ONE file set loaded. The format produced is DIFFERENT if more than one file set is loaded. Also, be aware of the fact that the listing is produced in a different order depending on whether the -TB option or the -SL option is used to produce it. If -SL is used, then the listing will be in LOCATION order. This will take VERY much longer than the other method of producing a list file, because it has to scan the data-base once for each location string. (I know, this is a bit poor, but maybe I'll alter it later on.) The good news is that it can save an appreciable amount of memory. For example, I produced three listing files of my "C:" drive. The first was in location order, the second was in file order, and the last was in extension order. Then I loaded them back in and they used 146848, 184560 and 181824 bytes of memory, respectively. By the way, using -SL means that the resulting file LOADS a bit quicker as well. CF allows you allows you to compare the directory structure on two different machines, if you don't have a copy of any other utility that can do a full directory dump. In my case, on the remote machine, I use: (8) CF -D C:\ + -D D:\ + -D E:\ + -D F:\ -TB > REMOTE.CF This will grab an image of the remote directory structure, and save it in the file REMOTE.CF. Note that there is only ONE file set loaded and it's THIS that makes CF append the location string to each line in REMOTE.CF. This is why CF will only accept it's single file set output as input. Having done this, on the local machine I type: (9) CF -D C:\ + -D D:\ + -D E:\ + -D F:\ -SE REMOTE This will load the directories on the local machine into the first file set, and REMOTE.CF from the remote machine into the second file set. Then, compare the file sets in the normal way. ARCHIVES -------- CF can directly access .ARC and .ZIP archive files to extract a listing file. However, it DOESN'T read the files itself, but uses one of the stand-alone utilities via the DOS "exec" function. Thus, for this facility to work you must have one of the utilities, that can produce listings from archive files, already on your "path". The utilities that will be used, if present, are .ZIP PKUNZIP, PKZIP, FV .ARC PKUNPAK, PKPAK, PKXARC, PKARC, FV, ARC .EXE FV, PKUNZIP, PKZIP .LZH LHARC in that order. (The .EXE files are self-extracting archive files. Some software is supplied in this form.) The archive accesses can also be done using the wild-card mechanism. However, for CF to try to access the files, rather than use their directory information, you must use the -C option, just as for text files. (In fact, archive listings ARE text files - CF redirects standard output and standard error output to a temporary file, executes the relevant archive program, then reads the resulting output back in.) For example, to read all .ZIP files on drive C:, use this: (10) CF -D -C C:\*.ZIP Note the -D (descend directories) and the -C (read as text files). VIEWING AND EDITING ------------------- CF can, by using external programs, edit and view text files. The mechanism used is similar to that employed when invoking programs that extract file lists from archived files. Therefore, in order for this feature to work, an editor and viewing program must reside somewhere on your search path. (Hereinafter, for "editor", read "editor or viewer".) The only constraint on these editing programs, is that they must be able to be started with the target file as a command-line parameter. For instance, that well-known text editor, WordStar, can edit a non-document file, "TEXT.DOC", by supplying a command line of the form "WS TEXT.DOC N". CF can be configured, albeit very crudely at present, to provide any necessary parameters in addition to the target file name. (For the configuration options, see the CONFIGURATION section.) In order to avoid memory problems, it is advisable to use small editors, especially if they are of the sort that loads the WHOLE file contents into memory. Also, they should not alter the video attributes while they are running since CF will NOT restore them afterwards. CF takes notice of the current screen size (in rows and columns) and editors that do the same will get along with CF much better than those that don't. (The editor "QEDIT" and the viewer "LIST" are very well behaved in this sense - you'd think that they were part of CF itself.) If, by using the keys that allow editing or viewing, or by use of the help keys, you invoke an editor, you may get a message saying that the file cannot be found. CF can only edit a file if it resides in the location specified in the file's source. In particular, watch out for the situation where you use a .CF file, containing text from another machine, that cites a file that has the same name, and is in the same DIRECTORY as a file on YOUR machine - CF will happily edit the file on your machine even though the contents may be quite different to that on the other machine. By the way, CF does NOT update it's internal information when you edit a file, so, on the screen, it will appear that the file date and size have not altered. You have been warned; CF is intended as a directory comparator, not a file management system. Finally, a quick word on the auto-view (ALT-V), auto-edit (ALT-E) and auto- batch (ALT-O) modes. I'll only explain auto-view since the other two are very similar. Imagine that you want to view many files, one after the other, and that each is next the previous one and can be reached by just a single cursor-movement. Rather than go though the sequence move-cursor, invoke-viewer, exit-viewer, CF allows the middle step to be avoided. If you use auto-view mode, the viewer will be invoked for the current file. Thereafter, each time you use one of the short-range movement keys (cursor-up, cursor-down, etc.), the viewer will automatically be entered. Exit auto-view by just re-selecting it, or you can enter auto-edit or auto-batch modes directly by using the relevant key. XTGOLD FEATURES --------------- Some file utilities (Xtree Gold, Norton Commander, etc.) allow the user to easily invoke a program, depending on the "current" file, with a single key- stroke. For example, in XTGOLD, if the user's current file is, say, "TEST.DOC", and you have a batch file "DOC.BAT" in the XTGOLD directory, then XTGOLD will run this batch file if you press "O", "o" or "ALT-O". So that you can access the current file, XTGOLD fills in several parameters before invoking the batch file. I thought that it would be a good idea if CF could also run these batch files. So, I implemented a version of XTGOLD's "O" command. (However, there is NO equivalent of the ALT-O command - CF ALWAYS uses only free memory to execute programs.) The only pre-requisite is that the user has defined an environment variable, CFXTGOLDDIR, that "points" to the directory that holds the batch files. For example, let us assume that I want to be able to invoke WordStar when the current file is a .DOC file. First, I have to make a directory, place it's name in the aforementioned environment variable, and create DOC.BAT. This would contain something like: WS %4.%5 D The "%4.%5" represents the current file name. So that the batch file can access various information, several things are passed down as parameters: %1 The full file path name. %2 The drive letter (no colon) %3 The path name (no drive or file name) %4 The file name (no extension) %5 The extension name If the current file name was, say, A:\B\CC.DDD, then the parameters would be: %1 A:\B\CC.DDD %2 A %3 \B %4 CC %5 DDD Hence, in the above example, our command line would be: WS CC.DDD D XTGOLD has another way to invoke small "batch files" - the Application Menu. In both CF and XTGOLD, you use the F9 key to bring up a menu of pre- configured items that allow you to start a "batch file" of commands on the current file. The reason for the quotes is that they are NOT, in fact, batch files. The little macros are kept in a file called XTG_MENU.BIN. Using the environment variable, CFXTGOLDDIR, you can tell CF where to find this file so that it can run the macros contained in it. However, you have to use XTGOLD to edit it. Since you must be familiar with this XTGOLD facility in order to edit this file, I'll say no more. (The normal keys work in the application menu - use ESCAPE to bail-out and RETURN to select an item to run.) NORTON COMMANDER FEATURES ------------------------- The emulation of the Norton Commander (NC) menu and "batch file" facilities have been accomplished by converting the NC files into their XTGOLD equivalents and using the existing code. So, if you use F2 to invoke the NC menu, CF actually reads the NC menu file, outputs a temporary file containing the XTGOLD version and then uses existing code to display and obey the commands required. Therefore, limits which NC do NOT enforce apply while you use CF. In particular, you can have only a limited number of lines on the menu, and a limited number of executable "batch" lines associated with each named line and that the user-specified key assignments are NOT obeyed. (In the latte case, this measn you can ONLY start an entry by using RETURN.) The "run this file" facilities of XTGOLD are also emulated when using the NC extension file. When RETURN is pressed, the NC extension file is scanned and, if an applicable entry is found, the NC special "!" items are converted into XTGOLD special "%" items and a temporary batch file is created. This batch file is then run. By the way, if CF can't find a line to use in the NC extension file, then it behaves as if you'd used the 'O' key to invoke the XTGOLD stuff instead. Note that in order to find these NC files, CF looks for the environment variable "CFNCDIR". If that doesn't exist, it uses the standard NC environment variable "NC" instead. CONFIGURATION ------------- CF can be configured with reference to the archive, editing and viewing programs that it will invoke, parameter values that must be used for ALL invocations of CF and various other items. Be warned that these facilities are liable to change as I improve CF. NOTE: AT PRESENT, CF STORES ALL ITEMS FROM THE CONFIG FILE IN STRINGS THAT ARE FIFTEEN (15) CHARACTERS LONG. LONGER STRINGS ARE TRUNCATED. YOU HAVE BEEN WARNED. At present, it works like this: at start-up, CF searches a file called CF.INI, that must be in the directory from whence CF was started or specified by the environment variable CFCFGNAME. Before CF will take notice of the text in this file, it must find a "header" containing the string "[CF]". For an explanation of this convention, see later in this section. Each of the other lines in the file has one of following forms: (a) PROGARCH <match> <progname> <beforeparams> <afterparams> PROGVIEW <match> <progname> <beforeparams> <afterparams> PROGEDIT <match> <progname> <beforeparams> <afterparams> The first string identifies the purpose for which the program named in <progname> is intended. The <match> entry is a file name, which MAY be wild-carded, that specifies which set of files <progname> can process. The <beforeparams> string is placed between the program name and the file name, and <afterparams> is placed between the file name and the end of the command line. In both of these strings, all under-line characters ('_') are replaced by spaces since CF does NOT add it's own spaces between the different components of the command line. (b) PARAMETER <parameter> The <parameter> is a string just as you would type on the command line. CF scans these configured parameters, and they get processed BEFORE the command line parameters. Of course, if the configued parameters are GLOBAL parameters, it doesn't matter WHERE they appear. However, if they are not global, then it DOES. (c) VARIABLE <name> <value> This facility allows you to pass an environment variable to CF without having to use a real environment variable to do it. The <name> string is the name of the environment variable that you wish to define and <value> is the value that it should hold. When it requires a particular environment variable, CF searches the config file for a "VARIABLE" line BEFORE searching the real MS-DOS environment variable list. For example, if you want to have "H:\!.!" as the temporary file name that CF will use, you can do one of two things; define a real environment variable by using "SET CFTEMPNAME=H:\!.!" at the MS-DOS command line prompt, or put a line like "VARIABLE CFTEMPNAME H:\!.!" into your config file. There are two situations where overriding an environment variable won't work. The first is CFCFGNAME; this won't work because the re-directions are in the config file and this is already open when the re-directions are loaded. The other is the PATH variable; this won't work as a result of the internal structure of CF. (d) RECOGNISE <extension> This allows you to make CF automatically recognise certain file types. For example, by using "RECOGNISE .CF" in your .INI file, CF will, if you specify just the root file name, automatically add the extension ".CF". What actually happens is this: CF decides whether the file name you type has any wild-card characters in it. If it DOES, then this auto- recognition is NOT invoked. Otherwise, it is deemed to be a "single load" and CF tries to open the file. If it doesn't exist AND the specified name does NOT contain a "dot" character, then CF searches the config information looking for the recognition lines. For each one, it merely appends the <extension> onto the specified file name and tries THAT. This process stops when either it FINDS a file or there are no more recognition lines. Note that "RECOGNISE .ZIP" will mean that you can say "CF X" instead of "CF X.ZIP". Also note that although CF checks that the supplied name doesn't contain an extension, the <extension> does NOT have to start with a dot - something like "RECOGNISE X.YYY" is perfectly acceptable. In this case, "CF A" would get converted into "CF AX.YYY" if the file "A" didn't exist. Ok, so what does a typical config file have in it? Here is a typical CF.INI file: [cf] parameter -se recognise .cf variable cftempname h:\!.! progarch *.zip pkunzip _-v_ _ progarch *.arc pkunpak _-v_ _ progarch *.arc pkarc _-v_ _ progarch *.arc fv _ _ progarch *.arc arc _v_ _ progarch *.exe fv _ _ progarch *.exe pkunzip _-v_ _ progarch *.lzh lharc _l_ _ progview *.* list _ _ progedit *.* q _ _ progedit *.* ws _ _n The "parameter" line just makes sure that CF will ALWAYS sort files by extension, "recognise .cf" means that you would not have to type .CF extensions and the "variable" line makes CF use H:\!.! as the temporary file name. The rest are external program specifications. If CF is asked to use an archiver to process a file called, say, "FILE.LZH", it will scan the config file, searching lines starting with "PROGARCH", until it comes to the entry that contains "LHARC". Then, it will concatenate the program name, the pre- text, the file name and the post-text to make a command line like this : "LHARC L FILE.LZH " This is what actually gets executed. Note that in ALL cases, the extension (in this case, ".LZH") is retained in the command line. I would recommend that you do NOT alter the program entries in the supplied CF.INI file. It might appear that the entries are in an arbitrary order, but I assure you that they are NOT; I found that the different archive programs all had their funny little ways, and that the table, as it stands, produces the best results. (However, one thing you might try is to move the FV lines closer to the front of the file. FV is much quicker at producing archive listings than the other programs. The only trouble I have found with this modification, is that it can cause problems when processing archives that have a .EXE extension. See stuff in the BUGS section that releates to FV, too.) By the way, a program can appear more than once in the config file. So, to view .EXE and .COM files in hex, you could use: progview *.com list _ /h progview *.exe list _ /h progview *.* list _ _ The "*.*" entries in these lines are there as a sort of "catch-all". If the target file doesn't match any preceding program, they'll be processed by the program that has "*.*" as a match pattern. (The pattern matching is the same as for the -F parameter.) CF will only process lines that are preceded by a line containing nothing but "[CF]". (This is intended to be compatible with the Microsoft TOOLS.INI file.) This allows the configuration stuff to be placed in a common area with other programs' information. Also note that, if you rename CF.EXE to CFX.EXE, say, the header will have to be "[CFX]". CF will ignore any lines that do not start with an item that it is looking for. The result of this is that lines that start, for example, "REMARK" will be ignored. Use this fact to incorporate comments into the config file. Also, you should be able to place comments at the end of each line since CF will ignore any extra text, but if you do this on "prog****" lines, they must NOT have any items missing before the comment or the comment text will be used to generate de-arch, edit and view command lines. This file can be re-loaded by using SHIFT-F10. This means that, if the one of the currently loaded file sets has the .INI file in it, you can use an editor to alter it and then re-load it using SHIFT-F10. Very useful for getting your .INI just right... (Note that the parameter lines are NOT re- processed by CF - they only apply the first time the config file is read.) KEYS ---- If you press F5 or the question mark key, CF will display a page of useful information. The first line consists of three numbers for DOS memory and a another three for EMS (if it's enabled). The first is the amount of memory CF started out with, the second is the amount it's got now and the last is the difference between the first two - in other words, it's the amount of memory that's required to store the files that you have currently loaded. The numbers for EMS memory are calculated in a similar manner. The rest of the page just lists the full source names of the file sets, and the start-up and current options list. Pressing F1 produces, not surprisingly, a summary help file. If you use SHIFT-F1 in place of F1, you get the THIS file instead. In order to exit CF, you can use several different keys. At present, any one of ESCAPE, 'Q', 'q', ALT-Q or CTRL-Q will exit CF after clearing the screen. The screen clear can be avoided by using 'X', 'x' or ALT-X instead. (You may ask why this was added; on my system, I have a colour screen AND a mono screen. I can now change to the mono screen, invoke CF and exit WITHOUT the screen clear, and then change back to the colour screen. In this way, the details of the last CF screen are still displayed on the mono screen, but I can act on that information by running programs which display their output on the colour screen.) Other active keys are F3 (toggle size/no size display), SHIFT-F3 (toggle date size), and F4 (toggle cursor lock mode). Duplicate file details may be viewed by using SPACE. You can interrupt CF, while it is loading files or generating output files, by pressing escape. Use F9 to invoke the XTGOLD- compatible application menu and F2 to use the NC version. Also, if it displays any error or warning messages, type any key to continue. Instead of using the -TB and -SL options to produce listings from CF, you do it interactively by using F6 (list in file order) and SHIFT-F6 (list in location order - the slower alternative). They both produce a file called CFOUTPUT.LST, unless there is only one file set loaded, in which case it's called CFOUTPUT.CF. If you want to alter the sort order of the files from by-name to by- extension, or vice versa, use F10. There are two little problems with this, at present. The first is that it can be a slow operation if you re-order a large number of files. Secondly, you may lose memory for each re-order, although each loss will DECREASE the more you do it. As far as I know, this is due to the action of one of the few modules, used in CF, that I did NOT write. I may investigate it later on. On the other hand, I may not... TAGGING ------- Like XTREE, XTPRO, XTGOLD, MAGELLAN, and so on, CF now lets you "tag" (that is, mark) files. The button conventions are similar to all of the programs mentions above. Basically, a button on its own operates on the file under the large "cursor", with the control key down it operates on all files in the current file set and, with the alt key, it operates on ALL files. Thus, to tag the current file, use 'T' (or 't'), to tag all in the current file set, use CTRL-T, and to tag all files use ALT-T. The 'U' equivalents untag files and the 'N' versions invert (ie, toggle) the tags. At present, the only thing that you can do with tagged files is to get a "batch" file output (by using F7). In fact, this just consists of a file with the file names of all tagged files in the file set under the cursor. I hope, eventually, to prefix the relevant location string onto each file, and maybe to even accept a command line "mask". We'll see. The name of the file, by the way, is CFOUTPUT.BAT. (Hard-coded, at the moment.) BUGS GALORE ----------- This section gives a little information on known CF problems, and bugs that I've come across in the programs that produce output for CF. First, MY bugs: (a) In one of the CF examples, it was suggested that you could use "CF . .." to compare your current directory contents with its parent directory. However, there is a little problem doing this under MS-DOS 3.2. It don't work. You have to use "..\" instead of "..". Although I know there is a problem here, unless other bug investigations throw light on the cause, I don't intend to do anything about it - MS-DOS is a shitty "operating system", running on a shitty type of computer, and I'm definitely NOT going to spend the rest of my life learning all about the shitty versions of both of these abortions. If you KNOW why this difference exists, and can tell me a (simple) cure, I'll fix it. If not, then forgot it. I develop using a '386 machine running 3.3 MS-DOS and that's as far back into the dark-ages as I'm prepared to go. (b) When you are in a root directory, "." doesn't work. You have to use "\" instead. On a proper operating system (say Unix), the "." would be expanded to the full path name and CF wouldn't even SEE the short-hand notation. However, MS-DOS isn't, so CF does. Clearly, I'll have to try to cope with all of these "funnies" eventually, but I'm only willing to do this if get more user feed-back - if there ARE no other users than me, I'm wasting my time 'cos CF does (nearly) everything that *I* want it to do. (c) See the documentation of the -W parameter for a discussion of a little problem with date formats. (It's connected with the fact that some of the programs that produce CF readable output use the country code to decide on the date format to be used.) (d) I configure CF to run CF when I use RETURN or 'O' to invoke programs by extension on .ZIP files. So, when I load a directory into a file set and it contains a .ZIP file, I can move the cursor to it and press RETURN and it will run ANOTHER copy of CF but, this time, just accessing and unpacking the .ZIP. This works fine except for one thing: the second incarnation of CF doesn't see any EMS memory AT ALL. The reason is that the EMS module I use grabs ALL EMS memory unless told otherwise. One day, I'll see if I can't make it release all un-allocated EMS during the period that it has started a child process. Until then, your stuck with this little "feature". Now, the Rest Of The World's bugs. Apologies to the relevant authors if these "bugs" turn out to be MY problem: (a) There appears to be a bug in MAGELLAN 2.0 - ZIP listings show each file's minute field as zero if the date and time format is set to show a four digit year field. Luckily, CF can cope with the other year-first formats, so there IS a way around it. (b) If the date and time of a file in an archive is 00-00-1980, older versions of FV fill the date and time fields with "dd mmm yy" and newer versions use spaces. CF can cope with this, but note that the older versions, that should use "dd mmm yy", appear to have a bug whereby they sometimes fill the date and time in from a PREVIOUS files' date and time. CF cannot detect when this happens. (Also, it appears that the seconds field is wrong in the older version - CF doesn't use seconds in time comparisons at the moment, but one day, it MAY do...) (c) While testing the code that copes with the configuration file, I found that a .LZH file wasn't being processed properly. If I used LHARC, from the command line, to produce a text file (that is, a .CF file), all was alright. However, if I invoked LHARC from within CF, by using "CF TEST.LZH -SE", then the resulting (temporary) .CF file had a spurious CR-LF pair in the middle of a line of text. As a result, this file was skipped by CF. At the moment, I don't know why this should occur. (Ostensibly, this is a LHARC problem, but I'm throwing no stones yet; I know that I'm living in a glass house...) (d) Back to FV. Somehow, I've managed to get a file with a time and date of 00:00:00 on 01-01-98. FV (versions 1.16, 1.28 and 1.32 at least) don't seem to like this. They each get the time correct, but show the date as "01 Jan ;8". Not surprisingly, CF can't cope with the semi-colon instead of a valid digit in the year field and throws a wobbler. The solution is to use something else rather than FV. (Now you know why I have reservations about using FV as the default archive lister - it's not as reliable as PKZIP, et al, although, I admit, it IS faster.) DISCLAIMER ---------- These days, all P.D. software documentation files seem to have a disclaimer in them some where. So, here goes... "I hereby disclaim all warranties relating to this software, whether express or implied, including without limitation any implied warranties of merchantability or fitness for a particular purpose. I will not be liable for any special, incidental, consequential, indirect or similar damages due to loss of data or any other reason, even if I have been advised of the possibility of such damages. In no event shall my liability for any damages ever exceed the price paid for the license (bugger all) to use the software, regardless of the form of the claim. The person using the software bears all risk as to the quality and performance of the software." In case you're wondering how I dreamed up that waffle, I'll tell you - I nicked it from PKWARE's disclaimer in their PKZIP documentation. So, now you know. CONCLUSION ---------- The limit on the number of files that can be loaded, besides those set by the amount of available memory, is that you can load up to 65535 files. (Guess why...) Note that this program (key assignments, display layout, file selection modes, and so on), is likely to change as I get feed-back, or I damn well feel like it - if you get a new version, and it doesn't behave the same as the previous version, then just play around to see what's new. Alternatively, you COULD read the documentation, if I supply any. (Mind you, THAT may well lie about things, if I miss a change or two.) Finally, I'll just say that *I* find CF useful. As a matter of fact, to give version 0.2 a bit of a test, I compared the sources of our system on our three machines. By inspecting the output, I found that we'd shipped the latest version of our software with a bug fix missing. (Run around with head cut off, make new version, ship it and hope none of the users noticed...) Mark Davis.