From:	Eric Backus <ericb AT lsid DOT hp DOT com>
Subject:	Re: O_BINARY (was Re: Re[2]: zip format for gnu tools avaiable )
To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Date:	Wed, 13 Apr 94 9:55:11 PDT
Mailer:	Elm [revision: 70.85]

> hmmm,,,this is strange...
> 
> About 5 years ago, I did an extensive C library for ms/dos which
> include most of the Unix type functions (including a working fork (for the 
> small model),
> exec which passed arguments in the environment; non-blocking IO, 
> directory traversal, time routines and whole bunch of other stuff.
> 
> I looked at the dos O_BINARY flag, concluded bytes were bytes, and
> did away with it in my implementation of the library...
> 
> I can port most Unix code which compiles into the small model on this
> so obviously it works... ;-)

Well, I guess it depends on what you mean by "it works".  If you run,
for example, "grep", and the output is left in binary mode, then the
lines will be terminated with just '\n', not '\r\n'.  If this gets
dumped to your screen, it probably won't look right because the screen
(being DOS oriented) wants to see a '\r'.  This is an example where
binary mode might be the wrong thing to do.

Just to show that this is not an isolated example, I'd argue that the
following utilities available from FSF should have text-mode input and
output:

	cat -n, cat -b, cat -E
	bc, dc
	cksum, sum
	cut, fold, paste
	date
	df
	diff, diff3, sdiff, wdiff
	doschk
	egrep, fgrep, grep
	env, printenv
	expr, printf
	find . -print, locate
	heading lines from "head file1 file2",
		"tail file1 file2", or "pr file"
	id, logname, tty, uname, who, whoami
	indent
	ls
	od

On the other hand, I think the following should have binary-mode
input and output:

	cat, tac
	compress, uncompress
	expand, unexpand
	gzip, gunzip, zcat
	non-heading lines from "head file1 file2",
		"tail file1 file2", or "pr file"
	nl
	recode
	sed
	sort
	split
	tee
	tput
	tr
	uniq
	uudecode, uuencode
	wc
--
				Eric Backus
				ericb AT lsid DOT hp DOT com
				(206) 335-2495

- Raw text -