nathan@reed.UUCP (Nathan Wilson) (07/12/85)
In the past I have always used the typical method of having the present MacTerm document on the disk that is recieving the file. However this last round of discussion on the topic brought an idea into mind. I remembered the reason that ':'s aren't allowed in Mac file names. Namely because the Mac interprets them as Volume:Filename. This can be rather unfortunate if you don't have a disk named <Volume>, but it can also be useful as in this case. I next looked at the man pages for macput and found a -n option which supposedly renames the file that it sends. I played with this for a while and discovered fairly rapidly that it doesn't work at all, even on the disk with the MacTerm document. (I tried both the suggested syntax 'macput foo -n bar' and 'macput -n bar foo' both of which resulted in saving foo on the usual disk under the name foo. I then remembered that the names for foo had been generated by xbin so maybe.... After finding the -n option of xbin, I tried 'xbin -n OtherDisk:bar foo' this created the usual three forks but with the names OtherDisk:bar.data etc. I then tried 'macput OtherDisk:bar' and the disk with the MacTerm document whirred then the other drive whirred and it deposited a functional version of foo under the name of bar on OtherDisk!!!!!!! I have since played with this method and discovered the following: 1) It will work with large files (I used ResEdit). 2) It will only work if there is enough space to recieve the file on BOTH disks (ah, well there had to be a catch somewhere). 3) It doesn't work to simply rename the files on the mainframe after xbin'ing them. (I was working on a VAX.) 4) The Mac has to know about the disk your sending the file to before you try sending it. (The easiest method that I found was to go to Send File in the File menu, eject the present disk, insert the destination disk and then cancel the send command. It also works to just put the disk in the external drive if you have one.) and 5) It works on a 128K, one drive mac and requires only two disk swaps for a 96k document!! End discovery one. Discovery Two. I only very rarely use the Print Selection... option in MacTerm and would prefer to use the 24K of disk space that the imagewriter takes up for other purposes. However, I am also very annoyed by the little dialog box that appears everytime I run MacTerm without an imagewriter on it. So I took out my hacking tools and got to work. I first tried renaming the 0k clipboard file on my disk Imagewriter which didn't work. I then went in with ResEdit and ripped out all the resources from the Imagewriter file. This resulted in 286 byte file, I then launched MacTerm and low and behold now alert box!!! Now I was curious what these 286 bytes were and what there purpose was, also I wanted something that wasn't named Imagewriter so that people wouldn't get confused. Using FEdit and IM I found out that all that was left was the bare minimum of a resource fork. Interesting, what does MacTerm look for? A file with a resource fork and called Imagewriter? I then tried another tack (due to a friends suggestion). We opened up MacTerm to see if we could find the string Imagewriter which quickly failed, then we went after the alert box itself. After finding that the DITL 4196 had the offending string, we went into ALRT 4196 and turned all the stage bits off (stg1boxDrawn etc.). We then left ResEdit, threw out the Imagewriter and started up MacTerm. To our amazement this actually worked. So I now have a version of MacTerm that doesn't tell me about the fact that I don't have an Imagewriter every time I start it up (a fact that has become abundantly clear). If I try to print with such a version it tells me '-192 PrintCache:PrJobDialog failed..' a suitable hint as to what my problem is. What other machine can you reprogram without the source, in under 30mins when you don't know what your looking for!!! -Nathan Wilson "The best things come in little pink boxes."