ascii or not ascii

Richard A. O'Keefe ok at quintus.UUCP
Sat Apr 30 12:56:08 AEST 1988


In article <533 at zoot.lamont.Columbia.edu>, hough at 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.



More information about the Comp.unix.questions mailing list