[33117] in Perl-Users-Digest
Perl-Users Digest, Issue: 4393 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Mar 19 14:09:20 2015
Date: Thu, 19 Mar 2015 11:09:06 -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 Thu, 19 Mar 2015 Volume: 11 Number: 4393
Today's topics:
Re: An error on page 142 of The Camel Book. <see.my.sig@for.my.address>
Re: An error on page 142 of The Camel Book. <bauhaus@futureapps.invalid>
Re: An error on page 142 of The Camel Book. <bauhaus@futureapps.invalid>
Re: An error on page 142 of The Camel Book. <mvdwege@gmail.com>
Re: An error on page 142 of The Camel Book. <rweikusat@mobileactivedefense.com>
Re: An error on page 142 of The Camel Book. <jurgenex@hotmail.com>
Re: An error on page 142 of The Camel Book. (Seymour J.)
Re: An error on page 142 of The Camel Book. (Seymour J.)
Re: An error on page 142 of The Camel Book. (Seymour J.)
Re: An error on page 142 of The Camel Book. (Seymour J.)
Re: An error on page 142 of The Camel Book. <jurgenex@hotmail.com>
Re: An error on page 142 of The Camel Book. <jurgenex@hotmail.com>
Re: An error on page 142 of The Camel Book. <rweikusat@mobileactivedefense.com>
Re: An error on page 142 of The Camel Book. <rweikusat@mobileactivedefense.com>
Re: This RE isn't working as expected. (Seymour J.)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 18 Mar 2015 23:38:17 -0700
From: Robbie Hatley <see.my.sig@for.my.address>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <lsednTTX4KFL85fInZ2dnUVZ572dnZ2d@giganews.com>
On 3/18/2015 5:54 PM, Kaz Kylheku wrote:
> ... Nevertheless, there is some counting stupidity there which
> contributes to the probability of a bug.
It's an error, yes. But even unstupid people can make errors.
> You would think that $#ARGV means "number of arguments", right?
No. The first time I saw it (yesterday) I thought, "What the heck
is *that*?" I didn't have a clue *what* it meant. On looking it up
in The Camel Book, I discovered that $#array means "the last index
of @array". That's what led me to find the error on page 142 while
searching for "$#".
> But in fact, the number of arguments (not including the
> script name) is not $#ARGV, but $#ARGV+1, and $#ARGV+2 if
> the script name is included.
No. The script name is not part of @ARGV at all in Perl.
Instead, the script name is in $0. scalar(@ARGV) is thus always
"the number of arguments *to* the program, *not* including
the name of the program".
So, given the following program:
#! /usr/bin/perl
# ~/scripts/test/arg-count.perl
print scalar(@ARGV);
If you invoke it like this:
arg-count.perl 'echo' 'bravo' 'Quebec'
It will print 3, not 4.
> This program
>
> #!/usr/bin/perl
> print $#ARGV, "\n";
> print $0, "\n";
>
> confirms that, when it is run with no arguments, $#ARGV is -1,
> which is fucking retarded right off the bat.
Actually, that's quite useful, because you can erase any array
and return all of its values to the "undefined" state like so:
#! /usr/bin/perl
# /rhe/scripts/test/foreshorten-test-2.perl
use strict;
use warnings;
use feature qw(say);
our @array = (1..100); # @array contains integers 1 through 100
say join ' ', @array; # prints 1 through 100
say '';
$#array = 12; # @array now contains integers 1 through 13 (indices 0..12)
say join ' ', @array; # prints 1 through 13
say '';
$#array = -1; # @array is now empty, with no valid indices or contents.
say join ' ', @array; # prints blank line
> If one argument is supplied, this is zero, and so on.
Yes. That's called "zero indexing". It may seem "fucking retarded",
as you phrase it, to someone with no assembly or C experience; but
once you realize that in machine language, assembly language, and C,
indices are "offsets from starting location", then you'll realize
that the index of the starting (first) location is 0, second
location is 1, third location is 2, etc. That's just the difference
between the layman's way of ordinalizing and the computer scientist's
way of ordinalizing.
"Why use offsets at all?", you may ask. And the answer is, that in
lower-level languages, arrays and pointers are intimately related.
For a (possibly mind-blowing) example of this, consider the following
C program, compile it, run it, note what it does, and figure out for
yourself how/why it works:
#include <stdio.h>
int main(void)
{
int i;
int Array [2][3][5] =
{
{
{ 0, 1, 2, 3, 4},
{ 5, 6, 7, 8, 9},
{10,11,12,13,14}
},
{
{15,16,17,18,19},
{20,21,22,23,24},
{25,26,27,28,29}
}
};
int * Patris = & Array[0][0][0];
for (i = 0; i< 30; ++i)
{
printf("%d, ", (*Patris));
++Patris;
}
return 0;
}
How do you tell if a person is a computer scientist? Have him or her
lie down and try to fall asleep by counting sheep. Iff the person is
a computer scientist, the person will count:
"Zero, one, two, three..."
:-)
> In the shell language, $# counts the arguments starting with $1, not including
> $0. This is sane and reasonable enough.
>
> In C main, argc counts the arguments including the program name argv[0].
> Reasonable.
>
> $#ARGV being one less than then number of arguments is not reasonable.
It has nothing to do with @ARGV per-se.
$#array applies to *all* arrays.
For all arrays the following is true:
$#array == scalar(@array) - 1
> So, overall point: don't blame this bug entirely on the damn for loop.
> Part of the blame goes to the (C coding) numbnut who came up wit this
> ARGV in Perl.
$#array was never intended to be "element count", but rather "last index".
Use scalar(@array) for element count. (Or, just mention @array in a scalar
context.)
And, Perl was originally written in C, and I believe most implementations
of it are written in C, so yes, its creators and maintainers are
C coders. And that's likely to be true for decades to come, because
C is the natural language for writing higher-level compiled/interpreted
languages in, because it's "close to the machine".
And, while I'm not quite sure how Larry Wall will react to being called
a "numbnut", I should perhaps warn you that some programmers may take
offense to being addressed in such a tone.
As for the error on page 142 of The Camel Book (which is the topic of
this thread), I'm guessing it's due to the author's habit of writing
"i < argc" in C, then (mistakenly) carrying that over to "$i < $#ARGV"
in Perl. (Should have been "$i <= $#ARGV" or (better) "$i < @ARGV".)
--
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: Thu, 19 Mar 2015 11:10:36 +0100
From: "G.B." <bauhaus@futureapps.invalid>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <mee79c$fh9$1@dont-email.me>
On 19.03.15 04:36, Robbie Hatley wrote:
> Well, yes. But I don't see how that's relevant to anything. The topic
> here is
> Perl, and more specifically, the difference between scalar(@ARGV) and
> $#ARGV.
> And the difference is 1. :-) Always the following expression is true:
> scalar(@ARGV) == $#ARGV + 1
This equality doesn't hold:
perl -e '$[ = 42; printf "#: %d, eq? %d\n", $#ARGV, @ARGV == $#ARGV+1'
Just deprecated. However, ARGV is the name of
much that a Unix programmer will need to know,
unfortunately, about both C and Perl.
Is there one thing other than hysteric raisins that could
explain C's use of the name "argc" to denote what §5.1.2.2.1(2)
is describing in its definition? That name should be "_" IMHO
or similar, so as to convey the many references it drags in.
------------------------------
Date: Thu, 19 Mar 2015 11:20:04 +0100
From: "G.B." <bauhaus@futureapps.invalid>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <mee7r3$hg0$1@dont-email.me>
On 19.03.15 07:38, Robbie Hatley wrote:
> but
> once you realize that in machine language, assembly language, and C,
> indices are "offsets from starting location", then you'll realize
> that the index of the starting (first) location is 0, second
> location is 1, third location is 2, etc. That's just the difference
> between the layman's way of ordinalizing and the computer scientist's
> way of ordinalizing.
Except that this is a strange way of looking at "offset"
as a name naming according to what the word means:
at 0, there is no offset at all, hence a "layman" will
ask what (existing thing) on earth you are taking about.
As usual, the answer is along "vacuous truth": an offset
of 0 is a linguistic oddity that still is convenient and
useful to include among offsets.
Consider instructions, inspired by assembly language,
addressing a "layman":
"John, move that barrel away from the wall, by zero inches!"
Does this make sense in the head of the person so instructed?
------------------------------
Date: Thu, 19 Mar 2015 15:56:35 +0100
From: Mart van de Wege <mvdwege@gmail.com>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <867fudujbw.fsf@gaheris.avalon.lan>
Robbie Hatley <see.my.sig@for.my.address> writes:
> On 3/18/2015 3:57 AM, Henry Law wrote:
>
>> ... But using a loop variable is sometimes essential when, for example,
>> you want to be able to issue error messages like "Item $i is borked"...
>
>
> Yes, and also, when you don't want to do "for each", but rather
> "for some but not all". For example, I have one program which needs to use
> C-style for loops because it needs to process just part of an array.
> One of its loops looks roughly like this:
>
> for ( my $i = $start ; $i < $stop ; ++$i ) {
> ... # process $array[$i]
> }
Isn't that what we have array slices for?
for my $element (@array[$lower_bound..$upper_bound) {
# process $element;
}
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
------------------------------
Date: Thu, 19 Mar 2015 15:15:34 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <877fudj9wp.fsf@doppelsaurus.mobileactivedefense.com>
Robbie Hatley <see.my.sig@for.my.address> writes:
> On 3/18/2015 3:35 PM, Kaz Kylheku wrote:
[...]
> Always the following expression is true: scalar(@ARGV) == $#ARGV + 1
The operands of == are evaluated in scalar context, hence, this is the
same as
@ARGV == $#ARGV + 1
------------------------------
Date: Thu, 19 Mar 2015 08:26:31 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <6hplgadm9munke0c37nmi738akar14uel3@4ax.com>
Kaz Kylheku <kaz@kylheku.com> wrote:
>You would think that $#ARGV means "number of arguments", right?
No, I wouldn't. Not at all! It is the highest index in the ARGV array.
If you want the number of arguments then just use @ARGV in scalar
context, exactly the same as you do for any other array in Perl.
>But in fact, the number of arguments (not including the
>script name) is not $#ARGV, but $#ARGV+1, and $#ARGV+2 if
Not really, either. This relation only appears to be true because by
chance nobody has changed $[.
>$#ARGV being one less than then number of arguments is not reasonable.
Considering that $#ARGV does not indicate the number of arguments in the
first place (why aren't you using "scalar @ARGV" as with any other
array?) this statement is about as reasonable as ranting about the QE 2
not landing at JFK. It is not meant to do that.
jue
------------------------------
Date: Thu, 19 Mar 2015 11:02:48 -0400
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <550ae518$6$fuzhry+tra$mr2ice@news.patriot.net>
In <20150318174055.104@kylheku.com>, on 03/19/2015
at 12:54 AM, Kaz Kylheku <kaz@kylheku.com> said:
>You would think that $#ARGV means "number of arguments", right?
Wrong. In a language with no sigils I would think that it is a
variable named $#ARGV; in a language with sigils I would RTFM[1] and
not guess.
>confirms that, when it is run with no arguments, $#ARGV is -1, which
>is fucking retarded right off the bat.
No, in a language with only 0-based[2] indexing, any value *other
than* -1 would be retarded.
>In the shell language, $# counts the arguments starting with $1,
>not including $0. This is sane and reasonable enough.
Make up your mind; it's the same as what Perl does.
>So, overall point: don't blame this bug entirely on the damn for
>loop. Part of the blame goes to the (C coding) numbnut who came up
>wit this ARGV in Perl.
The behavior of $#ARGV is the only reasonable choice once you use
0-based indexing, and Larry Wall was not responsible for that, given
his design goals for Perl. Blame Ritchie and company, or maybe the
designers of BCPL.
[1] Even when TFM is poorly indexed.
[2] Do I like 0-based indexing? No, but that's what Perl uses;
deal with it.
--
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: Thu, 19 Mar 2015 10:52:12 -0400
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <550ae29d$5$fuzhry+tra$mr2ice@news.patriot.net>
In <lsednTTX4KFL85fInZ2dnUVZ572dnZ2d@giganews.com>, on 03/18/2015
at 11:38 PM, Robbie Hatley <see.my.sig@for.my.address> said:
>Yes. That's called "zero indexing". It may seem "fucking retarded",
>as you phrase it, to someone with no assembly or C experience; but
>once you realize that in machine language, assembly language, and C,
>indices are "offsets from starting location",
I've got half a century of assembler experience, and I have to
challenge that. It's certainly rue of assemblers with no macro
facilities, but once you have compile[1]-time variables all bets are
off. In
GBLA &FOO(10)
&FOO is an array indexed from 1 to 10. Naturally, the rules vary from
assembler to assembler.
[1[ Yes, an assembler *is* a compiler.
--
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: Thu, 19 Mar 2015 10:41:17 -0400
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <550ae00d$4$fuzhry+tra$mr2ice@news.patriot.net>
In <O9GdnUfU-et2tJfInZ2dnUVZ572dnZ2d@giganews.com>, on 03/18/2015
at 06:44 PM, Robbie Hatley <see.my.sig@for.my.address> said:
>Yes, and also, when you don't want to do "for each", but rather
>"for some but not all".
The example you gave can be written equally easily as a foreach with a
range; IMHO that would be clearer.
--
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: Thu, 19 Mar 2015 10:37:13 -0400
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <550adf19$3$fuzhry+tra$mr2ice@news.patriot.net>
In <XbidnV9vx-m-x5TInZ2dnUVZ8kGdnZ2d@giganews.com>, on 03/18/2015
at 10:57 AM, Henry Law <news@lawshouse.org> said:
>But using a loop variable is sometimes essential when,
>for example, you want to be able to issue error messages like
>"Item $i is borked".
That still doesn't require C syntax.
for (0 .. $#ARGV) {
carp "Item $_ is borked" if $foo($_) > 99;
more code;
};
--
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: Thu, 19 Mar 2015 08:44:34 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <dgrlgatndju075cjb59pi7ejc711qegutv@4ax.com>
Robbie Hatley <see.my.sig@for.my.address> wrote:
>Always the following expression is true:
>scalar(@ARGV) == $#ARGV + 1
No, it is not. The correct equivalence is
scalar(@ARGV) == $[ + $#ARGV + 1
It just happens that almost always $[ is zero. And almost always is
_not_ good enough when it comes to computers and programming.
jue
------------------------------
Date: Thu, 19 Mar 2015 08:54:23 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <eurlga5ifb8bps7rt4skj1riact1j4jvjo@4ax.com>
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
>In <XbidnV9vx-m-x5TInZ2dnUVZ8kGdnZ2d@giganews.com>, on 03/18/2015
> at 10:57 AM, Henry Law <news@lawshouse.org> said:
>
>>But using a loop variable is sometimes essential when,
>>for example, you want to be able to issue error messages like
>>"Item $i is borked".
>
>That still doesn't require C syntax.
>
>for (0 .. $#ARGV) {
Exactly!
If you want to
- iterate over the elements of the array, then use foreach (@myArray)
- iterate over the indices, then use foreach ($[..$#myArray)
- iterate over a subset, then use an array slice
There is virtually never a need to use C-style loops.
But on the other hand: there is always TIMTOWTDI.
If someone wants to use awkward code, then who is going to say no?
jue
------------------------------
Date: Thu, 19 Mar 2015 16:09:26 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <873851j7ex.fsf@doppelsaurus.mobileactivedefense.com>
"$Bill" <news@todbe.com> writes:
> On 3/18/2015 16:19, Rainer Weikusat wrote:
>>
>> IMHO, for (;;) counting loops are a bad idea in any language.
>
> I can't think of a single reason why.
I'll start with the anecdotical part: When I began using C seriously,
about 14 years ago, two constructs greatly puzzled me, namely, the
postincrement operator and the for(;;) loop, as I couldn't understand in
what circumstances they might ever be really needed. I've meanwhile
found (rare) sensible use for the postmods but none for for(;;).
Non-anecdotical:
for (<ex1>; <ex2>; <ex3>) <block>
is a messy construct because it groups three unrelated things into a
single line. It's equivalent to
<ex1>;
{
last unless <ex2>;
<block>:
<ex3>;
redo;
}
and the idea behind it is roughly: Loops usually modify variables which
have to be initialized before the loop start executing, hence, we
introduce a syntactical special-case 'last statement immediately in
front of the loop' and move that into the () as <ex1>. Further, loops
usually/ often execute while some condition is true. Hence, special case
number two 'controlling expression of the first statement in the loop
body' <=> <ex2>. Lastly, the loop variables obviously need to be
modified. Here, we decree that 'the loop body' needs the values
associated with the current iteration and not the modified ones and that
there's a final special case 'last statement of the loop body' aka
<ex3>. While this sounds nice and general, it's really only applicable
to counting loops of the kind other languages, eg, Pascal or BCPL,
support directly:
for i := 1 to 66 step 3
This can be expressed in C as
for (i = 1; i <= 66; i += 3)
but that's really a lower-level construct because instead of telling the
computer what is desired, it specifies how to accomplish it. And it
suggests a false sense of generality because certain 'common problems'
can only be shoe-horned into this syntax by using it in ways it wasn't
meant to be used, eg,
----------
my $list = [1, [2, [3]]];
sub free_list_while
{
my ($cur, $next);
$next = $_[0];
while ($cur = $next) {
$next = $cur->[1];
$cur->[1] = undef;
}
}
sub free_list_for
{
my ($cur, $next);
for ($next = $_[0]; $next; $cur->[1] = undef) {
$cur = $next;
$next = $cur->[1];
}
}
-----------
NB: That's a simplified version of some 'real' code of a particular
application. The reason for the 'cons cells' is that merging of lists is
needed which is faster this way (for the actual use case) then it would
be with arrays and the explicit freeing loop is needed because perl
frees such structures recursively and might otherwise crash because it
ran out of stack space.
Often, 'real loops' aren't that simple, eg they may use six or seven
variables, some of which 'start out' with the proper values (eg, because
they were passed as arguments) while others may need to be initialized
and yet others can just be used starting with the default
value. Extremely long lines become unreadable quickly, hence, cramming
six or seven initialiations into <ex1> is not a good idea. Such a
compound expression is also difficult to modify because text editors can
be used to shuffle lines of text around easily but not parts of lines.
Then, the test expression might need to be a 'do this while the
condition is true' or 'do this until the condition becomes true'. Both
can be expressed with keywords,
perl -e '$b = 0; until ($b == 11) { print("$b\n"); ++$b; }'
but for only supports the first case and the 2nd has to be emulated by
inverting the test expression. Also, loops with test at the end are
also often useful. Again, for (;;) can't express this and the workaround
is to use a redundant test with known outcome for the first
iteration. The counting loop itself is an example of that:
$l = 1;
{
last if $l < 5; # WTF? It was just set it to 1!
++$;
}
Lastly, it's the purpose of the code in the loop body to modify the
state of the universe and different parts of it may need to be modified
at different times and the restriction to 'after the iteration at the
end of the block' is too limiting in practice, see toy exampe above. Of
course, what I already wrote about 'unwieldy initialization expressions'
applies to step expression using several variables, too.
The only thing which can really be said in favour of for (;;) is "it's
the piece of swimming wreckage everybody clings to because it's good
enough to help us stay afloat and the shore's so distant". But "everbody
does this because it's a comfortable way to avoid thingking about the
actual problem" makes a poor argument.
Depending on the situation, a better argument is "all the everybodies
will go ballistic when encountering any other kind of loop", ie 'never
use anything but for (;;) loops in published Linux kernel code lest
you be reprimanded for your want of "good taste"' (Surely, french fries
with ketchup represent the pinnacle of dining culture. We never wanted
anything else).
------------------------------
Date: Thu, 19 Mar 2015 16:18:43 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: An error on page 142 of The Camel Book.
Message-Id: <87y4mthsf0.fsf@doppelsaurus.mobileactivedefense.com>
"G.B." <bauhaus@futureapps.invalid> writes:
> On 19.03.15 07:38, Robbie Hatley wrote:
>> but
>> once you realize that in machine language, assembly language, and C,
>> indices are "offsets from starting location", then you'll realize
>> that the index of the starting (first) location is 0, second
>> location is 1, third location is 2, etc. That's just the difference
>> between the layman's way of ordinalizing and the computer scientist's
>> way of ordinalizing.
>
> Except that this is a strange way of looking at "offset"
> as a name naming according to what the word means:
> at 0, there is no offset at all, hence a "layman" will
> ask what (existing thing) on earth you are taking about.
>
> As usual, the answer is along "vacuous truth": an offset
> of 0 is a linguistic oddity that still is convenient and
> useful to include among offsets.
At least for C, this becomes a lot clearer when using a more suitable
term: distance. Assuming a definition
int a[5];
a is an expression denoting the start of the storage allocated for the
array and individual elements reside at a certain distance from the
start, eg, in the case of
a[0]
immediately there.
This explanation doesn't really make technical sense in Perl but "don't
confuse C programmers if it can be avoided" make social sense.
------------------------------
Date: Thu, 19 Mar 2015 11:21:32 -0400
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: This RE isn't working as expected.
Message-Id: <550ae97c$7$fuzhry+tra$mr2ice@news.patriot.net>
In <G-2dneZKIp3iAZ_InZ2dnUVZ57ydnZ2d@giganews.com>, on 03/13/2015
at 01:14 AM, Robbie Hatley <see.my.sig@for.my.address> said:
>so I wrote program called "qp-to-ascii.perl"
None of them use BASE64?
>Yep, I probably should have looked in CPAN to see if there's a
>"email cleaner" module that strips out extraneous headers, HTML
>sections, and attachments, converts text from "quoted printable"
>to ASCII, then prints the "cleaned" email.
I hope not; to every complicated problem there is a solution that is
obviouas, simple and wrong. Use a tool like MIME::Parser that tries to
get it right.
>My own crude "let's hack that together in a hurry" version follows,
>for your amusement.
ITYM depair; it's ladden with assumptions.
--
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: 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 4393
***************************************
