in reply to Re: file type
in thread file type

Actually, that's not entirely correct. Under UNIX, a file is a file is a file. There is no differentiation between binary and ASCII- that's why the standard UNIX streams have no need for binmode. A simple stream of bits is what you get when you read from a stream. DOS-based systems are the ones that require binmode and they differentiate between ASCII and binary even in the characters that are used in similar representations. PAGERs like to make a good guess and warn you if you try to PAGER an actual binary file but it does this by reading the file a bit and checking for non-ascii character bytes. In fact, under UNIX, it is entirely impossible to tell what a stream-type file is (devices and ttys are easy to check for).
AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.

Replies are listed 'Best First'.
Re: Re: Re: file type
by sierrathedog04 (Hermit) on Feb 09, 2001 at 10:59 UTC
    And another point, which I came across while reading Learning Perl, is that Perl itself does not differentiate between binary and text files. I can read a binary file into a string and manipulate the string value, truncate it, etc. just as I can read a text file into a string.

    The authors say that this feature of Perl is a result of Perl using a full byte (256 possible permutations of the 8 bits) to store each character of a string. ASCII characters only take up 7 bits apiece, so the ASCII character set is incapable of easily representing a binary file. It is hard to say why Larry chose to represent characters as 256 bits apiece, thus allowing strings to contain a binary file.

    I suspect it had more to do with a need to represent Asian languages than it did with any desire to store binary files as strings.

[reply]

In Section Seekers of Perl Wisdom