Documentation for CUT version 1.0, released 10 Febraury, 1988 WHAT IT DOES: CUT is the fastest (and maybe smallest) file splitting program ever written -- because it cheats. Instead of actually copying big files into separate smaller files, CUT just modifies the disk directory to make big files appear as separate smaller files. In a comparison test, SPLIT45 (an excellent file splitting program written in Turbo Pascal) took 15 seconds to split a 160K file into five 32K files. CUT took less than half a second -- hardly worth running the stopwatch. I ran the tests on a 4MHz Kaypro with a RamDisk, but even running the test on a floppy drive, CUT only took 3.5 seconds (floppy test not done with SPLIT45; I'm the impatient sort). WHAT IT RUNS ON: So far I've only tested CUT with a Kaypro 1 with a MicroSphere RamDisk. I know it WON'T work correctly on Kaypro DSDD (394K) floppies, but will work with the single-sided (191K) Kaypro format. What it comes down to is this: CUT should work with any disk format which assigns one physical directory extent for each logical directory extent (16K of allocation blocks). If you don't understand what this means, it's a little tricky to explain. All I can suggest is try it on a scratch disk; if it seems to work, enjoy it. SYNTAX: CUT d:Filename.Typ X Where: d: is an optional drive specifier Filename.Typ is any valid file specifier (but see note below on file specs) X is a digit 1-9, the desried size for split file segments, or the digit 0, to request re-joining files that had been split. The size for the split file segments will be 16K times the number X given in the command line. For example, "CUT Myfile 1", results in 16K segments; "CUT Myfile 2" gives 32K segments, and so on. What CUT does is assign X number of physical directory extents to each segment; each directory extent accounts for 16K. As files are split up, each segment is renamed by changing the first character in the filetype to a different letter, A through Z. So a 160K file called Longfile.Txt could be split as follows: CUT Longfile.Txt 1 This would result in 10 files, each 16K long, named Longfile.Axt, Longfile.Bxt and so one though Longfile.Jxt, in place of the original directory entry for Longfile.Txt. CUT will display the original filename and the new filenames side by side as they are created. If you want larger segments, just specify a larger value after the filename. For example, the command: CUT Longfile.Txt 5 would result in only two files (Longfile.AXT and Longfile.BXT), each 80K (5*16) in length. WARNING: Use of ambiguous filenames is NOT RECOMMENDED when cutting files. CUT does NOT check or warn you about this. ANOTHER WARNING: Though CUT produces some decidedly weird file names, it does NOT check for duplicates. If you shrug your shoulders and say "So what?" to the above warning, you probably shouldn't be using this program. Pay attention to what your doing -- this tool can bite back. AND ANOTHER WARNING: If you have a very big file and select a small segment size, you might end up with some non-alphabetic or lower-case characters in the split file name. CUT will be able to deal with these but most other programs will not. Here are recommended maximum files sizes for given segment sizes (X): X = 1, 416K X = 2, 832K X = 3, 1248K X = 4, 1664K X = 5, 2080K X = 6, 2496K X = 7, 2912K X = 8, 3328K X = 9, 3744K This is not a severe limitation. It only presents a problem with very large files being split into very small segments. But it can happen, so I figured I should warn you. RE-JOINING SPLIT FILE SEGMENTS: If you split some files up for the purpose of printing or reading them, or for backing them up onto floppies, or any function WHICH DOES NOT CHANGE THEIR CONTENTS, you can re-join the split file segments with the command: CUT Longfile.?xt 0 Notice the only ambiguous character used is the first letter in the filetype -- the one which changed when the file was split up. The same warning about ambiguous file names applies here -- other wildcards can be used but are not recommended in any other position. CUT will simply round up all the matching directory entries it finds, and try to make one long file out of them. The re-joined file will be renamed Longfile.-xt, with the "-" being there because CUT has no way to know what the original filename was. Of course you can rename it to anything you want. REPEATED WARNINGS: When combining split file segments, the only wildcard should be in the first letter of the filetype. And watch out for duplicate filenames! If you've done anything which changed the split file segments in any way, DON'T use the CUT 0 option. Use PIP instead: PIP Longfile.TXT=Longfile.Axt[Z],Longfile.Bxt[Z] to concatenate the changed files. Note also you should only use the [Z] parameter on text (ASCII) files. Use [O] instead, if you're working with any kind of 8-bit files (COM, LBR, ARC, any SQueezed or CRunched files, etc). ABOUT THOSE WARNINGS: The potential traps involved with wildcards are only a problem if you're unaware of them. I left it that way because in some cases, the ability to use wildcards can be useful. Here's an example: I had very long text file which I wanted to look at with VDE (Eric Meyer's memory based text editor). Normally VDE can handle files up to 48K, so I did: CUT NODELIST.TXT 3 to break the file into 48K segments. However, when I tried to load the first one, I got an "Out Of Memory" error from VDE. This was due to an unusual layout in the text file, which forced VDE to use more memory than usual. So I quit from VDE, and did this: CUT NODELIST.?XT 2 which regrouped the existing 48K segments into 32K segments instead. Regrouping the segments took exactly as long as splitting the file originally -- less than 1 second. The smaller segments loaded into VDE without any problem. A few paragraphs back, I warned against using wildcards when cutting files -- but now I gave an example of how it can be useful. The point is this: CUT is a powerful tool, but it's stupid. It does EXACTLY what you ask -- so make sure you ask it to do EXACTLY what you want. FINAL NOTES: CUT has much code in common with CFA. In fact, I first wrote the CUT command as a new feature within the CFA program. But the purpose and usage of CUT are so different from CFA that making them separate programs allowed for a more logical syntax. Therefore, I stripped all the file splitting code out of CFA version 0.3 (experimental release), and re-released that as CFA version 1.0 -- a "normal" release number because I don't expect to be changing CFA again anytime soon; the code that's in it works. Also, this is release 1.0 of CUT -- a "normal" version number not because it's polished and finished, but because the basic program has been tested and it also works to my satisfaction. I don't plan any major changes (at least not this week) -- but anyone else is free to tinker with it. Let me know if you come up with anything interesting. Lee D. Rimar contact at: D-KUG RBBS (313) 772-0522 Royal Oak RCP/M (313) 759-6569 Tony's Corner (313) 754-1131 (Opus node 120/13) (all available through PC-Pursuit: MIDET)