[33134] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 4412 Volume: 11

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Apr 11 16:09:20 2015

Date: Sat, 11 Apr 2015 13:09:05 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)

Perl-Users Digest           Sat, 11 Apr 2015     Volume: 11 Number: 4412

Today's topics:
    Re: "Deep Recursion" warning on factorial script. <lionslair@consolidated.net>
    Re: "Deep Recursion" warning on factorial script. <see.my.sig@for.my.address>
    Re: "Deep Recursion" warning on factorial script. <hjp-usenet3@hjp.at>
    Re: "Deep Recursion" warning on factorial script. <ben.usenet@bsb.me.uk>
    Re: "Deep Recursion" warning on factorial script. <gamo@telecable.es>
    Re: "Deep Recursion" warning on factorial script. <see.my.sig@for.my.address>
        perl one-liner to remove multiline stanza? <dkoleary@olearycomputers.com>
    Re: perl one-liner to remove multiline stanza? <rweikusat@mobileactivedefense.com>
    Re: perl one-liner to remove multiline stanza? <rweikusat@mobileactivedefense.com>
    Re: perl one-liner to remove multiline stanza? <dkoleary@olearycomputers.com>
    Re: Regex replace line breaks (Seymour J.)
    Re: Regex replace line breaks <news@todbe.com>
    Re: Regex replace line breaks <kaz@kylheku.com>
    Re: Regex replace line breaks <lionslair@consolidated.net>
    Re: Regex replace line breaks <see.my.sig@for.my.address>
    Re: Regex replace line breaks <hjp-usenet3@hjp.at>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Fri, 10 Apr 2015 22:13:19 -0500
From: Martin Eastburn <lionslair@consolidated.net>
Subject: Re: "Deep Recursion" warning on factorial script.
Message-Id: <Qj0Ww.255068$bk5.103789@fx06.iad>

It is a way to 'stack itself to death'  e.g. run out of memory or 
working area.   Some software has stacks in low memory thinking it is
safe.  But recursion if not cleaned or cleared can keep adding memory 
blocks that eventually write onto real code.

I used to do a lot of Machine code writing.  In small memory one trains
minds to do strange things.  Knowing how instructions are made, one 
could in real time modify the main flow or data base address by storing 
data.

I wrote some code that was impossible to copy into assembly.  It was to
tight and efficient.   I was able to do assembly in larger memory due to
the restrictive rules of the compiler.

My machine code was kept to under 4k instructions.  Above that I used 
assembly as it was on a larger machine.

Martin

On 4/8/2015 10:41 PM, John Black wrote:
> In article <mg41bh$t9u$1@news.grnet.gr>, gravitalsun@hotmail.foo says...
>>
>> On 8/4/2015 4:08 pµ, Robbie Hatley wrote:
>>>
>>> I cooked-up and ran the following script today and it worked fine,
>>
>> make a favor to you computer and yourself and never use recursion when
>> you can do it with a flat iterator like a for
>
> I'm sure Robbie knows that just as I doubt he actually needed a factorial sub at the moment.
> He seems to be experimenting with Perl to better understand its capabilities and limits.
>
> I'm curious myself, how deep would you feel comfortable going with in recursion?  Hundreds
> obviously.  Thousands?  More?
>
> In my programming, the most natural uses I've found for recursion was when traversing a
> hierarchy (in VHDL for example).  Like any language, a top level calls modules, which call
> other modules and so on.  Recursion is a natural way to walk the hierarchy.  But I was never
> worried about blowing through the stack because while there is no real limit on how deep the
> hierarchy could go, no actual design would go deeper than a dozen or so levels.
>
> John Black
>


------------------------------

Date: Sat, 11 Apr 2015 01:51:08 -0700
From: Robbie Hatley <see.my.sig@for.my.address>
Subject: Re: "Deep Recursion" warning on factorial script.
Message-Id: <AaOdnWGu44LsfbXInZ2dnUVZ572dnZ2d@giganews.com>


On 4/8/2015 8:41 PM, John Black wrote:

 > I'm sure Robbie knows that just as I doubt he actually needed a
 > factorial sub at the moment. He seems to be experimenting with
 > Perl to better understand its capabilities and limits.

Yes, exactly.

In this particular case, it would cost much less time and memory
to do this:

#! /usr/bin/perl
use Math::BigInt;
my $x = Math::BigInt->new(1);
printf("%3d! = %158s\n", $_, $x *= $_) for 1..100;

However, I was interested in playing with recursion, many levels deep,
to see how well that works in Perl.

 > I'm curious myself, how deep would you feel comfortable going
 > with in recursion?  Hundreds obviously.  Thousands?  More?

I'd say that depends a lot on the hardware and the OS, and how
many levels of recursion *they* can handle well. (If you see
messages such as "stack overflow" on your screen, that's a bad
sign.)

For me as a programmer, I'm not averse to any amount of recursion,
even infinite. Yes, there are some uses for infinite recursion.
I seem to recall, for example, that some of Srinivasa Ramanujan's
formulas for computing Pi involve infinite recursion. Code the
algorithm, then let it run until the machine runs low on stack space,
then terminate the recursion, unwind the stack, and print the result

 > In my programming, the most natural uses I've found for recursion
 > was when traversing a hierarchy (in VHDL for example).  Like any
 > language, a top level calls modules, which call other modules and
 > so on.  Recursion is a natural way to walk the hierarchy.  But I
 > was never worried about blowing through the stack because while
 > there is no real limit on how deep the hierarchy could go, no
 > actual design would go deeper than a dozen or so levels.

I've used recursion in similar ways, such as in a templated
C++ function object called "cursdirs" which navigates a directory
tree and applies a given function f to each subdirectory in the
tree. At each level, cursdirs(f) does these steps (in pseudo-code):


subdirs = list_of_subdirectories()
numdirs = size(subdirs)
if (numdirs > 0) {
    for ( i=0 ; i < numdirs ; ++i) {
       cd subdirs[i] // make subdirs[i] your new CWD
       cursdirs(f)   // RECURSE
       cd ..         // cd back to previous CWD
    }
}
f()                 // execute f() for current directory


I'd like to implement that in Perl. Shouldn't be too hard.
Just pass f to cursdirs as a "ref to sub" perhaps:


#! /usr/bin/perl
#  /rhe/scripts/test/pass-sub-ref-test
use v5.14;
use strict;
use warnings;

sub f {
    say "Hello, World!";
    # do something to files in current directory
}

sub cursdirs (&) {
    my $f = shift;
    # make list of subdirs
    #if any subdirs exist:
       # cd to each one
       # recurse
       # cd back to ..
    $f->();
}

cursdirs(\&f);
exit 0;


Something like that.

(A wicked thought just occurred to me: one could defeat such code
by making a directory a link to one of its own ancestors. That
would cause the above algorithm to go into infinite recursion.
Let me research that. Hmmm. According to my reading, it's
apparently not possible in Windows, Cygwin, or Linux, but is
possible in some old versions of Unix.)


-- 
Cheers,
Robbie Hatley
Midway City, CA, USA
perl -le 'print "\154o\156e\167o\154f\100w\145ll\56c\157m"'
http://www.well.com/user/lonewolf/
https://www.facebook.com/robbie.hatley



------------------------------

Date: Sat, 11 Apr 2015 12:33:57 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: "Deep Recursion" warning on factorial script.
Message-Id: <slrnmihu4l.fp4.hjp-usenet3@hrunkner.hjp.at>

On 2015-04-08 16:17, Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
> John Black <jblack@nospam.com> writes:
>> In article <mg29r3$db2$1@speranza.aioe.org>, gamo@telecable.es says...
>>> It seems that the recursive calls counter is an acumulator.
>>> 
>>> Try this instead:
>>
>> But your code is still recursive.  What did you do to eliminate the
>> problem?
>
> Nothing. 

Right.

> This proceeds until factorial(200). Because the result for factorial($n -
> 1) is always already cached by time factorial($n) is called if $n > 1,
> the original function never really recurses.

And if you remove the loop and just call factorial(200), the "problem"
returns:

Deep recursion on anonymous subroutine at ./gamo2 line 13.
Deep recursion on subroutine "Memoize::_memoizer" at (eval 7) line 1.
Deep recursion on subroutine "main::factorial" at
/usr/share/perl/5.20/Memoize.pm line 245.

        hp


-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp@hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel


------------------------------

Date: Sat, 11 Apr 2015 11:44:30 +0100
From: Ben Bacarisse <ben.usenet@bsb.me.uk>
Subject: Re: "Deep Recursion" warning on factorial script.
Message-Id: <874mon0ws1.fsf@bsb.me.uk>

Robbie Hatley <see.my.sig@for.my.address> writes:
<snip>
> I've used recursion in similar ways, such as in a templated
> C++ function object called "cursdirs" which navigates a directory
> tree and applies a given function f to each subdirectory in the
> tree.
<snip>
> I'd like to implement that in Perl. Shouldn't be too hard.
> Just pass f to cursdirs as a "ref to sub" perhaps:
<snip>
> sub cursdirs (&) {
>    my $f = shift;
>    # make list of subdirs
>    #if any subdirs exist:
>       # cd to each one
>       # recurse
>       # cd back to ..
>    $f->();
> }
<snip>
> (A wicked thought just occurred to me: one could defeat such code
> by making a directory a link to one of its own ancestors. That
> would cause the above algorithm to go into infinite recursion.
> Let me research that. Hmmm. According to my reading, it's
> apparently not possible in Windows, Cygwin, or Linux, but is
> possible in some old versions of Unix.)

However, whilst you are indeed prevented from doing that, such links
do exist in unix-like file systems.  In fact they are ubiquitous.  If you
don't filter out . and .. from the listing of directories you will get
caught in a (recursive) loop.

-- 
Ben.


------------------------------

Date: Sat, 11 Apr 2015 15:54:42 +0200
From: gamo <gamo@telecable.es>
Subject: Re: "Deep Recursion" warning on factorial script.
Message-Id: <mgb93p$bcs$1@speranza.aioe.org>

El 09/04/15 a las 15:20, G.B. escribió:
>> Provided the developer is much more versed in the very limited language
>> called 'mathematics'[*] and less familiar with the properties/
>> possibilities of the device he is trying to control, this may be
>> regarded as true.
>
> Mathematicians never talk publicly about their private
> parts (operations). Knuth is an exception.

The developers of computer languages takes care of maths
in a very extensive sense, since they invented impossible
maths as

i = i + 1

-- 
http://www.telecable.es/personales/gamo/
The generation of random numbers is too important to be left to chance


------------------------------

Date: Sat, 11 Apr 2015 12:49:58 -0700
From: Robbie Hatley <see.my.sig@for.my.address>
Subject: Re: "Deep Recursion" warning on factorial script.
Message-Id: <TeidnZAI-NhB57TInZ2dnUVZ572dnZ2d@giganews.com>


On 4/11/2015 3:44 AM, Ben Bacarisse wrote:

> Robbie Hatley <see.my.sig@for.my.address> writes:
> ...
> > (A wicked thought just occurred to me: one could defeat
> > [recursive code] by making a directory a link to one of
> > its own ancestors. That would cause [recursive code]
> > to go into infinite recursion. Let me research that.
> > Hmmm. According to my reading, it's apparently not
> > possible in Windows, Cygwin, or Linux, but is possible
> > in some old versions of Unix.)
>
> However, whilst you are indeed prevented from doing that,
> such links do exist in unix-like file systems.  In fact
> they are ubiquitous.  If you don't filter out . and ..
> from the listing of directories you will get caught in a
> (recursive) loop.

Yes, some filtering is required. "." and "..", for sure.
But certain other things as well.

For example, in recent Windows versions (since Vista),
one can create a directory entry of type "SYMLINKD",
which is a  symbolic link to a directory. And yes,
it can point to one of its own ancestors. I just tested that.
Obviously I should not interpret "SYMLINKD" objects as being
directories in my cursdirs function, else it could end up
chasing its tail:

wd=C:\cygwin64\rhe\test-zone\tarsier
%mklink /D gargoyle \cygwin64\rhe\test-zone
symbolic link created for gargoyle <<===>> \cygwin64\rhe\test-zone

wd=C:\cygwin64\rhe\test-zone\tarsier
%d
  Volume in drive C is Dol Amroth
  Volume Serial Number is 1EA1-A0B9

  Directory of C:\cygwin64\rhe\test-zone\tarsier

04/11/2015  01:58 AM    <DIR>                       .
04/11/2015  01:58 AM    <DIR>                       ..
04/11/2015  01:58 AM    <SYMLINKD>                  gargoyle [\cygwin64\rhe\test
-zone]
                0 File(s)              0 bytes
                3 Dir(s)  126,570,000,384 bytes free

wd=C:\cygwin64\rhe\test-zone\tarsier
%cd gargoyle

wd=C:\cygwin64\rhe\test-zone\tarsier\gargoyle
%cd tarsier

wd=C:\cygwin64\rhe\test-zone\tarsier\gargoyle\tarsier
%cd gargoyle

wd=C:\cygwin64\rhe\test-zone\tarsier\gargoyle\tarsier\gargoyle
%cd tarsier

wd=C:\cygwin64\rhe\test-zone\tarsier\gargoyle\tarsier\gargoyle\tarsier
%cd gargoyle

wd=C:\cygwin64\rhe\test-zone\tarsier\gargoyle\tarsier\gargoyle\tarsier\gargoyle
%

Containing one's own self is topologically "interesting". :-)
Rather like standing in a hallway with large mirrors on both
sides, copies of me retreating to infinity.

Things such as ".", "..", and "SYMLINKD" are pretty easy to
filter-out, though. What worries me more would be a directory
which is a *hard* link to one of its own ancestors. How can one
tell, other than keeping track of all of the inodes in a tree
and rejecting any directory with an inode number seen before?

Hmmm. That might work.

sub cursdirs (&) {
    my $f = shift;
    stat @inodes;
    my @subdirs;
    # opendir , readdir , get directories only, closedir;
    # reject directories with inodes already in @inodes;
    # push each accepted directory's inode onto @inodes.
    # push each accepted directory's name  onto @subdirs
    # foreach (@subdirs) {
    #    `cd $_`;
    #    cursdirs(f);
    #    `cd ..`;
    # f->();
}


-- 
Cheers,
Robbie Hatley
Midway City, CA, USA
perl -le 'print "\154o\156e\167o\154f\100w\145ll\56c\157m"'
http://www.well.com/user/lonewolf/
https://www.facebook.com/robbie.hatley


------------------------------

Date: Fri, 10 Apr 2015 10:29:57 -0700 (PDT)
From: dkoleary <dkoleary@olearycomputers.com>
Subject: perl one-liner to remove multiline stanza?
Message-Id: <9c19928a-b4f8-47c1-b7d1-f352f82b8598@googlegroups.com>

Hey;

This really seems like it should be an easy one-liner, but apparently, I'm thick today because I can't even figure out how to  print just the target stanza

I'm looking to remove a multi-line stanza from a configuration file:

multipaths {
   multipath {
      wwid  360002ac0000000000000039d000085d9
          alias   mpatha
   }
   multipath {
      wwid  360002ac0000000000000039e000085d9
      alias gi_01
   }
   multipath {
      wwid  360002ac00000000000005a69000085d9
      alias afs1_01
[[snip]]
   multipath {
      wwid  360002ac000000000000003ab000085d9
      alias redo_03
   }
[[snip]]

I'm looking to remove the redo_03 stanza.  

Any help will be gratefully accepted.  Thanks

Doug O'Leary


------------------------------

Date: Fri, 10 Apr 2015 19:01:16 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: perl one-liner to remove multiline stanza?
Message-Id: <871tjr982b.fsf@doppelsaurus.mobileactivedefense.com>

dkoleary <dkoleary@olearycomputers.com> writes:
> I'm looking to remove a multi-line stanza from a configuration file:
>
> multipaths {
>    multipath {
>       wwid  360002ac0000000000000039d000085d9
>           alias   mpatha
>    }
>    multipath {
>       wwid  360002ac0000000000000039e000085d9
>       alias gi_01
>    }
>    multipath {
>       wwid  360002ac00000000000005a69000085d9
>       alias afs1_01
> [[snip]]
>    multipath {
>       wwid  360002ac000000000000003ab000085d9
>       alias redo_03
>    }
> [[snip]]
>
> I'm looking to remove the redo_03 stanza.  

perl -ne 'BEGIN { $/ = "}\n" } print unless /alias redo_03/;'


------------------------------

Date: Fri, 10 Apr 2015 19:08:29 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: perl one-liner to remove multiline stanza?
Message-Id: <87wq1j7t5u.fsf@doppelsaurus.mobileactivedefense.com>

Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
> dkoleary <dkoleary@olearycomputers.com> writes:
>> I'm looking to remove a multi-line stanza from a configuration file:
>>
>> multipaths {
>>    multipath {
>>       wwid  360002ac0000000000000039d000085d9
>>           alias   mpatha
>>    }
>>    multipath {
>>       wwid  360002ac0000000000000039e000085d9
>>       alias gi_01
>>    }
>>    multipath {
>>       wwid  360002ac00000000000005a69000085d9
>>       alias afs1_01
>> [[snip]]
>>    multipath {
>>       wwid  360002ac000000000000003ab000085d9
>>       alias redo_03
>>    }
>> [[snip]]
>>
>> I'm looking to remove the redo_03 stanza.  
>
> perl -ne 'BEGIN { $/ = "}\n" } print unless /alias redo_03/;'

This doesn't work for the first stanza as it then also eats the
multipaths-line. Assuming the format is really that simple,

perl -ne 'BEGIN { $_ = <>; print; $/ = "}\n" } print unless /alias\s+mpatha/;'

could be used to avoid this.


------------------------------

Date: Fri, 10 Apr 2015 11:15:24 -0700 (PDT)
From: dkoleary <dkoleary@olearycomputers.com>
Subject: Re: perl one-liner to remove multiline stanza?
Message-Id: <127ecbd4-aa5a-4e96-beea-5e44028c640b@googlegroups.com>

Hey;

That is awesome!  Thanks!  And, boy, was I ever on the wrong track.

Appreciate the help.

Doug O'Leary



------------------------------

Date: Fri, 10 Apr 2015 08:35:32 -0400
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: Regex replace line breaks
Message-Id: <5527c394$2$fuzhry+tra$mr2ice@news.patriot.net>

In <JfmVw.240687$Op6.213226@fx16.iad>, on 04/08/2015
   at 10:21 PM, Martin Eastburn <lionslair@consolidated.net> said:

>TTY's have been out of normal use for quite a while.  CR, CR, LF
>allowed the carriage to return from a long line, index and start
>printing.

I've never seen CR used as an idle character, only NUL. I gueess it
must be a unixism.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org



------------------------------

Date: Fri, 10 Apr 2015 15:22:20 -0700
From: "$Bill" <news@todbe.com>
Subject: Re: Regex replace line breaks
Message-Id: <mg9id9$818$1@dont-email.me>

On 4/10/2015 05:35, Shmuel (Seymour J.) Metz wrote:
> In <JfmVw.240687$Op6.213226@fx16.iad>, on 04/08/2015
>     at 10:21 PM, Martin Eastburn <lionslair@consolidated.net> said:
>
>> TTY's have been out of normal use for quite a while.  CR, CR, LF
>> allowed the carriage to return from a long line, index and start
>> printing.
>
> I've never seen CR used as an idle character, only NUL. I gueess it
> must be a unixism.

TTY's were pretty much gone before UNIX arrived - I used to repair
them and CR,CR,LF was quite common for Teletype Corp teletype machines
which were lever/spring machines - not so much for a Kleinschmidt
which was gears/shafts.  The extra CR made sure the print box had time
to make it back to the left margin.  Of course this was 5 bit Baudot
code, not ASCII/EBCDIC.




------------------------------

Date: Sat, 11 Apr 2015 01:55:17 +0000 (UTC)
From: Kaz Kylheku <kaz@kylheku.com>
Subject: Re: Regex replace line breaks
Message-Id: <20150410184231.603@kylheku.com>

On 2015-04-10, Shmuel Metz <spamtrap@library.lspace.org.invalid> wrote:
> In <JfmVw.240687$Op6.213226@fx16.iad>, on 04/08/2015
>    at 10:21 PM, Martin Eastburn <lionslair@consolidated.net> said:
>
>>TTY's have been out of normal use for quite a while.  CR, CR, LF
>>allowed the carriage to return from a long line, index and start
>>printing.
>
> I've never seen CR used as an idle character, only NUL. I gueess it
> must be a unixism.

CR makes sense in that situation because it's idempotent.

The Unix tty line discipline has accuulated numerous configurable delays for
this.  That is the Unix way. Check your termios man page, in particular
the OFILL output flag which allows fill characters to be sent instead of using
delays, and ODFL which can select between using a NUL and DEL.
Delays are supported for newlines, carriage returns, tabs, backspaces,
vertical tabs and form feeds.

On this note, I remember using terminal emulator programs on microcomputers
back in the 1980's that required end-of-line delays, due to the serial port
being polled by software with no interrupts or hardware FIFO buffering.  (On
some machines, serial I/O was even done at the individual bit level, with the
correct transmit baud rate depending on timed loops.) These machines would miss
characters when scrolling the screen.  BBSes tended to have configurable delays
for this.


------------------------------

Date: Fri, 10 Apr 2015 21:57:38 -0500
From: Martin Eastburn <lionslair@consolidated.net>
Subject: Re: Regex replace line breaks
Message-Id: <850Ww.310410$_F4.298711@fx21.iad>

It was developed before Unix.
It was used that way on weather stations sending data
on long serial lines - remember 20 and 60 ma current loops.
When you plugged in, the short in the socket switch opened
and your printer was inserted.  So weather in the grid or
region would all print on each under certain codes or a
call to a machine could turn it on and the send would bypass
others.
Early RTTY used TTY's as slow scan printers.  Bouncing off satellites
various pictures.  Always a contest for best seasonal graphic.
You wanted to make sure the carriage was in column 1 before printing
the next long line.  Even in normal text it can be nasty as the
print head might sit in the far right and just punch in holes until the
return command is sent.

We are really spoiled with graphic monitors we have and color as well 
and 1080 pixels wide or more.  I have two monitors - Vertical and 
Horizontal.

Running paper tape and hearing the clack clack of the print head - a Can 
shaped print head.  IBM invented the ebi based Floating Ball.

A college prof of mine had an IBM industrial - parallel port for his
DEC PDP-8 and he drove it so hard it snapped the steel post that was
moving it.  IBM gave him a new printer for the scientific findings that
were put into the metal fatigue.

Martin

On 4/10/2015 7:35 AM, Shmuel (Seymour J.) Metz wrote:
> In <JfmVw.240687$Op6.213226@fx16.iad>, on 04/08/2015
>     at 10:21 PM, Martin Eastburn <lionslair@consolidated.net> said:
>
>> TTY's have been out of normal use for quite a while.  CR, CR, LF
>> allowed the carriage to return from a long line, index and start
>> printing.
>
> I've never seen CR used as an idle character, only NUL. I gueess it
> must be a unixism.
>


------------------------------

Date: Sat, 11 Apr 2015 03:12:07 -0700
From: Robbie Hatley <see.my.sig@for.my.address>
Subject: Re: Regex replace line breaks
Message-Id: <E_6dnZwKTYbwbrXInZ2dnUVZ572dnZ2d@giganews.com>


On 4/8/2015 12:49 AM, Eric Pozharski wrote:

 > Robbie Hatley wrote:
 > > On 4/7/2015 1:20 AM, gamo wrote:
 > > > El 07/04/15 a las 09:25, Robbie Hatley escribió:
 >
 > *SKIP*
 > > Such as, EBCDIC. I'm sure there are still a few computers around
 > > running that encoding and other encodings that don't mirror ASCII.


You erased the "case" in question. The erased text would have
answered your question for you. Here's what I *actually* wrote:


======== BEGIN QUOTE ============

On 4/7/2015 1:20 AM, gamo wrote:

 > El 07/04/15 a las 09:25, Robbie Hatley escribió:
 > > ... Firstly, I doubt that the assumptions \r == \x0d and \n == \x0a
 > > are globally true....
 >
 > As far as you must find a non-ASCII compatible computer, or a perl
 > builded outside standard C, you could doubt.

Such as, EBCDIC. I'm sure there are still a few computers around running
that encoding and other encodings that don't mirror ASCII.

======= END QUOTE ============


In short, the answer to your question is:
"incompatible character encoding".


> May I remind you, and your herd, that clpm has no karma thingy?

Yes, you may.

However, I haven't a clue as to what you just said.

I have a "herd"? News to me.

CLPM sounds like a terminal illness, along the lines of COPD.
"Cardio-Lymphatic PneuMonia", perhaps? I can't decide if its lack
of "karma thingy" is a good thing or a bad thing.

Wait, you mean "comp.lang.perl.misc"? I'd suggest "this group"
or "here" as better shorthands. Acronyms are over-used and
over-rated, methinks.

> Personally, I like George's approach most.

You mean this?

s/\v+/\n/g

That does have the flaw that it's OS dependent, assuming that \n
is \x0d (as the OP specified), which is actually true on very *few* OSs
(NOT Unix, NOT Linux, NOT Cygwin, NOT Dos, NOT Windows; though it was
used on some older OSs, including Commodore 8-bit machines, Acorn BBC,
ZX Spectrum, TRS-80, Apple II, and Macintosh up to OS-9).

If one is dealing with text from different sources, with different
combos of \0a and \0d as linebreaks, and wants to convert them all
to \x0d (for whatever reason), it needs to be done directly:

s/[\x0a\x0d]+/\x0d/g;

> *CUT*

Ouch. I suggest you douse that with H2O2 and put a bandaid on it.


-- 
Cheers,
Robbie Hatley
Midway City, CA, USA
perl -le 'print "\154o\156e\167o\154f\100w\145ll\56c\157m"'
http://www.well.com/user/lonewolf/
https://www.facebook.com/robbie.hatley


------------------------------

Date: Sat, 11 Apr 2015 12:36:23 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Regex replace line breaks
Message-Id: <slrnmihu97.m1i.hjp-usenet3@hrunkner.hjp.at>

On 2015-04-08 23:08, Shmuel Metz <spamtrap@library.lspace.org.invalid> wrote:
> In <mg0416$19e$1@speranza.aioe.org>, on 04/07/2015
>    at 10:20 AM, gamo <gamo@telecable.es> said:
>>As far as you must find a non-ASCII compatible computer,
>
> Or a computer whose software can handle ASCII but normally uses a
> different character set, e.g., EBCDIC. Of course, the use of EBCDIC
> would imply an older Perl, e.g., 5.8.7.

Or a future perl. Apparently, EBCDIC support is being fixed in the
current development cycle and will probably be included in the next
stable release again.

        hp


-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp@hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel


------------------------------

Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin) 
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>


Administrivia:

To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.

Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests. 

#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.


------------------------------
End of Perl-Users Digest V11 Issue 4412
***************************************


home help back first fref pref prev next nref lref last post