[31966] in Perl-Users-Digest
Perl-Users Digest, Issue: 3230 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Dec 8 14:09:26 2010
Date: Wed, 8 Dec 2010 11:09:07 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 8 Dec 2010 Volume: 11 Number: 3230
Today's topics:
PostScript::Simple - linedistance question <v.niekerk_@_hccnet.nl>
Re: PostScript::Simple - linedistance question <v.niekerk_@_hccnet.nl>
Re: PostScript::Simple - linedistance question <RedGrittyBrick@spamweary.invalid>
Re: Using Perl to find what address bar says <jwcarlton@gmail.com>
Re: Using Perl to find what address bar says (Randal L. Schwartz)
Re: Using Perl to find what address bar says <tzz@lifelogs.com>
Re: variables inside a string <use-net@tinita.de>
Re: Who will win the battle for control of the web? <hjp-usenet2@hjp.at>
Re: Who will win the battle for control of the web? <cartercc@gmail.com>
Re: Who will win the battle for control of the web? <hjp-usenet2@hjp.at>
Re: Who will win the battle for control of the web? <kkeller-usenet@wombat.san-francisco.ca.us>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 08 Dec 2010 18:35:11 GMT
From: Huub <v.niekerk_@_hccnet.nl>
Subject: PostScript::Simple - linedistance question
Message-Id: <4cffcfdf$0$4579$e4fe514c@dreader32.news.xs4all.nl>
Hi,
I have been using the PostScript::Simple package for quite some time and
initally with good results. However, after the necessary change of
printer (HP Deskjet 520 into DeskJet 690C), I noticed that the distance
between lines had changed slightly. When checking the code, I found
everything fine. BTW, the code also predefines A4 paper. Now, after
another necessary change of printer (Deskjet 690C into Epson Stylus S21),
I find that not only the distance problem persists, but the last line is
only printed partly. Can somebody please explain this to me?
Thank you..
------------------------------
Date: 08 Dec 2010 18:39:30 GMT
From: Huub <v.niekerk_@_hccnet.nl>
Subject: Re: PostScript::Simple - linedistance question
Message-Id: <4cffd0e2$0$4579$e4fe514c@dreader32.news.xs4all.nl>
On Wed, 08 Dec 2010 18:35:11 +0000, Huub wrote:
> Hi,
>
> I have been using the PostScript::Simple package for quite some time and
> initally with good results. However, after the necessary change of
> printer (HP Deskjet 520 into DeskJet 690C), I noticed that the distance
> between lines had changed slightly. When checking the code, I found
> everything fine. BTW, the code also predefines A4 paper. Now, after
> another necessary change of printer (Deskjet 690C into Epson Stylus
> S21), I find that not only the distance problem persists, but the last
> line is only printed partly. Can somebody please explain this to me?
>
> Thank you..
I should add that the script outputs to a .ps file and the file is
printed using Evince. It has been like that since I wrote the script.
------------------------------
Date: Wed, 08 Dec 2010 18:48:25 +0000
From: RedGrittyBrick <RedGrittyBrick@spamweary.invalid>
Subject: Re: PostScript::Simple - linedistance question
Message-Id: <4cffd2ed$0$12171$fa0fcedb@news.zen.co.uk>
On 08/12/2010 18:35, Huub wrote:
> I have been using the PostScript::Simple package for quite some time and
> initally with good results. However, after the necessary change of
> printer (HP Deskjet 520 into DeskJet 690C), I noticed that the distance
> between lines had changed slightly. When checking the code, I found
> everything fine. BTW, the code also predefines A4 paper. Now, after
> another necessary change of printer (Deskjet 690C into Epson Stylus S21),
> I find that not only the distance problem persists, but the last line is
> only printed partly. Can somebody please explain this to me?
Assuming you have not changed your Perl program, the generated
postscript must be the same. This means that this is probably not a Perl
question.
I imagine that Postscript::Simple may not take into account printer
capabilities as expressed in a PPD file. Conceivavbly this might cause
problems but I'd look elsewhere first.
Probably there are small differences in the Postscript emulation in the
three printers you mentioned. This could give rise to incorrect scaling.
It is also possible that the last printer has a smaller printable area
(due to the paper feed mechanism).
The Epson S21 is a very cheap inkjet printer - if (as seems likely) it
is not a postscript printer, you are probably using some other software
(e.g. Ghostscript) to rasterise the output of your Perl program - this
is another area where small differences in output might be introduced.
--
RGB
------------------------------
Date: Tue, 7 Dec 2010 14:21:36 -0800 (PST)
From: jwcarlton <jwcarlton@gmail.com>
Subject: Re: Using Perl to find what address bar says
Message-Id: <0762ffa5-8b27-41b3-a148-19b2c35d1ced@c17g2000prm.googlegroups.com>
On Nov 8, 1:53=A0am, jwcarlton <jwcarl...@gmail.com> wrote:
> Can you guys think of a way, in Perl, to find what the address bar
> actually says? I don't think that $ENV{'SCRIPT_NAME'} is quite the
> same, because it's only going to show me what it's SUPPOSED to be.
>
> I'm trying to find if a user is using something like anonymizer.com or
> hidemyass.com, and it seems like the easiest method is to compare
> $ENV{'SCRIPT_NAME'} to the address bar. I can do it in Javascript, but
> I'm hoping there's a way to do it in Perl.
In spite of the "genius" replies saying that this is impossible and
that I'm an idiot for asking, for future readers, there IS a way to
find if a user is using something like anonymizer.com or hidemyass.com
using Perl.
First, upload phpinfo.php (I know, that's PHP. Whatever. You can do it
in Perl if it suits your fancy):
<?php
phpinfo();
phpinfo(INFO_MODULES);
?>
Now, load this normally in your browser, then load it again using
hidemyass.com, or whatever other proxy you want.
Doing a side-by-side comparison, you'll see several discrepancies. The
most notable on my end is that hidemyass.com didn't recognize Session
Handling; so, I can simply load a session variable on one page, then
test for that variable on the next page. If it doesn't exist, then
they're probably using a proxy.
It's not perfect, since browsers with cookies disabled probably
wouldn't recognize sessions, either. But since my site would be
virtually unusable without cookies, I'm not so concerned about that.
If that won't work for you, another discrepancy found was that on a
normal load, HTTP_CONNECTION is set to "Keep-Alive"; but, using
proxies, it's not set. So, a simple check for $ENV{HTTP_CONNECTION}
might be all that's needed.
There were several discrepancies, though, so using this method you can
pick and choose what's different on your server.
Please don't bother replying to this thread, as I don't intend to
return. My email address is here, though, so feel free to email
questions.
TIMTOWTDI,
Jason
------------------------------
Date: Tue, 07 Dec 2010 19:31:21 -0800
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: Using Perl to find what address bar says
Message-Id: <8662v5x7na.fsf@red.stonehenge.com>
>>>>> "jwcarlton" == jwcarlton <jwcarlton@gmail.com> writes:
jwcarlton> If that won't work for you, another discrepancy found was that on a
jwcarlton> normal load, HTTP_CONNECTION is set to "Keep-Alive"; but, using
jwcarlton> proxies, it's not set. So, a simple check for $ENV{HTTP_CONNECTION}
jwcarlton> might be all that's needed.
But for those of you who actually want to learn something, there *are*
legitimate proxies that would be indistinguishable using these
techniques. So it doesn't matter that you compare proxied vs not, and
test for that. You'll break legit users.
It's too bad the original poster was so closed minded. {Sigh}
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.posterous.com/ for Smalltalk discussion
------------------------------
Date: Wed, 08 Dec 2010 08:11:48 -0600
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Using Perl to find what address bar says
Message-Id: <8739q8bbh7.fsf@lifelogs.com>
On Tue, 07 Dec 2010 19:31:21 -0800 merlyn@stonehenge.com (Randal L. Schwartz) wrote:
>>>>>> "jwcarlton" == jwcarlton <jwcarlton@gmail.com> writes:
jwcarlton> If that won't work for you, another discrepancy found was that on a
jwcarlton> normal load, HTTP_CONNECTION is set to "Keep-Alive"; but, using
jwcarlton> proxies, it's not set. So, a simple check for $ENV{HTTP_CONNECTION}
jwcarlton> might be all that's needed.
RLS> But for those of you who actually want to learn something, there *are*
RLS> legitimate proxies that would be indistinguishable using these
RLS> techniques. So it doesn't matter that you compare proxied vs not, and
RLS> test for that. You'll break legit users.
RLS> It's too bad the original poster was so closed minded. {Sigh}
For his stated purpose (some specific proxies) and the vast majority of
visitors his approach would work. Sometimes there's no perfect solution
and we have to settle for less; I think a real-world conversation would
have reached that conclusion quickly and without the animosity this
thread inspired in everyone.
Ted
------------------------------
Date: 8 Dec 2010 13:33:10 GMT
From: Tina =?UTF-8?Q?M=C3=BCller?= <use-net@tinita.de>
Subject: Re: variables inside a string
Message-Id: <8m9fomF6psU1@mid.individual.net>
sln@netherlands.com wrote:
>
> The fact is that if a user knows (or guesses) your statement form,
> he/she will be able to splice in code, in any construction of eval "".
not only then. it's way simpler.
consider:
@{[ system('rm ...') ]}
or
${\ system('rm ...') }
always remember that interpolation in perl does more than just replace
$foo with the value of $foo.
--
http://www.perl-community.de/
http://perlpunks.de/
------------------------------
Date: Wed, 8 Dec 2010 13:47:36 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Who will win the battle for control of the web?
Message-Id: <slrnifuvj8.s9v.hjp-usenet2@hrunkner.hjp.at>
On 2010-12-06 19:09, ccc31807 <cartercc@gmail.com> wrote:
> On Dec 6, 4:25 am, Bart Van der Donck <b...@nijlen.com> wrote:
>> IMHO Perl has already lost that battle years ago. Perl is a USA thing
>> by and for dinosaurs; it makes me think of George Bush.
I have no idea why Perl should be a "USA thing". It seems to be alive
and well in Europe, and from people who attend more conferences than me
I hear that the community in East Asia is especially vibrant.
>> PHP is the server scripting language of the web, and has proven it for
>> ten years now: international, global, community driven, fresh air,
>> modern.
>
> Did you read the article?
>
> WRT Flash, Silverlight, and the others mentioned, PHP is in the same
> position as Perl, except PHP is much less capable than Perl.
>
> I raised the possibility of using Perl to generate RIAs, and got a
> quick answer from Sherm and Tad: even the thought is off topic for
> Perl.
>
> If you want to develop rich internet applications, you might as well
> forget Perl, which is just as well suited to developing RIAs as a cast
> iron frying pan ... or so they say. They are probably right, at least,
> they won't get an argument from me.
You are confused about the difference between server-side and
client-side programming. For "rich internet applications" (make one
cross on the bullshit bingo card) you typically need both.
You need code which runs in the browser. That means that there needs to
be an interpreter for that code in the browser, and that limits you to a
handful of options: JavaScript, Flash, Java, ... unless you can convince
your users that your site is worth installing yet another plugin.
You also need code which runs on the server. Here you can use anything
you want: Perl, PHP, Python, Ruby, Java, C, Lisp, JavaScript, ...
Note that the overlap between client-side and server-side languages is
small: Java is about the only language which was popular for both,
but these days Java applets seem to be exceedingly rare (except for
remote management stuff). JavaScript OTOH seems to be quite unpopular on
the server despite a number of implementations. Flash on the server?
Never heard about that.
So for you almost always need two languages: One for the client-side
(typically JavaScript), and one for the server. There is no reason why
one should "forget Perl" on the server: It is just as well suited for
that task as PHP, Python, Ruby, Java, C, Lisp, etc. Each language has
its pros and cons, but I don't see anything in any of them which would
make it unsuitable for the server side of an AJAX application.
hp
------------------------------
Date: Wed, 8 Dec 2010 08:38:36 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: Who will win the battle for control of the web?
Message-Id: <fad21ab7-3cbb-4375-b376-44b7c3632430@m20g2000prc.googlegroups.com>
On Dec 8, 7:47=A0am, "Peter J. Holzer" <hjp-usen...@hjp.at> wrote:
> You are confused about the difference between server-side and
> client-side programming. For "rich internet applications" (make one
> cross on the bullshit bingo card) you typically need both.
No, not confused about server/client side. From the article: "Each of
the big three computing companies =96 Microsoft, Apple and Google =96 has
its own radically different vision to promote, as does the world=92s
biggest creative software company, Adobe." Yes, Flash and JavaScript
is interpreted in the browser, as is Java, and .NET relies on the MS
runtime, but that isn't the end of the story. You can write Flex using
notepad, run it through the Flex compiler, and produce Flex files. You
can also produce XML files that will run in a browser, not only XHTML
but things like SVG.
Maybe I'm confused about RIAs. Roughly, I see RIAs as something like
an interactive TV, e.g., the iPhone apps. My question was what role,
if any, Perl can play in creating RIAs. I don't have in mind a Perl
module to spit out Flash movies, but leveraging Perl's strengths in
the RIA arena.
> You need code which runs in the browser. That means that there needs to
> be an interpreter for that code in the browser, and that limits you to a
> handful of options: JavaScript, Flash, Java, ... unless you can convince
> your users that your site is worth installing yet another plugin.
Which you can't outside of a particular need. (Yesterday I installed
Scorch, the Sibelius music reader, to read some files, but I was
highly motivated to do that.)
> You also need code which runs on the server. Here you can use anything
> you want: Perl, PHP, Python, Ruby, Java, C, Lisp, JavaScript, ...
> Note that the overlap between client-side and server-side languages is
> small: Java is about the only language which was popular for both,
> but these days Java applets seem to be exceedingly rare (except for
> remote management stuff). JavaScript OTOH seems to be quite unpopular on
> the server despite a number of implementations. Flash on the server?
> Never heard about that.
Server side Perl emits files, which can be HTML files, PDF files, GIF
and JPEG files, ASCII text files, and so on. Can Perl generate a file
that will produce a rich internet experience for the user, i.e., in a
browser?
> So for you almost always need two languages: One for the client-side
> (typically JavaScript), and one for the server. There is no reason why
> one should "forget Perl" on the server: It is just as well suited for
> that task as PHP, Python, Ruby, Java, C, Lisp, etc. Each language has
> its pros and cons, but I don't see anything in any of them which would
> make it unsuitable for the server side of an AJAX application.
I just mentioned two, Flex and SVG. And yes, you can use Perl to emit
JavaScript to enable dynamic functionality for the end user, whether
you call it AJAX or just plain old JavaScript.
Seems to me that, in this brave new world of internet enabled devices
everywhere, that Perl needs to evolve or else become a niche language,
rather than the 'glue of the internet.'
It also seems to me that the Perl community is oblivious to these new
developments, fat, happy, barefoot, and dumb. OTOH, it wouldn't
surprise me to see a new PM that will produce something like this, but
I think it will come from a new generation.
CC.
------------------------------
Date: Wed, 8 Dec 2010 19:41:58 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Who will win the battle for control of the web?
Message-Id: <slrnifvkbn.ocn.hjp-usenet2@hrunkner.hjp.at>
[I note that we may have use a different definition for RIAs. For me
these include AJAX-based web-application, indeed I was thinking mostly
of them. But Wikipedia distinguishes between RIAs, which require the
user to install extra software (plugins, runtime environments, etc.) on
their PC and AJAX which uses only browser-builtin facilities. In recent
years there is little which can't be done with Ajax, and I think Ajax
will take an ever-larger piece of the cake and Flash and co will lose
ground]
On 2010-12-08 16:38, ccc31807 <cartercc@gmail.com> wrote:
> On Dec 8, 7:47 am, "Peter J. Holzer" <hjp-usen...@hjp.at> wrote:
>> You also need code which runs on the server. Here you can use anything
>> you want: Perl, PHP, Python, Ruby, Java, C, Lisp, JavaScript, ...
>
>> Note that the overlap between client-side and server-side languages is
>> small: Java is about the only language which was popular for both,
>> but these days Java applets seem to be exceedingly rare (except for
>> remote management stuff). JavaScript OTOH seems to be quite unpopular on
>> the server despite a number of implementations. Flash on the server?
>> Never heard about that.
>
> Server side Perl emits files,
No, it emits HTTP responses. A "file" is something on a disk (or similar
storage device), an HTTP response is a message in a communication
protocol.
> which can be HTML files, PDF files, GIF and JPEG files, ASCII text
> files, and so on. Can Perl generate a file that will produce a rich
> internet experience for the user, i.e., in a browser?
Same as any other language. You get an HTTP request, you process it, you
send an HTTP response. All of this is completely independent of the
language, except that you may find libraries and frameworks which are
more or less suited to the task at hand.
I don't understand what you mean by "a file that will produce a rich
internet experience". You can of course create any file from Perl. But
for some it would be foolish: If you want a .class-file, you use an
existing Java compiler, you don't write a new Java compiler from scratch
in Perl (But you might write a Perl compiler which emits Java byte code
in Perl). If by "a file that will produce a rich internet experience"
you mean a single file which contains the application and can be put on
a server and downloaded by the browser, then that consists mostly of
code (which has to be written), auxiliary data like icons, animations,
sounds, text, (which has to be produced) and a bit of packaging around
that. There's is not much room for a server-side programming language in
producing such a file: When the programmer is finished, its static
(although the programmer may of course use scripts to automate the
creation of some of its parts). The server side programming language
only comes into play, once the browser downloads the file and starts
executing it: Then the application will "phone home" and request data
which may be delivered by a piece of Perl talking to a database, for
example.
>> So for you almost always need two languages: One for the client-side
>> (typically JavaScript), and one for the server. There is no reason why
>> one should "forget Perl" on the server: It is just as well suited for
>> that task as PHP, Python, Ruby, Java, C, Lisp, etc. Each language has
>> its pros and cons, but I don't see anything in any of them which would
>> make it unsuitable for the server side of an AJAX application.
>
> I just mentioned two, Flex and SVG.
SVG is just a vector graphics format. You can of course produce SVG from
Perl, there are modules for that (or you could just hand-code it). It
isn't a programming language - for dynamic stuff in the browser it is
usually combined with JavaScript.
Flex is, AFAICS, mostly a development framework for Flash. It is
possible that the applications generated by that framework can only talk
to server-components sold by Adobe (like LiveCycle Data Services). Then
you're locked into your cozy little Adobe world and can only use what
Adobe provides. But if does talk standard protocols, then again it
doesn't matter whether the server side is written in Java, Perl, PHP or
Erlang.
> Seems to me that, in this brave new world of internet enabled devices
> everywhere, that Perl needs to evolve or else become a niche language,
> rather than the 'glue of the internet.'
>
> It also seems to me that the Perl community is oblivious to these new
> developments, fat, happy, barefoot, and dumb. OTOH, it wouldn't
> surprise me to see a new PM that will produce something like this, but
> I think it will come from a new generation.
Again, you haven't provided the slightest reason why you think so.
hp
------------------------------
Date: Wed, 8 Dec 2010 11:01:20 -0800
From: Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us>
Subject: Re: Who will win the battle for control of the web?
Message-Id: <0915t7xg3f.ln2@goaway.wombat.san-francisco.ca.us>
On 2010-12-08, ccc31807 <cartercc@gmail.com> wrote:
>
> Seems to me that, in this brave new world of internet enabled devices
> everywhere, that Perl needs to evolve or else become a niche language,
> rather than the 'glue of the internet.'
I'd think that the ''glue of the internet'' would be used in many more
places than just serving HTTP requests.
--keith
--
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information
------------------------------
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 3230
***************************************
