> It is interesting to note that "linein" was used, which means > that the author expected and indicated processing a text > file. Now, a LF or CR-LF sequence on "linein" (and "lineout" > for that matter) are never part of the read data (and > appended automatically with lineout/say when writing textual > data). So text files have been processed in Rexx always in a > different way than binary files (for which charin/charout > would be available), making it easy for the programmer to > process them. I can see that Rexx programmers might therefore > expect automatic BOM-handling on non-ASCII text files, if the > Rexx programmer uses "linein" or "lineout/say".
Not true, Rony .. in record-oriented file systems the line-end sequence was (is) metadata, and therefore lines could (can) include all 256 byte possibilities. In a similar way, UTF8 files could be catered for by (for example) UnicodeIn() and UnicodeOut() functions. But changing the definition of charin and linein makes very little sense -- and would surely break many programs: starting with the humble 'thex' that lets on see every byte in a file in hex, regardless of whether it is normally 'printable' or not. Mike ------------------------------------------------------------------------------ Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d _______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
