Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!CMR001.BITNET!Jacques_Gelinas From: Jacques_Gelinas@CMR001.BITNET Newsgroups: comp.sys.apollo Subject: (none) Message-ID: <8905230413.AA23343@umix.cc.umich.edu> Date: 23 May 89 04:13:24 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 182 Received: from Jacques_Gelinas by CMR001.BITNET 23 May 89 00:09:44 EDT Date: 22 May 89 23:58:00 EDT From: Jacques Gelinas To: Subject: Unix eof detection and long filenames under tar. Hi. I have undertaken the task of installing TeX2.95 on our 25 DN3000 + 3 DN4000 Apollo network, without previous experience with UNIX or C (Well actually, I know PDP/11 assembly language contructs like "CMP (SP)+,(SP)+" and it helps) But the software distributed by Pierre Mackay of the U. of W. is so well written that it worked first time! (also shows that BSD4.2 at SR9.7 is compatible with other systems) Here are four simple questions, with some rather long inputs. Merci de votre attention. Thanks for your time. ========================================== First question: tar and very-very-long-filenames After figuring out how to insert a QUIC24 cartridge in a drive (a 10 cents sticker from Apollo would be usefull for me since the unit is on the floor and the picture in the manual "Operating the DN3000" is not clear), the tar program displayed the following messages (the drive is on a DN4000 and the 32MB were copied over the network to another DN4000 disk -- and it took tar 3hrs or so to make a backup tape). Can I get these files out of the tape ? (How did prof. Mackay get them on the tape ?) ========================================== % date Wed Mar 22 16:55:51 EST 1989 % tar xf /dev/rct8 tar: cannot open /dev/rct8 % mt -f /dev/rct8 retension % tar xf /dev/rct8 tar: ./tex82/README.WRITE-WHITE - cannot create tar: ./DVIware/laser-setters/dvi2adobe_fonts/ StoneInformal-SemiboldItalic.tfm - cannot create (10 similar lines deleted) % date Wed Mar 22 19:41:51 EST 1989 ========================================== Second question: Paranoia and (text) eof Just as FORTRAN systems have trouble with READ(*,*,ERR=99,END=99), it seems that portable UNIX eof detection is not easy. The (UNIX) TeX software does it as follows. Can this be simplified on Apollo BSD4.2 systems ? ========================================== /* testeof(filep) ** Test whether or not the Pascal text file with iorec pointer filep ** has reached end-of-file (when the only I/O on it is done with ** lineread, above). ** We may have to read the next character and unget it to see ** if perhaps the end-of-file is next. */ testeof(iop) FILE *iop; { register int c; if (feof(iop)) return(TRUE); else { /* check to see if next is EOF */ c = getc(iop); if (c == EOF) return(TRUE); else { (void) ungetc(c,iop); return(FALSE); } } } ========================================== Third question: eof and binary files. I understand that functions such as getc, putc are not implemented the same way on all systems (but why is -3/2 undefined? --i digress) However the following program -my 5th C program- shows that even on the same system getc and fgetc are not equivalent. It writes 4 bytes on a file, rewinds the file, and reads the 4 bytes back by calls to fgetc, getc, fgetc, getc. It seems that fgetc does not work consistently (at least for SR9.7). The 2nd ed. of the K.R. white book describes a binary stream as an unformatted stream of bytes that can be written, read back and compared equal on the same system. Does this fail to implement a binary stream on a DN3000 ? (no change for sys5, SR9.7) Could someone explain to me the line "fgetc returns EOF: Error 0" ? Why is the first use of fgetc different ? (By permuting the calls to getc and fgetc, you can get other results. This looks weird.) ========================================== % printenv NODETYPE=DN3000 PROJECT=prof ORGANIZATION=math SYSTYPE=bsd4.2 % cat fgetc.c==getc.c /* ------ is fgetc "like" getc ? -------- */ main (){ # include FILE * datf ; int c ; datf = fopen("fgetc.dat","w+") ; # define BYTE 0377 printf( "BYTE = %o, (int)(char)BYTE = %o\n",BYTE,(int)(char)BYTE); if(fputc( BYTE, datf)==EOF ) perror("fputc returns EOF") ; if( putc( BYTE, datf)==EOF ) perror(" putc returns EOF") ; c = fputc(BYTE, datf ) ; printf("fputc: c = %o\n", c ) ; c = putc(BYTE, datf ) ; printf(" putc: c = %o\n", c ) ; fseek( datf, 0L, 0) ; if( (c = fgetc(datf)) == EOF ) perror("fgetc returns EOF") ; printf("fgetc: c = %o\n", c) ; if( (c = getc(datf)) == EOF ) perror(" getc returns EOF") ; printf(" getc: c = %o\n", c) ; if( (c = fgetc(datf)) == EOF ) perror("fgetc returns EOF") ; printf("fgetc: c = %o\n", c) ; if( (c = getc(datf)) == EOF ) perror(" getc returns EOF") ; printf(" getc: c = %o\n", c) ; if(fclose(datf)) perror("fclose") ; system( "od -b fgetc.dat ; rm -i fgetc.dat" ) ; } % cc !* cc fgetc.c==getc.c % a.out BYTE = 377, (int)(char)BYTE = 37777777777 fputc returns EOF: Error 0 putc returns EOF: Error 0 fputc: c = 37777777777 putc: c = 37777777777 fgetc: c = 377 getc: c = 377 fgetc returns EOF: Error 0 fgetc: c = 37777777777 getc: c = 377 0000000 377 377 377 377 0000004 rm: remove fgetc.dat? y ========================================== Last question: default cc flags All the machines we have are DN3000 or DN4000. Why is it necessary to specify the -M3000 flag for the cc compiler? The RT/11 operating system permitted me -in 1979- to customize the compilers by setting some switches (like the number of lines per page for listings). Can this be done also at installation time for the Apollo system? ========================================== J. GELINAS