Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!quintus!ok From: ok@quintus.UUCP (Richard A. O'Keefe) Newsgroups: comp.unix.questions Subject: Re: ascii or not ascii Message-ID: <920@cresswell.quintus.UUCP> Date: 30 Apr 88 02:56:08 GMT References: <533@zoot.lamont.Columbia.edu> Organization: Quintus Computer Systems, Mountain View, CA Lines: 36 Keywords: ascii, prime Summary: PR1ME code = ASCII + 128 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 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.