Mail Archives: djgpp/1994/04/13/13:30:16
> 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 -