Mail Archives: djgpp/1994/10/17/04:56:02
> I have long agreed with Marty Leisner's position that making binary,
> not text, the default in file I/O, is the nearly perfect solution to
> this *for personal use*. For historical reasons I hesitate to suggest
> this for the DJGPP package as a whole, and of course for wide
> distribution of general-purpose utilities like cp, rm, and so on this
> is just not robust enough.
Alas, the problem is not with cp, rm and such like, but with more
sophisticated programs which need to ``understand'' their input.
Take, for example, protoize or Info programs. If you feed them
DOS-style text file (with CR-LF pairs at the end of each line),
they will refuse to run, even if O_BINARY is the default open
mode. For these, the best cure is to call crlf2nl() right after
you read() a chunk (and then, sigh, you have also to update their
notion of the count of characters they've read...).
Other programs just can't be made right for DOS without adding
options which tell them explicitly what you mean. An example is
wc. Do we tell it to count those CRs as characters or do we not?
This alone is sufficient to start a religious war, so it's usually
safer to permit doing both at user's will at the price of an extra
option.
Personally, I don't like the dos2unix approach, because it gets
in the way of the user too much.
>> 3) DOS limitations and peculiarities, like 8.3 filenames, drive
>> letter as part of filename, etc.
>
> A lot of this gets handled by DJGPP, either in the library or GO32, it
> seems to me.
A lot, but not all of it. Examples: the typical backup filename
generation paradigm (just add a suffix to the original name); the
blind belief that a dot is just like any other pathname character; and
the assumption that only filenames which begin with `/' are absolute
(what about c:/dir1/dir2/file?).
- Raw text -