[31793] in Perl-Users-Digest
Perl-Users Digest, Issue: 3056 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Aug 1 14:09:21 2010
Date: Sun, 1 Aug 2010 11: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 Sun, 1 Aug 2010 Volume: 11 Number: 3056
Today's topics:
Re: Can this be done (by a noob :)) <tadmc@seesig.invalid>
Re: Can this be done (by a noob :)) <sherm.pendley@gmail.com>
Re: CGI Program Questions <edgrsprj@ix.netcom.com>
Re: CGI Program Questions (Randal L. Schwartz)
Re: CGI Program Questions <edgrsprj@ix.netcom.com>
Re: FAQ 8.44 How do I tell the difference between error <hjp-usenet2@hjp.at>
Re: If Perl is compiled on a 32-bit system, and the sys <nospam-abuse@ilyaz.org>
Re: If Perl is compiled on a 32-bit system, and the sys <ben@morrow.me.uk>
Re: If Perl is compiled on a 32-bit system, and the sys <hjp-usenet2@hjp.at>
Re: piped open and shell metacharacters <xhoster@gmail.com>
Re: piped open and shell metacharacters <derykus@gmail.com>
Re: piped open and shell metacharacters <jak@isp2dial.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 31 Jul 2010 18:43:33 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Can this be done (by a noob :))
Message-Id: <slrni59d4u.oti.tadmc@tadbox.sbcglobal.net>
Ben Morrow <ben@morrow.me.uk> wrote:
>
> Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
>> On 2010-07-31 16:42, Jürgen Exner <jurgenex@hotmail.com> wrote:
>> > "Thomas Andersson" <thomas@tifozi.net> wrote:
>> >>The loop has been rewritten and workds as intended now, using last to exit
>> >>on the two possible conditions. Now look like this:
>> >>
>> >>while (1) {
>> >
>> > Ouch, this hurts! Usually this line indicates a deamon which is never
>> > supposed to terminate.
>>
>> Maybe. Personally I never use while (1), I prefer for (;;) instead.
>> But neither implies that the loop is really infinite: It may (and often
>> is) be left with last or return.
>
> Actually it will *always* be left in some way, if only due to the heat
> death of the Universe... :)
LOL!
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Sat, 31 Jul 2010 20:26:48 -0400
From: Sherm Pendley <sherm.pendley@gmail.com>
Subject: Re: Can this be done (by a noob :))
Message-Id: <m24offxjnb.fsf@sherm.shermpendley.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Actually it will *always* be left in some way, if only due to the heat
> death of the Universe... :)
Isn't there a prize for solving the halting problem? :-)
sherm--
--
Sherm Pendley <www.shermpendley.com>
<www.camelbones.org>
Cocoa Developer
------------------------------
Date: Sat, 31 Jul 2010 21:57:36 -0500
From: "E.D.G." <edgrsprj@ix.netcom.com>
Subject: Re: CGI Program Questions
Message-Id: <dqudnb7GMuQFf8nRnZ2dnUVZ_hadnZ2d@earthlink.com>
"E.D.G." <edgrsprj@ix.netcom.com> wrote in message
news:4IOdnbhlW5_kXavRnZ2dnUVZ_iydnZ2d@earthlink.com...
> Question 2 - Can anyone recommend a freeware, modifiable Perl language
> CGI program that will accept an E-mail sent to a Web site address, extract
> picture files etc. from the E-mail, and then store the files in some
> directory at the Web site?
The first part of this effort was a success thanks to a helpful
professional PHP language programmer. This is a discussion of the outcome
for any parties interested in this type of programming effort.
An E-mail forwarding program available through the Web server where I
have a domain was installed in my own Web domain area and instructed to
"pipe" any E-mail letters sent to my domain E-mail addresses to a special
PHP program that was created for processing the letters.
Several already available E-mail processing PHP modules were
installed in my Web domain area. And when an E-mail is piped to the
original PHP program it starts running and instructs those PHP modules to
decode the E-mail. It then uses the extracted sections to store any files
attached to the E-mail in directories at my Web domain specified in the
original PHP program. Security features were added to the original program
to keep spam E-mail from causing problems.
If all goes according to plan, those PHP based routines will
eventually be converted to Perl language programs so that they can be merged
with Perl language Internet Bulletin Board programs. Versions of the
original program will also run as standalone programs.
It is my assumption that the necessary Perl language E-mail
processing modules already exist. And a search will probably be made for
them at some future date.
Although the basic idea here was fairly simple, the data processing
routines were moderately complicated. It took the PHP programmer and myself
a while to get everything to work properly.
------------------------------
Date: Sat, 31 Jul 2010 20:09:45 -0700
From: merlyn@stonehenge.com (Randal L. Schwartz)
To: "E.D.G." <edgrsprj@ix.netcom.com>
Subject: Re: CGI Program Questions
Message-Id: <867hkbt4ee.fsf@red.stonehenge.com>
>>>>> "E" == E D G <edgrsprj@ix.netcom.com> writes:
>> Question 2 - Can anyone recommend a freeware, modifiable Perl language CGI
>> program that will accept an E-mail sent to a Web site address, extract
>> picture files etc. from the E-mail, and then store the files in some
>> directory at the Web site?
It's not CGI if it isn't being invoked from a web page hit. You're
talking about a mail handler. Get your terminology correct first,
before asking for further help.
Oh, and email doesn't go to "a web site address", in spite of pop
culture insisting that you "email us at www.example.com". Keep in mind
these are the the same idiots who say "visit our site at example dot com
backslash feedback". Right, because backslash *is* the separator there.
Not.
print "Just another Perl hacker,"; # the original
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
------------------------------
Date: Sat, 31 Jul 2010 23:15:05 -0500
From: "E.D.G." <edgrsprj@ix.netcom.com>
Subject: Re: CGI Program Questions
Message-Id: <Na6dnaYQz7xcacnRnZ2dnUVZ_s-dnZ2d@earthlink.com>
"Randal L. Schwartz" <merlyn@stonehenge.com> wrote in message
news:867hkbt4ee.fsf@red.stonehenge.com...
> It's not CGI if it isn't being invoked from a web page hit. You're
> talking about a mail handler.
A goal here is to eventually have a single Internet Bulletin Board program
that will:
--- Accept and process data submitted to it through Web page input screens.
--- Accept and process data submitted to it via E-mail letters. As you
said, a mail handler is involved.
--- Accept and process data submitted to it by other programs running at my
domain Web site that will run one or more times a day and collect scientific
data from other Web sites.
The effort to get such a bulletin board running at my domain Web site is
gradually moving along a step at a time.
------------------------------
Date: Sun, 1 Aug 2010 01:46:36 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: FAQ 8.44 How do I tell the difference between errors from the shell and perl?
Message-Id: <slrni59df1.v04.hjp-usenet2@hrunkner.hjp.at>
On 2010-07-31 22:00, PerlFAQ Server <brian@theperlreview.com> wrote:
> --------------------------------------------------------------------
>
> 8.44: How do I tell the difference between errors from the shell and perl?
>
> (answer contributed by brian d foy)
>
> When you run a Perl script, something else is running the script for
> you, and that something else may output error messages. The script might
> emit its own warnings and error messages. Most of the time you cannot
> tell who said what.
I find this paragraph confusing. The "something else" that "is running
the script for" me is the perl interpreter. But from the rest of this
entry I guess that "something else" means the shell, which doesn't run
the script, it merely starts it. Or at least it shouldn't run the
script. If it tries to, you get the error message below.
> You probably cannot fix the thing that runs perl, but you can change how
> perl outputs its warnings by defining a custom warning and die
> functions.
>
> Consider this script, which has an error you may not notice immediately.
>
> #!/usr/locl/bin/perl
>
> print "Hello World\n";
>
> I get an error when I run this from my shell (which happens to be bash).
^^^^^^^^^^^^^^^^^^^^^^^^
> That may look like perl forgot it has a "print()" function, but my
> shebang line is not the path to perl, so the shell runs the script, and
> I get the error.
>
> $ ./test
> ./test: line 3: print: command not found
At least bash 4.1 on Linux prints
bash: ./foo: /usr/locl/bin/perl: bad interpreter: No such file or directory
here. But an older version of bash (or some other shell) may behave as
stated.
>
> A quick and dirty fix involves a little bit of code, but this may be all
> you need to figure out the problem.
[...]
> Perl: Useless use of division (/) in void context at ./test line 9.
[...]
> You could also just know all the perl errors, and although there are
> some people who may know all of them, you probably don't.
Or you may just know the general style of error messages from perl and
from your shell. In the example above, the error message
./test: line 3: print: command not found
has the form
$filename: line $linenumber: $message
Perl messages never look like this. They always have the form
$message at $filename line $linenumber
(plus possibly a hint on the last read operation). This is sufficiently
different from the style of the shell (and indeed from just about any
other Unix program) that perl messages are easily recognized.
hp
------------------------------
Date: Sat, 31 Jul 2010 23:40:59 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: If Perl is compiled on a 32-bit system, and the system is upgraded to 64-bit...
Message-Id: <slrni59d4b.unv.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-07-31, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
>> E.g., Generally speaking, on "well-designed" 32-bit architecture, one
>> would be able to address 8GB of memory (4GB of data, and 4GB of
>> code).
> And we could split off the stack into a different segment, too and then
> address 12 GB of memory.
Not with C. The same subroutine should accept stack data pointers and
heap data pointers.
> the code also much, much smaller than 4GB
This is not what I experience with my system (which has less than 4GB
memory, though). The monsters like Mozilla take more text memory that
data memory (unless one loads a LOT of HTML into the browser). (This
might be related to 64KB granularity of system allocator in OS/2 [in
units of virtual memory, not real memory] - e.g, you order 1000 small
chunks of shared memory, and you use 64MB of virtual space.) And many
things related to DLLs are loaded into a code-like memory ("shared
address space region").
So maybe I'm wrong: the usage of "shared address space region" may be
large, but not everything which is put there is code. But to be
absolutely sure, I must run some tools on a memory state dump...
> I see the smiley but I'd like to clarify for our young readers that
> 32bit Linux uses near pointers. On the 386, a far pointer would be 48
> bits.
... but only if you round up to a multiple of 8bit; otherwise 46bit.
>> [*] AFAIK, Solaris (tries to?) separate code from data AMAP. On
>> Solaris/i386, are they in different segments?
> I don't think so. Sun likes Java. Java uses JIT compilers. JIT compilers
> and separated address spaces for code and data don't mesh well.
Do not see how this would be related. AFAI suspect (basing on the
sparse info I have seen), the only way to load code on solaris is to
write an executable module on disk, and dlopen() it.
Yours,
Ilya
------------------------------
Date: Sun, 1 Aug 2010 01:16:51 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: If Perl is compiled on a 32-bit system, and the system is upgraded to 64-bit...
Message-Id: <j0rei7-l0p2.ln1@osiris.mauzo.dyndns.org>
Quoth Ilya Zakharevich <nospam-abuse@ilyaz.org>:
> On 2010-07-31, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
> >[Ilya wrote]
>
> >> [*] AFAIK, Solaris (tries to?) separate code from data AMAP. On
> >> Solaris/i386, are they in different segments?
>
> > I don't think so. Sun likes Java. Java uses JIT compilers. JIT compilers
> > and separated address spaces for code and data don't mesh well.
>
> Do not see how this would be related. AFAI suspect (basing on the
> sparse info I have seen), the only way to load code on solaris is to
> write an executable module on disk, and dlopen() it.
mprotect(2). I suspect you can also allocate writeable-and-executable
memory with an mmap of /dev/zero.
Ben
------------------------------
Date: Sun, 1 Aug 2010 13:40:04 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: If Perl is compiled on a 32-bit system, and the system is upgraded to 64-bit...
Message-Id: <slrni5an8k.bf.hjp-usenet2@hrunkner.hjp.at>
On 2010-07-31 23:40, Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
> On 2010-07-31, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
>>> E.g., Generally speaking, on "well-designed" 32-bit architecture, one
>>> would be able to address 8GB of memory (4GB of data, and 4GB of
>>> code).
>
>> And we could split off the stack into a different segment, too and then
>> address 12 GB of memory.
>
> Not with C.
I used to think so, but it's not quite true.
> The same subroutine should accept stack data pointers and
> heap data pointers.
Yes, but
* automatic variables don't have to be on the "hardware stack".
* only those variables which actually are accessed via pointer
need to be in a pointer-accessible space.
So a compiler could put stuff like
* return addresses
* non-array automatic variables which don't have their address taken
* function arguments and return values
* temporary variables
into the stack segment and automatic variables which do have their
address taken into the data segment.
Among other things this means that return addresses are not accessible
with a pointer and can't be overwritten by a buffer overflow. It also
means that the size of the stack segment will almost always be very
small (arrays will (almost) never be there) and that function call and
return are more expensive (you need to maintain a second "stack").
So I'm not sure whether the advantages outweigh the disadvantages.
But that's moot. I don't expect any new segmented architectures, and
existing ones are either obsolete or used in "flat" mode.
>> the code also much, much smaller than 4GB
>
> This is not what I experience with my system (which has less than 4GB
> memory, though). The monsters like Mozilla take more text memory that
> data memory (unless one loads a LOT of HTML into the browser).
Mozilla is a monster, but it still uses only about 40 MB of code memory,
which is about 1% of 4 GB:
% perl -e 'while (<>) { my ($b, $e, $p) = /^(\w+)-(\w+) (\S+)/; $s =
hex($e) - hex($b); $s{$p} += $s } for (keys %s) { printf "%s %9d\n",
$_, $s{$_} / 1024 }' /proc/18752/maps |sort -n -k 2
---p 64
rwxp 192
r--s 496
rw-s 768
r-xp 40656
r--p 98524
rw-p 279960
(this is firefox 3.6 running on 32bit linux for about a day)
So if you moved that code into a different segment, you could use 4GB
instead of 3.96GB for data. Doesn't seem like much of an improvement.
(especially if you consider that on most 32-bit OSs the address space is
limited to 2 or 3 GB anyway - lifting that limit would have a much
larger effect).
>> I see the smiley but I'd like to clarify for our young readers that
>> 32bit Linux uses near pointers. On the 386, a far pointer would be 48
>> bits.
>
> ... but only if you round up to a multiple of 8bit; otherwise 46bit.
>
>>> [*] AFAIK, Solaris (tries to?) separate code from data AMAP. On
>>> Solaris/i386, are they in different segments?
>
>> I don't think so. Sun likes Java. Java uses JIT compilers. JIT compilers
>> and separated address spaces for code and data don't mesh well.
>
> Do not see how this would be related.
A JIT compiler needs to generate executable code which is immediately
executed by the same process. This is hard to do if the JIT compiler
can't put the code into a place where it can be executed.
> AFAI suspect (basing on the sparse info I have seen), the only way to
> load code on solaris is to write an executable module on disk, and
> dlopen() it.
That would absolutely kill the performance of a JIT compiler. If
Solaris/x86 uses separate code and data segments (which I doubt) then
there is probably some way (maybe with mmap) to map a region of memory
into both the data and the code segment. More likely they use a common
address space and just use mprotect to prevent execution of data which
isn't meant to be code.
hp
------------------------------
Date: Sat, 31 Jul 2010 14:23:56 -0700
From: Xho Jingleheimerschmidt <xhoster@gmail.com>
Subject: Re: piped open and shell metacharacters
Message-Id: <4c54b8c7$0$9143$ed362ca5@nr5-q3a.newsreader.com>
C.DeRykus wrote:
> On Jul 30, 5:21 pm, John Kelly <j...@isp2dial.com> wrote:
>> On Fri, 30 Jul 2010 16:20:45 -0700 (PDT), "C.DeRykus"
>>
>> <dery...@gmail.com> wrote:
>>> On Jul 30, 7:39 am, John Kelly <j...@isp2dial.com> wrote:
>>>> ...
>
>>> On FreeBSD (with small edits above), I don't see that
>>> happening.
>>> $ myscript.pl sleep 60
>>> parent shell=71889 perl process=75147 perl kid=75148
> JK> That's what I'm saying; the kid pid is only 1 greater than
> JK> the perl pid, which means there was never a shell pid
> JK> launched.
>>> $ ps -ax
>>> PID TT STAT TIME COMMAND
>>> 71889 2 SNs 0:00.01 -bash (bash)
>>> 75147 2 SN+ 0:00.02 /usr/bin/perl ./shell.pl sleep 60
>>> 75148 2 SN+ 0:00.00 sleep 60
>>> ....
>>> I believe execl in the perl kid launches a shell
>>> which then gets overlaid by sleep().
> JK> I don't think so.
> JK>
> JK> You could overlay the shell by prefixing the command
> JK> with the "exec" shell builtin, but I didn't do that.
> JK>
> JK> Seems like perl is recognizing 2>&1 as a limited special
> JK> case, copying
> JK> fd1 to fd2 , then exec'ing the binary directly, without
> JK> sing a shell.
>
> Maybe I missed something but I anything supporting your
> supposition in the source or docs:
I don't see it in the docs either. But I'm quite sure it is in the
source, as the behavior indubitably exists, as verified with strace, and
I doubt perl has a mind of its own.
------------------------------
Date: Sun, 1 Aug 2010 01:27:52 -0700 (PDT)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: piped open and shell metacharacters
Message-Id: <ef252423-29c8-418d-b8d4-b2d16ca7b927@u38g2000prh.googlegroups.com>
On Jul 31, 2:23=A0pm, Xho Jingleheimerschmidt <xhos...@gmail.com> wrote:
> C.DeRykus wrote:
> > On Jul 30, 5:21 pm, John Kelly <j...@isp2dial.com> wrote:
> >> On Fri, 30 Jul 2010 16:20:45 -0700 (PDT), "C.DeRykus"
>
> >> <dery...@gmail.com> wrote:
> >>> On Jul 30, 7:39 am, John Kelly <j...@isp2dial.com> wrote:
> >>>> ...
>
> >>> On FreeBSD (with small edits above), I don't see that
> >>> happening.
> >>> $ myscript.pl =A0sleep 60
> >>> parent shell=3D71889 perl process=3D75147 =A0perl kid=3D75148
> > JK> That's what I'm saying; the kid pid is only 1 greater than
> > JK> the perl pid, which means there was never a shell pid
> > JK> launched.
> >>> $ ps -ax
> >>> =A0PID =A0TT =A0STAT =A0 =A0 =A0TIME COMMAND
> >>> 71889 =A0 2 =A0SNs =A0 =A00:00.01 -bash (bash)
> >>> 75147 =A0 2 =A0SN+ =A0 =A00:00.02 /usr/bin/perl ./shell.pl sleep 60
> >>> 75148 =A0 2 =A0SN+ =A0 =A00:00.00 sleep 60
> >>> ....
> >>> I believe execl in the perl kid launches a shell
> >>> which then gets overlaid by sleep().
> > JK> I don't think so.
> > JK>
> > JK> You could overlay the shell by prefixing the command
> > JK> with the "exec" shell builtin, but I didn't do that.
> > JK>
> > JK> Seems like perl is recognizing 2>&1 as a limited special
> > JK> case, copying
> > JK> fd1 to fd2 , then exec'ing the binary directly, without
> > JK> sing a shell.
>
> > Maybe I missed something but I anything supporting your
> > supposition in the source or docs:
>
> I don't see it in the docs either. =A0But I'm quite sure it is in the
> source, as the behavior indubitably exists, as verified with strace, and
> I doubt perl has a mind of its own.
Yes, IIUC, it looks like there is a dup and the shell's
bypassed:
From doio.c:
/* handle the 2>&1 construct at the end */
if (*s =3D=3D '>' && s[1] =3D=3D '&' && s[2] =3D=3D '1'
...
if (!*t && (PerlLIO_dup2(1,2) !=3D -1)) {
s[-2] =3D '\0';
break;
}
}
--
Charles DeRykus
------------------------------
Date: Sun, 01 Aug 2010 12:39:21 +0000
From: John Kelly <jak@isp2dial.com>
Subject: Re: piped open and shell metacharacters
Message-Id: <heqa56d3vri1nb7li66c3578l45n4nvcd5@4ax.com>
On Sun, 1 Aug 2010 01:27:52 -0700 (PDT), "C.DeRykus" <derykus@gmail.com>
wrote:
>Yes, IIUC, it looks like there is a dup and the shell's
>bypassed:
>
> From doio.c:
>
> /* handle the 2>&1 construct at the end */
> if (*s == '>' && s[1] == '&' && s[2] == '1'
> ...
> if (!*t && (PerlLIO_dup2(1,2) != -1)) {
> s[-2] = '\0';
> break;
> }
> }
Interesting it says "at the end"
I wonder if placing it elsewhere in the command will circumvent Perl's
shortcut and invoke a shell as usual.
--
Web mail, POP3, and SMTP
http://www.beewyz.com/freeaccounts.php
------------------------------
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 3056
***************************************
