On 2018-05-19 13:43:14 +0100, bartc wrote: > On 19/05/2018 12:33, Peter J. Holzer wrote: > > On 2018-05-19 11:33:26 +0100, bartc wrote: > > > > Not you understand why some of us don't bother with 'text mode' files. > > > > "Not" or "Now"? > > Now. > > > Yesterday you claimed that you worked with them for 40 years. > > Text files, yes. Not 'text mode' which is something inflicted on us by the C > library.
I very much enjoy the fact that the programming languages I've used to
process text files in the last 15 years (i.e. Perl and Python) can
convert just about any character encoding and any newline convention to
a canonical representation with a single parameter to open.
When the "textmode" in the C library was invented (it wasn't just C,
though: Wirth's Modula-2 book describes a remarkably similar mechanism)
the situation was a lot more complicated: Many operating systems didn't
have a newline character (or character sequence). They had fixed length
records or a length indicator at the start of each line or even more
complicated schemes. The textmode removes these differences - you always
get lines terminated by \n. Without a textmode, you would have to deal
with all those different file formats if you wanted to write a portable
version of even a simple program like cat. The world has become simpler
in this regard.
> > > However if you have an actual EBCDIC system and would to read .ppm files,
> > > then you will have trouble reading the numeric parameters as they are
> > > expressed using sequences of ASCII digits.
>
> > I think the simplest way would be perform the calculation by hand
> > (new_value = old_value * 10 + next_byte - 0x30). At least in a language
> > which lets me process individual bytes easily. That would even work on
> > both ASCII and EBCDIC based systems (and on every other platform, too).
>
> /The/ simplest? Don't forget the numbers can be several digits each. Here's
> how I read them (NOT Python):
>
> readln @f, width, height
>
> Would it work in an EBCDIC based system? Probably not. But, who cares?
The premise in your previous message was that you are on an EBCDIC based
system (and a quite limited at that which doesn't even have a character
set conversion library, so you would have to program the character set
conversion yourself). So you can't cop out with "I don't care about
EBCDIC based systems".
(Your single readln wouldn't work reliably on ASCII systems either,
since - as others have already pointed out - the header format of a PPM
file isn't quite as simple as you imagine).
> (Perhaps someone who has access to an EBCDIC system can try a .PPM reader to
> see what happens. I suspect that won't work either.)
A PPM reader for an EBCDIC system will certainly be able to read PPM
files on an EBCDIC system. Why would anybody write and release software
which doesn't work on the intended target system?
hp
--
_ | Peter J. Holzer | we build much bigger, better disasters now
|_|_) | | because we have much more sophisticated
| | | h...@hjp.at | management tools.
__/ | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
signature.asc
Description: PGP signature
-- https://mail.python.org/mailman/listinfo/python-list
