On Fri, 29 May 2015 09:03:59 -0500, Ze'ev Atlas wrote:
>
>It is apparent that IBM chose to mark the end of line with NL and not with any
>of LF or CRLF. That on itself is probably a correct decision and probably
>what the standard should have been to begin with. The problem is that in the
>C language convention, the escape sequence \n has subtle double meaning. It
>means LF but it also contains within it the semantics of NL.
>
The semantic of "\n" is implementation-dependent. In Linux, it compiles as
<LF>;
in z/OS as <NL> (But, I believe, as <LF> in Enhanced ASCII mode); and in
Classic Mac OS (pre OS X) as <CR>.
>When we do
>printf ("some text \n");
>it will work correctly on all platforms and nobody would ever notice any
>problem. it will produce on EBCDIC
>some text NL
>and on ASCII platforms
>some text LF
>or
>some text CRLF
>
Much of this is handled by the device driver.
>But when we issue a pattern matching (I'll use Perl syntax for brevity)
>if ($text =~ /some text \n/)
>the \n is translated by convention to LF and the EBCDIC based pattern matching
>will fail to match!
>
That problem should not occur. By z/OS convention, \n represents <NL> and
then pattern matching succeeds. What z/OS facility treats \n as <LF>?
>So the solution should be to somehow (optionally) dictate to the package that
>\n is NL and not LF. I've requested that such option would be implemented so
>I can use it.
>
That should not be necessary. Can you provide more context for your example?
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
