hough@lamont.Columbia.edu (sue hough) (04/29/88)
I am trying to read an ascii (Prime generated) 9-track tape on a Unix system. The restored files look like ascii when I use MORE, CAT, HEAD, etc. But when I try to edit them with vi, I get "not an ascii file". Any suggestions appreciated. (A UNIX novice) S. Hough email: hough@lamont.ldgo.columbia.edu
dhesi@bsu-cs.UUCP (Rahul Dhesi) (04/29/88)
In article <533@zoot.lamont.Columbia.edu> hough@lamont.Columbia.edu (sue hough) writes: >I am trying to read an ascii (Prime generated) 9-track tape on a Unix > system. The restored files look like ascii when I use MORE, CAT, > HEAD, etc. But when I try to edit them with vi, I get > "not an ascii file". I seem to remember that Primos likes the eighth bit set in each character. It must be that vi doesn't like this. Write a filter to strip these bits, or use Chuck Forsberg's undos/todos utility with the -s switch. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
gwyn@brl-smoke.ARPA (Doug Gwyn ) (04/30/88)
In article <533@zoot.lamont.Columbia.edu> hough@lamont.Columbia.edu (sue hough) writes: >I am trying to read an ascii (Prime generated) 9-track tape on a Unix > system. The restored files look like ascii when I use MORE, CAT, > HEAD, etc. But when I try to edit them with vi, I get > "not an ascii file". Any suggestions appreciated. As I recall, Prime typically stores text in 7-bit ASCII with the high bit SET. On the receiving end, do something like tr '[\201-\377]' '[\001-\0177]' < prime_data > unix_data if your "tr" can handle it, or write a small C program to do the same thing.
schwartz@gondor.cs.psu.edu (Scott Schwartz) (04/30/88)
In article <533@zoot.lamont.Columbia.edu> hough@lamont.Columbia.edu (sue hough) writes: >I am trying to read an ascii (Prime generated) 9-track tape on a Unix > system. The restored files look like ascii when I use MORE, CAT, > HEAD, etc. But when I try to edit them with vi, I get > "not an ascii file". Any suggestions appreciated. Prime sets the high bit of all characters. Vi thinks that characters with the high bit set are not ascii. A clash of wills takes place :-) Use tr to map all the prime-ascii characters to real ascii. -- Scott Schwartz schwartz@gondor.cs.psu.edu schwartz@psuvaxg.bitnet
ok@quintus.UUCP (Richard A. O'Keefe) (04/30/88)
In article <533@zoot.lamont.Columbia.edu>, hough@lamont.Columbia.edu (sue hough) writes: > I am trying to read an ASCII (Prime generated) 9-track tape on a Unix > system. The restored files look like ASCII when I use MORE, CAT, > HEAD, etc. But when I try to edit them with vi, I get "not an ascii file". As you probably know, ASCII is the American version of ISO 646, which assigns character/control meanings to integer in the range 0..127. PR1ME, in their infinite wisdom, decided that character codes should range from 128 to 255. (Now that ISO 8859/1 assigns meanings to 0..255, this may leave PR1ME looking even less brilliant.) more, cat, and head are simply copying the bytes they find to the terminal, but your terminal driver is almost certainly stripping the parity bit off. cat and head are supposed to work on arbitrary byte streams after all. A quick way to verify whether this is the problem is to look at the file with the 'od' command. Suppose the file is called PR1ME.DAT. Do od -b PR1ME.DAT This prints the bytes as unsigned octal. If the numbers you see are 200 or more, this is the problem, and you will have to feed your files through a program such as cat >pr1me-to-ascii.c <<'ENDOFFILE' #include <stdio.h> main() { int c; while ((c = getchar()) != EOF) putchar(c & 0177); exit(0); } ENDOFFILE You may have some other problems as well: PR1ME assigned meanings like "insert N spaces" and "copy N characters from the previous record" to some of the ASCII control characters.
g-rh@cca.CCA.COM (Richard Harter) (05/23/88)
In article <2802@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >In article <533@zoot.lamont.Columbia.edu> hough@lamont.Columbia.edu (sue >hough) writes: >>I am trying to read an ascii (Prime generated) 9-track tape on a Unix >> system. The restored files look like ascii when I use MORE, CAT, >> HEAD, etc. But when I try to edit them with vi, I get >> "not an ascii file". >I seem to remember that Primos likes the eighth bit set in each >character. It must be that vi doesn't like this. Write a filter to >strip these bits, or use Chuck Forsberg's undos/todos utility with the >-s switch. There are two problems. The first is that Primos ascii has the eighth bit set. The second is that it uses "compressed ascii". Strings of blanks are replaced by a control byte followed by a count byte. The original does not say how the ascii tape was generated. It might have been generated using primix (which looks like unix on the surface but is primos underneath), by one of the system utilities (MAGNET or MAGSAVE), or by a program (e.g. fortran). It matters. Each of these methods has its own eccentricities. Probably the simplest way to get data from a prime via tape is to ask the prime source to produce an IBM compatible tape written in EBCDIC :-). -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.