From:	jls11 AT po DOT CWRU DOT Edu (John L. Spetz)
Newsgroups:	comp.os.msdos.djgpp
Subject:	DJGCC port of GREP has option -U but no opposite
Date:	18 Feb 1998 02:57:30 GMT
Organization:	Case Western Reserve University, Cleveland, OH (USA)
Lines:	29
Message-ID:	<6cdimq$br9$1@alexander.INS.CWRU.Edu>
Reply-To:	jls11 AT po DOT CWRU DOT Edu (John L. Spetz)
NNTP-Posting-Host:	owl.ins.cwru.edu
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

I notice that the DJGCC port makes a distinction between
text files and binary ones.  Since the line separating
convention for DOS is to use ASCII-13 (ie carriage return)
followed by ASCII-10 (ie line feed) where UNIX uses ASCII-10
alone, the DOS port will strip trailing ASCII-13 characters
from a line (internally).  This is of course so regular
expressions that use $ to search for end of line will not
be broken by spurious ASCII-13 ^M characters being considered
part of each line of text.  

So far so good; this allows code for UNIX to behave reasonable
for straight forward DOS text files.  Option -U or --binary
is provided in the DOS port of GREP to force GREP to treat a
file which appears to be text as binary so the -b or 
--byte-offset option will work as advertized.

What there is *not* is an option to force treatment of an
apparently binary file as DOS text.  It is kind of annoying
when an otherwise pure text file has stray "binary" characters
and is then treated as a binary file.  Aside from some regular
expressions breaking this leads to extra blank lines being
output when the -v or --revert-match option is used.  I wonder
if there could be an option -T alias --text which simply forces
the code that guesses whether a file is binary or text to
assume a file is text.  I could provide a diff that does this,
I suppose, but would there be any chance of it being officially
adopted?  

- Raw text -