[33129] in Perl-Users-Digest
Perl-Users Digest, Issue: 4406 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Apr 2 09:09:21 2015
Date: Thu, 2 Apr 2015 06: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, 2 Apr 2015 Volume: 11 Number: 4406
Today's topics:
An annoying error on page 783 of The Camel Book <see.my.sig@for.my.address>
Backticks status in scalar context: bug or missundersta <ams@luminous.ludd.ltu.se>
more Net:SSLeay (SSL_read) <rweikusat@mobileactivedefense.com>
Re: Net::SSLeay error messages <gamo@telecable.es>
Re: Net::SSLeay error messages <rweikusat@mobileactivedefense.com>
Re: One more reason I like Perl. <netnews@invalid.com>
Re: One more reason I like Perl. <kaz@kylheku.com>
Re: One more reason I like Perl. <rweikusat@mobileactivedefense.com>
Re: One more reason I like Perl. (Jens Thoms Toerring)
Re: One more reason I like Perl. <jblack@nospam.com>
Re: One more reason I like Perl. <rweikusat@mobileactivedefense.com>
Re: One more reason I like Perl. <kaz@kylheku.com>
Re: One more reason I like Perl. <kaz@kylheku.com>
Re: One more reason I like Perl. <rweikusat@mobileactivedefense.com>
Re: One more reason I like Perl. <rweikusat@mobileactivedefense.com>
Re: One more reason I like Perl. <see.my.sig@for.my.address>
Re: One more reason I like Perl. <see.my.sig@for.my.address>
Re: One more reason I like Perl. <see.my.sig@for.my.address>
Re: One more reason I like Perl. (Jens Thoms Toerring)
Re: One more reason I like Perl. <whynot@pozharski.name>
Re: One more reason I like Perl. <see.my.sig@for.my.address>
Re: One more reason I like Perl. <rweikusat@mobileactivedefense.com>
Re: running Perl scripts w/o extension on Windows 7 <Daniel.A.Mercer@wellsfargo.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 02 Apr 2015 03:44:06 -0700
From: Robbie Hatley <see.my.sig@for.my.address>
Subject: An annoying error on page 783 of The Camel Book
Message-Id: <pOidnQBK1NzpgIDInZ2dnUVZ572dnZ2d@giganews.com>
Programming Perl, 4th ed, PDF version, page 783 says that
$OUTPUT_FIELD_SEPARATOR is the same as $/ .
Wrong. It's actually $, rather than $/ .
That had me pulling my hair out for an hour, because a script
I just wrote was smashing all its output together:
#! /usr/bin/perl
# make-all-list.perl
use v5.14;
use strict;
use warnings;
our @names = `ls -1`;
our @tomake;
foreach (@names)
{
s/\x0a$//;
s/\x0d$//;
if (m/\.(c|cpp)$/)
{
s/\.(c|cpp)$/.exe/;
push(@tomake, $_);
}
}
$/ = ' ';
print(@tomake, "\n");
That's supposed to write a space-separated list of exe file names
corresponding to *.c and *.cpp files in the current directory,
assuming that each exe file has exactly one source file.
It gets run from inside a makefile like so:
ALL = $(shell make-all-list.perl)
all: $(ALL)
@echo Fractals Program Collection is up to date.
(followed by rules for making exe files from c and cpp files)
Expected output:
hennon.exe julia.exe mandel.exe mandelbrot.exe sierpinski.exe spirograph.exe
Actual output:
hennon.exejulia.exemandel.exemandelbrot.exesierpinski.exespirograph.exe
It turns out, the output field separator variable is actually
"$," rather than "$/"; the program worked fine when I changed that one
character.
This is already on O'Reilly's errata page, I see. But it's something
to keep in mind for anyone who wants to print uninterpolated arrays
and have spaces printed between elements.
Of course I *could* have done THIS:
print("@tomake", "\n");
which would insert spaces because $" defaults to ' '.
Or, I suppose I could have put the space in the s/// like so:
s/\.(c|cpp)$/.exe /;
Hmmm. Always multiple ways to do things in this language, it seems.
--
Curious,
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, 2 Apr 2015 11:25:34 +0000 (UTC)
From: Martin Str|mberg <ams@luminous.ludd.ltu.se>
Subject: Backticks status in scalar context: bug or missunderstanding
Message-Id: <mfj8vc$f51$1@speranza.aioe.org>
perldoc perlop says under Quote-Like Operators:
qx/STRING/
`STRING`
A string which is (possibly) interpolated and then executed as a
system command with "/bin/sh" or its equivalent. Shell wildcards,
pipes, and redirections will be honored. The collected standard
output of the command is returned; standard error is unaffected.
In scalar context, it comes back as a single (potentially multi-
line) string, or undef if the command failed. In list context,
returns a list of lines (however you've defined lines with $/ or
$INPUT_RECORD_SEPARATOR), or an empty list if the command failed.
Let me point out the part that is relevant:
In scalar context, it comes back as a single string, or undef if the command
failed.
Look at this program:
#!/usr/bin/perl -w
use strict;
use warnings;
my $cmd = "/bin/false";
my $o = `$cmd`;
if( defined( $o ) ) {
print "o defined.\n";
print "o = '$o'\n";
}
die "cmd '$cmd' failed.\n" unless defined( $o );
Evidently `$cmd` failed (/bin/false can't do anything else). But still the
program prints:
o defined.
o = ''
I've tried SLED 11.3 perl 5.10.0, Debian 6 perl 5.14.2 and self-compiled perl
5.20.2.
Something is wrong. Comments?
--
MartinS
------------------------------
Date: Wed, 01 Apr 2015 20:39:45 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: more Net:SSLeay (SSL_read)
Message-Id: <87sicjeiym.fsf@doppelsaurus.mobileactivedefense.com>
The 'SSL read routine' of Net::SSLeay (1.36) is
void
SSL_read(s,max=32768)
SSL * s
int max
PREINIT:
char *buf;
int got;
CODE:
New(0, buf, max, char);
ST(0) = sv_newmortal(); /* Undefined to start with */
if ((got = SSL_read(s, buf, max)) >= 0)
sv_setpvn( ST(0), buf, got);
Safefree(buf);
Reading into an internal buffer dynamically allocated and freed for
every call and copying that to a 2nd, dynamically allocated buffer for
passing the data out isn't a particularly good idea, not only because of
the 'double alloc double copy' but because this makes SSL_read
incompatible with both the read and sysread builtin functions.
The real falling millstone breaking the unfortunate journeyman's neck,
however, is that it returns a freshly allocated SV without a value while
eating the actual OpenSSL return value in case of an error. But the
caller is supposed to pass that to SSL_get_error in order to determine
the nature of the problem and whether the (OpenSSL) SSL_read should
simply be retried.
The current version (1.68) sort-of fixes this by returning got as 2nd
element of a list when called in list mode: It's still incompatible with
Perl but it now has an OpenSSL compatible, optional mode of operation
(actually fixing the problem is - of course - impossible as this would
break no end of code relying on the broken behaviour ...)
This workaround is - of course - undocumented. Surely no one would ever
contemplate using a CPAN module without studying any xs code employed by
it carefully first ...
------------------------------
Date: Wed, 01 Apr 2015 20:54:24 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Net::SSLeay error messages
Message-Id: <mfhet8$l34$1@speranza.aioe.org>
El 31/03/15 a las 23:51, Rainer Weikusat escribió:
> While this module documents that it would print SSL errors by default,
> it doesn't actually do so.
>
https://metacpan.org/pod/distribution/Net-SSLeay/lib/Net/SSLeay.pod#Error-handling-functions
--
http://www.telecable.es/personales/gamo/
The generation of random numbers is too important to be left to chance
------------------------------
Date: Wed, 01 Apr 2015 20:42:12 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Net::SSLeay error messages
Message-Id: <87oan7eiuj.fsf@doppelsaurus.mobileactivedefense.com>
gamo <gamo@telecable.es> writes:
> El 31/03/15 a las 23:51, Rainer Weikusat escribió:
>> While this module documents that it would print SSL errors by default,
>> it doesn't actually do so.
>>
>
> https://metacpan.org/pod/distribution/Net-SSLeay/lib/Net/SSLeay.pod#Error-handling-functions
These are the functions documented as printing errors by default (more
precisely, they're documented as printing errors and one can conjecture
that the trace level wrongly documented as defaulting to 'print errors'
should affect them).
------------------------------
Date: Wed, 01 Apr 2015 05:31:01 -0700
From: HASM <netnews@invalid.com>
Subject: Re: One more reason I like Perl.
Message-Id: <87y4mc6nei.fsf@127.0.0.1>
> I was just struggling to get a "substitute replacement string for
> pattern" program running in C++, and I finally got it running, but
> the size had bloated to 250 lines.
Without spending more than a couple of minutes on the on this, can't you
use PCRE in your C++ program and make it a bit more compact?
-- HASM
------------------------------
Date: Wed, 1 Apr 2015 14:33:03 +0000 (UTC)
From: Kaz Kylheku <kaz@kylheku.com>
Subject: Re: One more reason I like Perl.
Message-Id: <20150401072736.852@kylheku.com>
On 2015-04-01, HASM <netnews@invalid.com> wrote:
>
>> I was just struggling to get a "substitute replacement string for
>> pattern" program running in C++, and I finally got it running, but
>> the size had bloated to 250 lines.
>
> Without spending more than a couple of minutes on the on this, can't you
> use PCRE in your C++ program and make it a bit more compact?
Also, C++ is getting regexes!
There is a lot more in that horrendous code that could be a hell of a
lot more compact, not only the choice of regex.
Also, the Perl code offered in comparison doesn't do extraneous things like
parsing options and such. It has no error messages or help text. It doesn't
even check that enough arguments are supplied.
The structure of the equiavlent equiavlent C++ code could just be:
#include <iostream>
#include <some_regex_class.h>
using namespace std;
int main(int argc, char **argv)
{
if (argc < 3) {
cerr << "..." << endl;
return EXIT_FAILURE;
}
// construct a regex object from argv[2]
// loop to scan input for matches for regex, replacing with argv[1]
}
Basically the original program is a big, overstuffed strawman against C++.
------------------------------
Date: Wed, 01 Apr 2015 15:56:17 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: One more reason I like Perl.
Message-Id: <871tk3gani.fsf@doppelsaurus.mobileactivedefense.com>
Kaz Kylheku <kaz@kylheku.com> writes:
> On 2015-04-01, HASM <netnews@invalid.com> wrote:
>>
>>> I was just struggling to get a "substitute replacement string for
>>> pattern" program running in C++, and I finally got it running, but
>>> the size had bloated to 250 lines.
>>
>> Without spending more than a couple of minutes on the on this, can't you
>> use PCRE in your C++ program and make it a bit more compact?
>
> Also, C++ is getting regexes!
OMG. We still haven't really gotten past Ebola ...
[...]
> Basically the original program is a big, overstuffed strawman against
> C++.
At least, it's a demonstration that - for some people - using Perl to
solve a simple problem like this is a lot easier than using C++ if only
because this means they aren't getting lost in all kinds of stuff which
isn't really useful for the problem at hand.
------------------------------
Date: 1 Apr 2015 17:15:36 GMT
From: jt@toerring.de (Jens Thoms Toerring)
Subject: Re: One more reason I like Perl.
Message-Id: <co2ndmFogk7U1@mid.uni-berlin.de>
Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
> Kaz Kylheku <kaz@kylheku.com> writes:
> > Basically the original program is a big, overstuffed strawman against
> > C++.
> At least, it's a demonstration that - for some people - using Perl to
> solve a simple problem like this is a lot easier than using C++ if only
> because this means they aren't getting lost in all kinds of stuff which
> isn't really useful for the problem at hand.
Well, that depends a bit on how well that person knows the
languages - someone "fluent" in C++ but with hardly any
experience in Perl might easily come up with a horrible
kludge of a Perl script and compare that to a terse, well-
written C++ program and then claim that Perl sucks while
C++ is so much better...
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
------------------------------
Date: Wed, 1 Apr 2015 13:42:21 -0500
From: John Black <jblack@nospam.com>
Subject: Re: One more reason I like Perl.
Message-Id: <MPG.2f85f80cee46290898981d@news.eternal-september.org>
In article <YPednQL8bafY64bInZ2dnUVZ57ydnZ2d@giganews.com>, see.my.sig@for.my.address says...
> while (<STDIN>) {
> if (scalar(@ARGV) > 2) {eval "s/$ARGV[0]/$ARGV[1]/$ARGV[2]"}
> else {eval "s/$ARGV[0]/$ARGV[1]/" }
> print;
> }
>
> Short, sweet, and functional.
>
This is great, thanks! Why is eval needed? I seem to be able to remove it on the else line
but not on the line above?
John Black
------------------------------
Date: Wed, 01 Apr 2015 19:50:26 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: One more reason I like Perl.
Message-Id: <87wq1vel8t.fsf@doppelsaurus.mobileactivedefense.com>
John Black <jblack@nospam.com> writes:
> In article <YPednQL8bafY64bInZ2dnUVZ57ydnZ2d@giganews.com>, see.my.sig@for.my.address says...
>> while (<STDIN>) {
>> if (scalar(@ARGV) > 2) {eval "s/$ARGV[0]/$ARGV[1]/$ARGV[2]"}
>> else {eval "s/$ARGV[0]/$ARGV[1]/" }
>> print;
>> }
>>
>> Short, sweet, and functional.
>>
>
> This is great, thanks! Why is eval needed? I seem to be able to remove it on the else line
> but not on the line above?
The eval isn't needed on the 2nd line because $ARGV[0] is interpolated
into the (otherwise empty) regex and likewise, $ARGV[1] into the
(otherwise empty) substitution expression. It is need for the 1st line
because this doesn't work for s///-flags (supposed to come from
$ARGV[2].
------------------------------
Date: Wed, 1 Apr 2015 19:14:08 +0000 (UTC)
From: Kaz Kylheku <kaz@kylheku.com>
Subject: Re: One more reason I like Perl.
Message-Id: <20150401121326.983@kylheku.com>
On 2015-04-01, Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
> Kaz Kylheku <kaz@kylheku.com> writes:
>> On 2015-04-01, HASM <netnews@invalid.com> wrote:
>>>
>>>> I was just struggling to get a "substitute replacement string for
>>>> pattern" program running in C++, and I finally got it running, but
>>>> the size had bloated to 250 lines.
>>>
>>> Without spending more than a couple of minutes on the on this, can't you
>>> use PCRE in your C++ program and make it a bit more compact?
>>
>> Also, C++ is getting regexes!
>
> OMG. We still haven't really gotten past Ebola ...
>
> [...]
>
>> Basically the original program is a big, overstuffed strawman against
>> C++.
>
> At least, it's a demonstration that - for some people - using Perl to
> solve a simple problem like this is a lot easier than using C++ if only
> because this means they aren't getting lost in all kinds of stuff which
> isn't really useful for the problem at hand.
Which is totally valid because Perl programmers never get lost in any kind of
stuff that is not really useful for the problem at hand.
------------------------------
Date: Wed, 1 Apr 2015 19:18:30 +0000 (UTC)
From: Kaz Kylheku <kaz@kylheku.com>
Subject: Re: One more reason I like Perl.
Message-Id: <20150401121629.19@kylheku.com>
On 2015-04-01, John Black <jblack@nospam.com> wrote:
> In article <YPednQL8bafY64bInZ2dnUVZ57ydnZ2d@giganews.com>, see.my.sig@for.my.address says...
>> while (<STDIN>) {
>> if (scalar(@ARGV) > 2) {eval "s/$ARGV[0]/$ARGV[1]/$ARGV[2]"}
>> else {eval "s/$ARGV[0]/$ARGV[1]/" }
>> print;
>> }
>>
>> Short, sweet, and functional.
>>
>
> This is great, thanks! Why is eval needed?
It's a deliberate handicap. The C++ will likely have a security hole,
so it would be a totally unfair contest for the Perl not to have some
exploitable surface.
------------------------------
Date: Wed, 01 Apr 2015 22:21:32 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: One more reason I like Perl.
Message-Id: <87a8yree8z.fsf@doppelsaurus.mobileactivedefense.com>
Kaz Kylheku <kaz@kylheku.com> writes:
> On 2015-04-01, John Black <jblack@nospam.com> wrote:
>> In article <YPednQL8bafY64bInZ2dnUVZ57ydnZ2d@giganews.com>, see.my.sig@for.my.address says...
>>> while (<STDIN>) {
>>> if (scalar(@ARGV) > 2) {eval "s/$ARGV[0]/$ARGV[1]/$ARGV[2]"}
>>> else {eval "s/$ARGV[0]/$ARGV[1]/" }
>>> print;
>>> }
>>>
>>> Short, sweet, and functional.
>>>
>>
>> This is great, thanks! Why is eval needed?
>
> It's a deliberate handicap. The C++ will likely have a security hole,
> so it would be a totally unfair contest for the Perl not to have some
> exploitable surface.
The eval enables someone who can chose values for the first three
argument to execute any Perl code which can be interpolated into the
s/// such that the result compiles. Considering that the same someone
just ran perl with an abitrary argument (namely, the name of the
script), this doesn't seem much of 'an exploitable surface'.
------------------------------
Date: Wed, 01 Apr 2015 22:29:38 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: One more reason I like Perl.
Message-Id: <87619fedvh.fsf@doppelsaurus.mobileactivedefense.com>
Kaz Kylheku <kaz@kylheku.com> writes:
> On 2015-04-01, Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
>> Kaz Kylheku <kaz@kylheku.com> writes:
>>> On 2015-04-01, HASM <netnews@invalid.com> wrote:
>>>>
>>>>> I was just struggling to get a "substitute replacement string for
>>>>> pattern" program running in C++, and I finally got it running, but
>>>>> the size had bloated to 250 lines.
>>>>
>>>> Without spending more than a couple of minutes on the on this, can't you
>>>> use PCRE in your C++ program and make it a bit more compact?
>>>
>>> Also, C++ is getting regexes!
>>
>> OMG. We still haven't really gotten past Ebola ...
>>
>> [...]
>>
>>> Basically the original program is a big, overstuffed strawman against
>>> C++.
>>
>> At least, it's a demonstration that - for some people - using Perl to
>> solve a simple problem like this is a lot easier than using C++ if only
>> because this means they aren't getting lost in all kinds of stuff which
>> isn't really useful for the problem at hand.
>
> Which is totally valid because Perl programmers never get lost in any kind of
> stuff that is not really useful for the problem at hand.
Some people would argue that contemplating use of Perl equals 'being
lost in stuff which is not useful for the problem at hand' :->. OTOH,
the Perl motto is "make simple things simple and complicated ones
possible" while "enable making simple things complicated while pushing
complicated ones beyond the event horizon" aptly describes the purpose
of C++. Perl is less "in your face!" in this respect: Its more
complicated features will happily lay dormant until called for.
------------------------------
Date: Thu, 02 Apr 2015 00:35:28 -0700
From: Robbie Hatley <see.my.sig@for.my.address>
Subject: Re: One more reason I like Perl.
Message-Id: <AOmdnTUXrZqjbIHInZ2dnUVZ57ydnZ2d@giganews.com>
On 4/1/2015 5:31 AM, HASM wrote:
> > I was just struggling to get a "substitute replacement string for
> > pattern" program running in C++, and I finally got it running, but
> > the size had bloated to 250 lines.
>
> Without spending more than a couple of minutes on the on this, can't you
> use PCRE in your C++ program and make it a bit more compact?
Ah. I was unaware of the existence of said library; thanks for the
citation.
Though I suppose Boost probably has something like that also; I'd have
to look. (Just barely getting started in Boost.)
Also, the version of the std-C-lib that comes with Cygwin has a regex
module, but it's just raw pattern matching only, no s/// operator for
some reason that eludes me; you have to implement your own s///. Grrr.
But C++'s ability to work with files & directories and handle Unicode
file names is clunky, whereas Perl excels at those things. So a lot of
the old programs I wrote in C++ to do file & directory maintenance on
my own computers I'm now re-writing in Perl for 6 HUGE reasons:
1. The original *.exe files won't work on 64bit Windows.
2. Djgpp (my former programming platform) is obsolete.
3. Perl is better at handling files & directories.
4. Perl is better at handling Unicode.
5. 10x reduction in file size.
6. 100x reduction in programming time.
I'm not knocking C or C++; but different languages excel at
different things.
--
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, 02 Apr 2015 01:00:38 -0700
From: Robbie Hatley <see.my.sig@for.my.address>
Subject: Re: One more reason I like Perl.
Message-Id: <2OKdnZG3fMK5aoHInZ2dnUVZ57ydnZ2d@giganews.com>
On 4/1/2015 7:33 AM, Kaz Kylheku wrote:
> There is a lot more in that horrendous code that could be a hell of a
> lot more compact, not only the choice of regex.
That's because that I made that program by tailoring a "template" program.
The template I made some years ago because I found that I was writing
file & directory maintenance programs which ended up repeating a lot of
code. So I moved some to a library and put the rest in a file called
"template.cpp". New utility programs could then be made by just altering
a copy of the template.
The upside of that was, it drastically reduced time necessary to make new
utility programs.
The downside was, the source files typically contained unnecessary stuff
inherited from the template, unless I spent a lot of time "weeding".
> Also, the Perl code offered in comparison doesn't do extraneous things like
> parsing options and such. It has no error messages or help text. It doesn't
> even check that enough arguments are supplied.
A program which is 10 lines long hardly *needs* any elaborate error checking.
And as for run-time argument checking, the Perl interpreter will happily
tell you if the stuff you just typed results in an eval string which is
erroneous. Lets try my substitute.perl program with garbage arguments:
%substitute ']/]/]/]4j2S0;2~)(U' '\\@*%\?/?/\/grab' '$*&%^@'
rabbit
Segmentation fault (core dumped)
Yes, I think that "Segmentation fault (core dumped)" is a pretty clear
and immediate indicator that you typed something you shouldn't have. :-)
> The structure of the equiavlent equiavlent C++ code could just be:
> [code]
If written ab-ovo, yes.
> Basically the original program is a big, overstuffed strawman against C++.
Not my intent. (See above re "template".)
--
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, 02 Apr 2015 01:28:18 -0700
From: Robbie Hatley <see.my.sig@for.my.address>
Subject: Re: One more reason I like Perl.
Message-Id: <lK6dnVtrAvk9YIHInZ2dnUVZ572dnZ2d@giganews.com>
Correction: the error msg I just posted was from the C++ version of
my "Substitute" program; the Perl version is called "substitute.perl".
The actual error message is:
%substitute.perl ']/]/]/]4j2S0;2~)(U' '\\@*%\?/?/\/grab' '$*&%^@'
rabbit
Number found where operator expected at (eval 1) line 1, near "]4"
(Missing operator before 4?)
Bareword found where operator expected at (eval 1) line 1, near "4j2S0"
(Missing operator before j2S0?)
Use of ?PATTERN? without explicit operator is deprecated at (eval 1) line 1, <STDIN> line 1.
Array found where operator expected at (eval 1) line 1, at end of line
(Missing operator before ?)
So Perl is even more detailed than C++ at telling you exactly what's wrong
with what you type as command-line arguments, esp if those arguments are
going into eval's. That's another reason why Perl is great for this type
of thing: the interpreter plays "input nanny".
Whereas in a non-interpreted language, the executable is run directly by
the OS, so error messages are much more vague and don't specify what parts
of the input or source code caused the error. Especially since I set the
compiler to strip-out the symbol table; not even a debugger could give
detailed reasons for crashes, unless I make a debug version of the exe
and run it through a debugger.
--
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: 2 Apr 2015 09:30:10 GMT
From: jt@toerring.de (Jens Thoms Toerring)
Subject: Re: One more reason I like Perl.
Message-Id: <co4gh0F683pU2@mid.uni-berlin.de>
Robbie Hatley <see.my.sig@for.my.address> wrote:
> Correction: the error msg I just posted was from the C++ version of
> my "Substitute" program; the Perl version is called "substitute.perl".
> The actual error message is:
> %substitute.perl ']/]/]/]4j2S0;2~)(U' '\\@*%\?/?/\/grab' '$*&%^@'
> rabbit
> Number found where operator expected at (eval 1) line 1, near "]4"
> (Missing operator before 4?)
> Bareword found where operator expected at (eval 1) line 1, near "4j2S0"
> (Missing operator before j2S0?)
> Use of ?PATTERN? without explicit operator is deprecated at (eval 1) line 1, <STDIN> line 1.
> Array found where operator expected at (eval 1) line 1, at end of line
> (Missing operator before ?)
> So Perl is even more detailed than C++ at telling you exactly what's wrong
> with what you type as command-line arguments, esp if those arguments are
> going into eval's. That's another reason why Perl is great for this type
> of thing: the interpreter plays "input nanny".
I'd rather not be an unsuspecting user of one of your programs;-)
A program that segfaults has a serious defect that must be cor-
rected. It's no substitute for checking the validity of the
arguments since it just tells the user that the programmer has
made a mistake. And having a script spit out these messages from
the Perl interpreter is perhaps nice during development, but it's
not a "user interface".
So, what you've demonstrated, as far as I can see, is that it's
a bit easier to write small throw-away programs in Perl than in
C++. But nobody ever had any doubts about that, I guess...
Regards, Jensa
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
------------------------------
Date: Thu, 02 Apr 2015 08:57:37 +0300
From: Eric Pozharski <whynot@pozharski.name>
Subject: Re: One more reason I like Perl.
Message-Id: <slrnmhpmih.bp9.whynot@orphan.zombinet>
with <MPG.2f85f80cee46290898981d@news.eternal-september.org> John Black wrote:
> In article <YPednQL8bafY64bInZ2dnUVZ57ydnZ2d@giganews.com>,
> see.my.sig@for.my.address says...
>> while (<STDIN>) {
>> if (scalar(@ARGV) > 2) {eval "s/$ARGV[0]/$ARGV[1]/$ARGV[2]"}
>> else {eval "s/$ARGV[0]/$ARGV[1]/" }
>> print;
>> }
*SKIP*
> This is great, thanks! Why is eval needed? I seem to be able to
> remove it on the else line but not on the line above?
Because options aren't subject of interpolation. While they can be
made, using "Extended Patterns, except for C<cegor>. Probably (if there
would be any intention to produce something resembling sed(1)) C<ceg>
could be handled with CL options, and C<or> can be dropped.
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
------------------------------
Date: Thu, 02 Apr 2015 05:01:27 -0700
From: Robbie Hatley <see.my.sig@for.my.address>
Subject: Re: One more reason I like Perl.
Message-Id: <t-edncUYL9MIsoDInZ2dnUVZ57w3t52d@giganews.com>
On 4/1/2015 11:42 AM, John Black wrote:
> In article <YPednQL8bafY64bInZ2dnUVZ57ydnZ2d@giganews.com>,
> see.my.sig@for.my.address says...
> > while (<STDIN>) {
> > if (scalar(@ARGV) > 2) {eval "s/$ARGV[0]/$ARGV[1]/$ARGV[2]"}
> > else {eval "s/$ARGV[0]/$ARGV[1]/" }
> > print;
> > }
> >
> > Short, sweet, and functional.
> >
>
> This is great, thanks! Why is eval needed? I seem to be able to
> remove it on the else line but not on the line above?
That's because Perl "interpolates" the stuff between the s/// delimiters,
but *not* stuff after the final delimiter. So if I try the following:
#! /usr/bin/perl
# substitute.perl
use v5.14;
use strict;
use warnings;
while (<STDIN>) {
if (scalar(@ARGV) > 2) {s/$ARGV[0]/$ARGV[1]/$ARGV[2]}
else {s/$ARGV[0]/$ARGV[1]/ }
print;
}
That won't work because $ARGV[2] isn't interpolated, so it's a compile-time
syntax error:
%substitute.perl 'rab' 'grab' 'g'
Scalar found where operator expected at /rhe/scripts/util/substitute.perl line 7,
near "s/$ARGV[0]/$ARGV[1]/$ARGV"
syntax error at /rhe/scripts/util/substitute.perl line 7, near
"s/$ARGV[0]/$ARGV[1]/$ARGV"
Execution of /rhe/scripts/util/substitute.perl aborted due to compilation errors
So eval has to be used on the "if" line, because it forces interpolation.
The "else" line doesn't actually need eval, but I put it in there for symmetry.
--
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, 02 Apr 2015 13:26:12 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: One more reason I like Perl.
Message-Id: <87h9syhg2j.fsf@doppelsaurus.mobileactivedefense.com>
jt@toerring.de (Jens Thoms Toerring) writes:
[...]
> I'd rather not be an unsuspecting user of one of your programs;-)
> A program that segfaults has a serious defect that must be cor-
> rected.
A program which segfaulted made an invalid memory access. There are a
variety of possible causes for that, programm error, hardware problem or
invalid input (precondition not satisfied). For the latter case, a
sensible user interface should check whether arguments from outside the
program make any sense[*] prior to trying to use them and should print
intelligible error messages enabling correction of the problem but
technically, this remains an operator error.
[*] ... because the 'heartbleed' publicity stunt could have been avoided
in this way :->
------------------------------
Date: Thu, 02 Apr 2015 02:46:00 -0500
From: damercer2850 <Daniel.A.Mercer@wellsfargo.com>
Subject: Re: running Perl scripts w/o extension on Windows 7
Message-Id: <5OqdnaHEG5MlboHInZ2dnUU7-VGdnZ2d@giganews.com>
Without an extension, no. Your file must have an extension. Microsoft uses the extension to associate the file with another program. The trick is to set up
The PATH and PATHEXT variables to recognize your file and then associate that extension with the perl executable. You change variables in Start=>Control Panel=>System=>Advanced System Settings. This brings up the System Properties dialog. You can also right click on Computer in File Explorer and select Properties.
In the System Properties dialog select the Advanced tab and click on the Environment Variables button. The Pat and PATHEXT variable elements are semi-colon delimited.
To associate a file type click on Start=>Default Programs=>Associate a file type or protocol with a program.
Click on your extension then hit the Change Program button. You can Browse to get to your Perl executable.
I have ActiveStae's ActivePerl and have two extensions - .pl for command line programs (mostly replacements for standard Unix utilities) and .plx which invokes wperl.exe for windowing programs (it runs without a console window).
Once you have down the above you can run your perl programs without explicitly calling perl.exe and without using the file extension.
For instance, on my pc calling find will actually invoke c:\Perl\bin\perl.exe c:\bin\find.pl.
Dan Mercer
damercer@comcast.net
--
------------------------------
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 4406
***************************************
