On Thu, 4 Jun 2015 19:19:56 -0500, Bill Godfrey wrote:
On Thu, 4 Jun 2015 11:05:15 -0400, Shmuel Metz (Seymour J.) wrote:
In 4767436570688083.wa.bgodfrey.gzgmail@listserv.ua.edu, on
06/01/2015
at 10:18 PM, Bill Godfrey said:
The grep and awk commands don't match \n to end-of-line on
On Thu, 4 Jun 2015 11:05:15 -0400, Shmuel Metz (Seymour J.) wrote:
In 4767436570688083.wa.bgodfrey.gzgmail@listserv.ua.edu, on
06/01/2015
at 10:18 PM, Bill Godfrey said:
The grep and awk commands don't match \n to end-of-line on omvs,
or on linux for that matter.
Don't they match \n to
In 4767436570688083.wa.bgodfrey.gzgmail@listserv.ua.edu, on
06/01/2015
at 10:18 PM, Bill Godfrey bgodfrey...@gmail.com said:
The grep and awk commands don't match \n to end-of-line on omvs,
or on linux for that matter.
Don't they match \n to LF on most Eunix and *ix systems?
Do '/test$/'
On Mon, 1 Jun 2015 22:18:20 -0500, Bill Godfrey wrote:
The grep and awk commands don't match \n to end-of-line on omvs, or on
linux for that matter.
awk certainly does. To wit:
user@OS/390.24.00: cat awknl
#! /bin/sh -x
awk 'BEGIN {
On Tue, 2 Jun 2015 03:17:35 -0500, Paul Gilmartin wrote:
On Mon, 1 Jun 2015 22:18:20 -0500, Bill Godfrey wrote:
The grep and awk commands don't match \n to end-of-line on omvs, or on
linux for that matter.
awk certainly does. To wit:
user@OS/390.24.00: cat awknl
On Tue, 2 Jun 2015 05:48:31 -0500, Bill Godfrey wrote:
I was only referring to \n in the pattern used in awk's general pattern
{action} syntax, where the pattern
is matched against text being read. I should have qualified my statement.
This is a characteristic not of awk's pattern matching but
In 5568a3c8.5030...@gmail.com, on 05/30/2015
at 01:37 AM, David Crayford dcrayf...@gmail.com said:
It implicitly converted strings to ASCII
That's good if you want them converted; not so good if you don't.
She died of a favor
from which none could save her.
and that was the end of
In 0379604180364016.wa.bgodfrey.gzgmail@listserv.ua.edu, on
05/29/2015
at 10:30 AM, Bill Godfrey bgodfrey...@gmail.com said:
I get identical results whether I use \n or $ in the OP's example. In
OMVS. I'm not addressing your question but rather the OP's example.
Which OMVS facilities
On Mon, 1 Jun 2015 17:11:54 -0400, Shmuel Metz (Seymour J.)
shmuel+ibm-m...@patriot.net wrote:
In 0379604180364016.wa.bgodfrey.gzgmail@listserv.ua.edu, on
05/29/2015
at 10:30 AM, Bill Godfrey bgodfrey...@gmail.com said:
I get identical results whether I use \n or $ in the OP's example.
In 5567e81c.4040...@vse2pdf.com, on 05/29/2015
at 12:16 AM, Tony Thigpen t...@vse2pdf.com said:
1960's ATT pushes for a replacement of ITA2 which the ATA published
as ASCII in 1963.
I might believe ASA, through several iterations. I hate overloaded
code points!
--
Shmuel (Seymour J.)
In 838271083.1045039.1432870193420.javamail.ya...@mail.yahoo.com, on
05/29/2015
at 03:29 AM, Ze'ev Atlas
004b34e7c98a-dmarc-requ...@listserv.ua.edu said:
Does anybody know why do we need two characters that seem to do the
same thing
No, especially since they *don't* do the same thing. A
In 8215077812992901.wa.paulgboulderaim@listserv.ua.edu, on
05/29/2015
at 12:27 AM, Paul Gilmartin
000433f07816-dmarc-requ...@listserv.ua.edu said:
Using a device-specific hardware command to separate records in a
general file makes as little sense as Assembler H's use of machine
Gil is correct, \n is implementation dependent.
Actually, PCRE handles it correctly, except that I've got confused and chose an
incorrect option in my config.h. Once I've corrected it tests run smoothly and
produce correct test results.
Thanks all for explanations and advice
ZA
On 29/05/2015 1:43 PM, Anne Lynn Wheeler wrote:
EBCDIC and the P-Bit, The Biggest Computer Goof Ever
http://www.bobbemer.com/P-BIT.HTM
The culprit was T. Vincent Learson. The only thing for his defense is
that he had no idea of what he had done. It was when he was an IBM Vice
President, prior
Thank you all for comprehensive explanation
ZA
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Your messages clarified my issue and actually assured me that the solution I'd
suggested is correct, so I would like to brief you.
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
On Fri, 29 May 2015 09:56:20 -0500, Paul Gilmartin paulgboul...@aim.com wrote:
On Fri, 29 May 2015 09:52:42 -0500, Bill Godfrey wrote:
On Fri, 29 May 2015 09:03:59 -0500, Ze'ev Atlas wrote:
But when we issue a pattern matching (I'll use Perl syntax for brevity)
if ($text =~ /some text \n/)
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
On Fri, 29 May 2015 09:03:59 -0500, Ze'ev Atlas wrote:
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!
why not this?
if ($text =~ /some text
On Fri, May 29, 2015 at 9:31 AM, Paul Gilmartin
000433f07816-dmarc-requ...@listserv.ua.edu wrote:
On Fri, 29 May 2015 19:54:20 +0800, David Crayford wrote:
And how much has that dumb decision cost mainframe customers over the
years? Fiasco is the right word.
And IBM could have
On Fri, 29 May 2015 09:52:42 -0500, Bill Godfrey wrote:
On Fri, 29 May 2015 09:03:59 -0500, Ze'ev Atlas wrote:
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
On 29/05/2015 10:31 PM, Paul Gilmartin wrote:
On Fri, 29 May 2015 19:54:20 +0800, David Crayford wrote:
And how much has that dumb decision cost mainframe customers over the
years? Fiasco is the right word.
And IBM could have recovered, rather than compounding the fiasco at
the inception of
change the file!? That's exactly what I don't want, and it gives me no
choice. Notepad++ and vim do better: they allow the user to choose the
output format, defaulting to the original input format.
Paul,
It was part of a general comment about how even Microsoft has different
rules in
On Fri, 29 May 2015 00:16:28 -0400, Tony Thigpen wrote:
Interesting, Windows Notepad requires CRLF, but Windows Wordpad will
read and display a LF only file correctly and even change the file to
CRLF when saved.
change the file!? That's exactly what I don't want, and it gives me no
choice.
john.archie.mck...@gmail.com (John McKown) writes:
As a side note (as I have heard it), the reason that Windows uses CRLF
as a line ending is because MS-DOS did the same. MS-DOS used CRLF
because CPM-80 used CRLF. And, finally, CPM-80 used CRLF because the
common printers at the time could not
On Fri, 29 May 2015 19:54:20 +0800, David Crayford wrote:
And how much has that dumb decision cost mainframe customers over the
years? Fiasco is the right word.
And IBM could have recovered, rather than compounding the fiasco at
the inception of OMVS by making OMVS ASCII based and providing
Hi allI am dealing with some C package on classic z/OS (PDS/E, no USS). When C
reads text files it inserts 0x15 in the end of the record (it goes that far as
to drop the trailing blanks and substitute them with one 0x15 for fixed length
records, but I think that there is an option to override
It's actually much worse. There are three:
Ebcdic:
CR = x0D
NL = x15
LF = x25
Originally, CR only moved the print back to the first position of the
same line. LF only moved the print down one line without moving
sideways. NL moved both down and to the first position of the line.
When it was
t...@vse2pdf.com (Tony Thigpen) writes:
It's actually much worse. There are three:
Ebcdic:
CR = x0D
NL = x15
LF = x25
Originally, CR only moved the print back to the first position of the
same line. LF only moved the print down one line without moving
sideways. NL moved both down and to
On Thu, 28 May 2015 23:34:53 -0500, John McKown wrote:
0x15 is _NOT_ a Line Feed character. It is a New Line (NEL) character from
the 3215 console days. In EBCDIC, 0x25 is the true Line Feed character. On
the 3215, the NEL
was a single byte which did a carriage return and line feed operation
On Thu, May 28, 2015 at 10:29 PM, Ze'ev Atlas
004b34e7c98a-dmarc-requ...@listserv.ua.edu wrote:
Hi allI am dealing with some C package on classic z/OS (PDS/E, no USS).
When C reads text files it inserts 0x15 in the end of the record (it goes
that far as to drop the trailing blanks and
31 matches
Mail list logo
