kds@intelca.UUCP (04/11/84)
>What is worse is when one wants to transfer text files to the VMS system. >Neither cu nor tip knows enough to convert the newslines in the file to >carriage returns. This definitely should be an option to tip. There are actually, I believe that VMS text files are REALLY different, not just adding a CR to a LF, but rather are usually what is called variable length records, where there is NO CR,LF at all, but rather the first two characters of a "record" contain a count of the number of characters in the record. It is then the function of the utility trying to read these suckers to figure out what the line really is. That is why in Eunice there is a unixtovms and vmstounix command, since it is not really obvious how to do something intelligent when you have both flavors of text files around. What does this have to do with cu? Well, it tries to point out that rather then mucking with cu on the Unix system, you really should use a utility on the destination system that knows how to create a file of the appropriate type! toodles..... -- Ken Shoemaker, Intel, Santa Clara, Ca. {pur-ee,hplabs,ucbvax!amd70,ogcvax!omsvax}!intelca!kds
smk@axiom.UUCP (Steven M. Kramer) (04/13/84)
> Well, it tries to point out that rather then mucking with cu on the > Unix system, you really should use a utility on the destination system > that knows how to create a file of the appropriate type! toodles..... Any the names probably should be cat, tee, ... Why? Because maybe some way can be built so that the ~%take cmd will work even on non-UNIX systems. Now, I haven't thought too much on `philosophy infringement'. All I'm after is the simplest file xfer method using terminal lines. -- --steve kramer {allegra,genrad,ihnp4,utzoo,philabs,uw-beaver}!linus!axiom!smk (UUCP) linus!axiom!smk@mitre-bedford (MIL)
cdl@mplvax.UUCP (04/14/84)
|
As a side note on translating between 'Files-11' text files (with character
count per line) and 'unix' text files (character stream, delimited by \n),
note that the most recent incarnation of the program 'ansitar' has routines
named 'pipunblock' and 'pipblock' that do this particular job. It would be
easy to lift them out and put them into a filter. In fact I did that just last
week for 'pipunblock' to make sense out of an ANSI-standard tape that was
created on a VMS system.
Carl Lowenstein {ucbvax,philabs}!sdcsvax!mplvax!cdl
U.C. San Diegoguy@rlgvax.UUCP (Guy Harris) (04/15/84)
>>What is worse is when one wants to transfer text files to the VMS system. >>Neither cu nor tip knows enough to convert the newslines in the file to >>carriage returns. This definitely should be an option to tip. There are >actually, I believe that VMS text files are REALLY different, not just >adding a CR to a LF, but rather are usually what is called variable >length records, where there is NO CR,LF at all, but rather the first >two characters of a "record" contain a count of the number of >characters in the record. It is then the function of the utility trying >to read these suckers to figure out what the line really is. That is >why in Eunice there is a unixtovms and vmstounix command, since it >is not really obvious how to do something intelligent when you have >both flavors of text files around. What does this have to do with cu? >Well, it tries to point out that rather then mucking with cu on the >Unix system, you really should use a utility on the destination system >that knows how to create a file of the appropriate type! toodles..... The way one normally sends a file from machine X to machine Y, assuming one is running a "cu"-type program on machine X to turn machine X into an "expensive dial-up terminal" to machine Y, is to run the moral equivalent of "cat" on machine Y and have the "cu"-type program simulate typing the contents of the file which is on machine X at machine Y. In the specific case, one would do something like COPY TT: DBA0:FROBNITZ.TXT on the VMS system; "COPY" will read the terminal (TT:) and dump its contents into "DBA0:FROBNITZ.TXT". Since a terminal normally sends ASCII stream text to the host, the fact that a "cu"-type program on UNIX will send ASCII stream text while the OS on machine Y assumes counted records doesn't make any difference. RMS understands the difference between a terminal and a text file, and will convert the record read from the terminal into the appropriate form to pass through the kidneys of "COPY" into the bowels of "DBA0:FROBNITZ.TXT". Twiddling "cu"/"tip" to understand that the remote machine doesn't have a UNIX-style TTY driver is fairly straightforward and, as Mr. Sebok says, should be done. It will solve the mentioned problem completely. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
rpw3@fortune.UUCP (04/18/84)
#R:intelca:-25000:fortune:26900047:000:701
fortune!rpw3 Apr 17 19:11:00 1984
Simple method used by me to get files OUT of a PDP-10:
1. Put the line "~>>cu.log" into a file called "culog.on".
(Note: No colon ^ here, so you still see everything on the screen.)
2. Put the line "~>" into a file called "culog.off".
3. When you want to start copying, say "type culog.on".
When you want to stop say "type culog.off".
4. Everything gets APPENDED (because of the ">>") to "cu.log"
on your local system.
5. When you're through, edit the garbage (command prompts, etc.)
out of "cu.log".
O.k.?
Rob Warnock
UUCP: {ihnp4,ucbvax!amd70,hpda,harpo,sri-unix,allegra}!fortune!rpw3
DDD: (415)595-8444
USPS: Fortune Systems Corp, 101 Twin Dolphin Drive, Redwood City, CA 94065kvc@scgvaxd.UUCP (Kevin Carosso) (04/20/84)
> actually, I believe that VMS text files are REALLY different, not just > adding a CR to a LF, but rather are usually what is called variable > length records, where there is NO CR,LF at all, but rather the first > two characters of a "record" contain a count of the number of > characters in the record. It is then the function of the utility trying I think you are very confused. Yes, it's true that VMS treats text files internally as variable length records with record terminator attributes (normally CR) but this has NOTHING to do with sending files with cu. VMS sees cu as nothing more than a user typing (albeit a little faster than most humans can type) a file at a terminal. In this sense, VMS treats CR as the line (or record, if you like) delimiter. That's because most terminals issue CR when you hit the big key labelled "RETURN". In cooked mode, the UNIX terminal driver ALSO has to convert CR into something meaningful internally, in this case LF. If "cu" had been written with a little more generality in mind, it would send to the remote system exactly what that remote system would see if it were a human sending data down the line: a CR. Let's not be so hasty to pass things off as operating system problems when they aren't. It really is "cu" that needs mucking. Remember that making it send CR will still work with UNIX systems but allow other systems to work as well. It seems to me that any change that increases the generality and usefulness of a tool without compromising the current functionality of that tool is a change for the better. It's UNIX anyway, who cares if your source code is different from anyone else's source code? :-) /Kevin Carosso allegra!scgvaxd!engvax!kvc Hughes Aircraft Co.
kvc@scgvaxd.UUCP (Kevin Carosso) (04/20/84)
oops... first run of this was blank here... THE bug is still crawling... > actually, I believe that VMS text files are REALLY different, not just > adding a CR to a LF, but rather are usually what is called variable > length records, where there is NO CR,LF at all, but rather the first > two characters of a "record" contain a count of the number of > characters in the record. It is then the function of the utility trying I think you are very confused. Yes, it's true that VMS treats text files internally as variable length records with record terminator attributes (normally CR) but this has NOTHING to do with sending files with cu. VMS sees cu as nothing more than a user typing (albeit a little faster than most humans can type) a file at a terminal. In this sense, VMS treats CR as the line (or record, if you like) delimiter. That's because most terminals issue CR when you hit the big key labelled "RETURN". In cooked mode, the UNIX terminal driver ALSO has to convert CR into something meaningful internally, in this case LF. If "cu" had been written with a little more generality in mind, it would send to the remote system exactly what that remote system would see if it were a human sending data down the line: a CR. Let's not be so hasty to pass things off as operating system problems when they aren't. It really is "cu" that needs mucking. Remember that making it send CR will still work with UNIX systems but allow other systems to work as well. It seems to me that any change that increases the generality and usefulness of a tool without compromising the current functionality of that tool is a change for the better. It's UNIX anyway, who cares if the source code is different from anyone else's source code? :-) /Kevin Carosso allegra!scgvaxd!engvax!kvc Hughes Aircraft Co.