[18705] in Perl-Users-Digest
Perl-Users Digest, Issue: 873 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu May 10 21:05:53 2001
Date: Thu, 10 May 2001 18:05:11 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <989543110-v10-i873@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Thu, 10 May 2001 Volume: 10 Number: 873
Today's topics:
Re: 1 billion seconds bug (Craig Berry)
Re: 1 billion seconds bug <ilya@math.ohio-state.edu>
Re: CGI and printing vars <todd@designsouth.net>
Re: CGI and printing vars <godzilla@stomp.stomp.tokyo>
cgi mini shopping cart script question <vrdoljak@uclink.berkeley.edu>
Re: cgi.pm problems (David Efflandt)
Re: Good editor for perl Use Scite ! <bman@bolek.com>
Re: Good editor for perl Use Scite ! <dodger@necrosoft.net>
Re: Local Time <flavell@mail.cern.ch>
Re: Local Time (Abigail)
multi thread sockets <root@novastar.dtdns.net>
Posting Guidelines for comp.lang.perl.misc ($Revision: tadmc@augustmail.com
proposition to webmasters <vincentg@datashaping.com>
Question about Const package <goldbb2@earthlink.net>
Re:[OT] RTF -> PDF <tom.beer@btfinancialgroup.spamfilter.com>
regexp to expand variables <diab.lito@usa.net>
Re: setting environment variables <bop@mypad.com>
Re: setting environment variables <uri@sysarch.com>
Re: setting environment variables <jurgenex@hotmail.com>
Tuning Perl application <pade@trifox.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 10 May 2001 22:42:50 -0000
From: cberry@cinenet.net (Craig Berry)
Subject: Re: 1 billion seconds bug
Message-Id: <tfm6ba3tofs149@corp.supernews.com>
Bart Lateur (bart.lateur@skynet.be) wrote:
: Craig Berry wrote:
: >Actually, since epoch seconds count from an absolute time point (1970 Jan
: >1 00:00:00 GMT) and are thus not timezone-dependent, we'll all hit it
: >simultaneously. Gives one a nice warm feeling of worldwide togetherness,
: >it does.
:
: Except for people using a Mac.
We were discussing the upcoming 1 billion mark of Unix epoch time, so I
didn't repeat the Unix part in my comment above. People using VMS have an
even weirder epoch, after all. :)
: Two differences:
:
: - The Mac epoch is the beginning of 1904. 1 billion is long past. The 3
: billion mark was reached on January 24, 1999.
Which reminds me once again of one of my favorite meaningless factoids:
Pi seconds is a nanocentury, to a precision good enough to make for useful
back-of-the-envelope calculations (since a century is roughly 3.16 billion
second).
--
| Craig Berry - http://www.cinenet.net/~cberry/
--*-- "God becomes as we are that we may be as he is."
| - William Blake
------------------------------
Date: 10 May 2001 22:43:56 GMT
From: Ilya Zakharevich <ilya@math.ohio-state.edu>
Subject: Re: 1 billion seconds bug
Message-Id: <9df5jc$djs$1@agate.berkeley.edu>
[A complimentary Cc of this posting was sent to
Bart Lateur
<bart.lateur@skynet.be>], who wrote in article <l62mft49r35cseuhhuang7pilbffqbi0hf@4ax.com>:
> Except for people using a Mac.
> - Seconds since epoch are in local time. Local time?!?! Yes, local
> time.
Hmm? Do you mean "seconds since epoch was reached in the local time"?
"Local time" according to the laws of 1904 (including Russia having a
Julian calendar), or backpropagated laws of 1981, or backpropagated
laws of the time of the last MacOS update, or what?
Or is it seconds between epoch and the moment when UTC local-time is
equal to the local time?
Puzzled,
Ilya
------------------------------
Date: Thu, 10 May 2001 23:45:13 GMT
From: "Todd Smith" <todd@designsouth.net>
Subject: Re: CGI and printing vars
Message-Id: <dKFK6.4065$I5.1466490@news1.rdc1.tn.home.com>
"Joe Schaefer" <joe+usenet@sunstarsys.com> wrote in message
news:m3vgn9exzd.fsf@mumonkan.sunstarsys.com...
> "Todd Smith" <todd@designsouth.net> writes:
>
> > And I hate typing $a = "stuff", $cgi->param(Name), "eqfefge",
> > $cgi->param(Email}, "aefeafeag"- because that's ugly.
>
> % man CGI
>
> Look for 'Vars' and/or 'import_names'.
>
Cool, thanks
------------------------------
Date: Thu, 10 May 2001 17:12:02 -0700
From: "Godzilla!" <godzilla@stomp.stomp.tokyo>
Subject: Re: CGI and printing vars
Message-Id: <3AFB2E52.490F0F3F@stomp.stomp.tokyo>
Todd Smith wrote:
> when I use CGI, sometimes I need to print some of the variables back out on
> the page. Or if I'm sending email to a few people based on input, like a
> feedback form, I like to make the body of the email all at once and store it
> in a variable for later. So, I wish I could do this:
> use CGI;
> $cgi = new CGI;
(snipped code)
As you know by now, there is a parallel article of mine
to this one, offering one cure for what CGI.pm screws up.
There is another way to avoid these myriad problems
presented by CGI.pm which only requires some skill;
write your own program.
Below my signature, as usual, you will find a test
script which performs in seventy or so very easy
lines, what you are using six-thousand-five-hundred
plus lines of CGI.pm to do, unsuccessfully. This
test script contains one of my off-the-shelf read
and parse routines which offers a minimal degree
of security. The remainder, is mostly printing.
Many advantages are quickly found with this method.
You have direct access to your read and parse, an
ability to parse input directly, create single
key and value pairs or modify to hash style with
single key and multiple values. You may also reduce
security or bolster security quickly and easily.
Lots of tricks can be included as needed along
with many other nice options, all directly and
quickly with no need to jump through CGI.pm hoops
only to discover CGI.pm tripped you up somewhere.
You expressed a wish to easily concatenate variables
in an easy fashion and, learned CGI.pm will not allow
this, without lots of unwarranted coding.
Have a look:
my ($send) = "Name: $in{Name}<BR>Email: $in{Email}";
Easy concatenation with old fashion double quotes.
You cannot do this with CGI.pm as you discovered.
This can be done when you write your own program.
Within my test script, you will note I split up
some of my print lines and use indentation. Run my
script and look at your document source. You will
view a very neat and well organized document source.
This is not easily done with CGI.pm methodolgy.
My script also displays a method of controlling
script event sequencing quickly and easily by
use of sub-routine calls, near the top of the
script where they are easy to change. For complex
scripts, this is life saver, especially if you
need to split up an html print, as with a chat
script or other script which prints html, a little
at time, sprinkled with processing code. You
cannot do this with CGI.pm; it only allows certain
event sequences for html and, those events are
difficult to access and modify.
No module overhead, no hoops through which to
jump, no unwarranted coding, no annoyance, just
a quick efficient short script which you may make
do whatever you like, easily.
So here you have an easy seventy lines of code
performing with success what CGI.pm could not
do with thousands of lines of code, not without
your having to ask how to make CGI.pm do what
you want, right?
Consider writing programs, not copying and pasting.
Godzilla!
--
#!perl
my ($script_name) = "test1.pl";
&Akostininchi_Ithana;
my ($send) = "
Name: $in{Name}
<BR>
Email: $in{Email}";
&Print;
sub Akostininchi_Ithana
{
if ($ENV{'CONTENT_LENGTH'} > 131072)
{ print "<HTML><BODY><P>Bozo!</BODY></HTML>"; exit; }
else
{
local (*in) = @_ if @_;
my ($i, $key, $value);
read (STDIN, $in, $ENV{'CONTENT_LENGTH'});
@in = split (/&/, $in);
foreach $i (0 .. $#in)
{
$in[$i] =~ s/\+/ /g;
($key, $value) = split (/=/, $in[$i], 2);
($value eq "") && next;
$key =~ s/%(..)/pack ("c",hex($1))/ge;
$value =~ s/%(..)/pack ("c",hex($1))/ge;
$value =~ s/\(/(/g;
$value =~ s/\)/)/g;
$value =~ s/\[/[/g;
$value =~ s/\\/\/g;
$value =~ s/\]/]/g;
$value =~ s/\^/^/g;
$value =~ s/`/`/g;
$value =~ s/{/{/g;
$value =~ s/}/}/g;
$value =~ s/\|/|/g;
$in{$key} .= "\0" if (defined($in{$key}));
$in{$key} .= $value;
}
return 1;
}
}
sub Print
{
print "Content-type: text/html\n\n
<BODY BGCOLOR=\"#ffffff\">
<FORM ACTION=\"$script_name\" METHOD=\"post\">
<FONT FACE=\"arial rounded mt bold\" SIZE=\"3\">
<INPUT TYPE=\"submit\" NAME=\"button\" VALUE=\"Test This\">
<P>
Name:
<INPUT TYPE=\"text\" NAME=\"Name\">
<P>
Email:
<INPUT TYPE=\"text\" NAME=\"Email\">
</FONT>
</FORM>
<P><P>
$send
</BODY></HTML>";
}
exit;
------------------------------
Date: Thu, 10 May 2001 16:49:48 -0700
From: Gordon Vrdoljak <vrdoljak@uclink.berkeley.edu>
Subject: cgi mini shopping cart script question
Message-Id: <3AFB291C.1AAA521C@uclink.berkeley.edu>
Hello,
I'm writing a mini cgi shopping cart script for people to purchase materials
from our lab. I've gotten it written as a form where each person puts in their
first name, last name, material (from a drop down list), and quantity.
When they add an item it will write out the information to a file (cart.txt for
want of a better name) and then display the items at the bottom of the form page
they fill out.
I'm having some trouble adding the last part where the person can remove items
from their list, clear their list, or submit the list (which sends the
information to a master file). Should it be given as a separate link to another
cgi script/html page, or is there a way of adding additional 'buttons' to the
same cgi script to perform different tasks if pressed such as deleting items
from the list or submitting all the information?
Any comments appreciated greatly,
Sincerely,
Gordon Vrdoljak.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Gordon Ante Vrdoljak Electron Microscope Lab
ICQ 23243541 http://nature.berkeley.edu/~gvrdolja 26 Giannini Hall
vrdoljak@uclink.berkeley.edu UC Berkeley
phone (510) 642-2085 Berkeley CA 94720-3330
fax (510) 643-6207 cell (510) 290-6793
------------------------------
Date: Fri, 11 May 2001 00:13:26 +0000 (UTC)
From: see-sig@from.invalid (David Efflandt)
Subject: Re: cgi.pm problems
Message-Id: <slrn9fmbl6.bsn.see-sig@typhoon.xnet.com>
On Thu, 10 May 2001 19:33:05 +0800, alex <nobody@nowhere.net> wrote:
> it display me something like this on the broswer windows ,i mean ,in the
> browsing windows
>
> pragma : no-cache content-type:text/html
> virtual clock
> the time the house the day the month the year
> the click boxes~~~~
> the 12 or 24 radios
> reset and submit
>
> the problem is why would the pragma:no-cache will be printed on the browser
> windows without braces as a header attribute
You still have not answered, what OS, what web server? For some reason
your web server appears to have already printed its headers and ignores
yours. You might try giving the script an 'nph-' filename prefix
(non-parsed headers) and tell CGI.pm to do nph.
This apparently has nothing to do with Perl, since it is outputting the
proper headers (you just do not see the newlines when viewed has html).
Ask on a newsgroup related to your web server why this server ignores your
headers.
--
David Efflandt (Reply-To is valid) http://www.de-srv.com/
http://www.autox.chicago.il.us/ http://www.berniesfloral.net/
http://cgi-help.virtualave.net/ http://hammer.prohosting.com/~cgi-wiz/
------------------------------
Date: Fri, 11 May 2001 00:01:39 GMT
From: "--==[bMan]==--" <bman@bolek.com>
Subject: Re: Good editor for perl Use Scite !
Message-Id: <3AFB2BD3.B7B42F86@bolek.com>
Yeah, but nedit runs on all of them and it's GUI :-) (http://www.nedit.com)
Fairlight wrote:
> On Wed, 09 May 2001 21:32:12 GMT, smilepak <smilepak@hotmail.com> wrote:
> >Use CuteHTML!
>
> Funny, I have no problems with vim in any environment...from linux to
> solaris to cygwin to win95 native32.
>
> mark->
> --
> Fairlight-> ||| | Fairlight Consulting
> __/\__ ||| "I'm talking for free, |
> <__<>__> ||| It's a New Religion..." | http://www.fairlite.com
> \/ ||| --Le Bon | info@fairlite.com
--
Bolek,
URL: http://www.bolek.com
e-mail: bman@bolek.com
ICQ: 4086197, Address: 402905326
------------------------------
Date: Fri, 11 May 2001 00:16:21 GMT
From: "Dodger" <dodger@necrosoft.net>
Subject: Re: Good editor for perl Use Scite !
Message-Id: <pbGK6.1080$LJ4.465896@news1.rdc2.pa.home.com>
"--==[bMan]==--" <bman@bolek.com> wrote in message
news:3AFB2BD3.B7B42F86@bolek.com...
> Fairlight wrote:
> > Funny, I have no problems with vim in any environment...from linux to
> > solaris to cygwin to win95 native32.
> Yeah, but nedit runs on all of them and it's GUI :-)
(http://www.nedit.com)
The use of the word 'but' in here seems to indicate that somehow vim doesn't
or isn't or both.
In fact, vim (as gvim) is GUI, and it runs on all of them, as Fairlight
said.
--
Dodger
www.dodger.org
www.necrosoft.net
www.gothic-classifieds.com
------------------------------
Date: Fri, 11 May 2001 00:40:31 +0200
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: Local Time
Message-Id: <Pine.LNX.4.30.0105102352120.27671-100000@lxplus003.cern.ch>
On Thu, 10 May 2001, Scratchie wrote:
> I think the "insecurity" of using `date` to retrieve a date string has
> been, shall we say, somewhat overstated in this thread.
If it was about one isolated specimen, then sure, you'd be right.
> Not everyone is
> writing enterprise-level mission-critical apps in perl.
Not everyone who was duped by a relatively recent virus attack was
individually and personally responsible for knocking-out their
enterprise's entire room-booking and scheduling system, making work
essentially impossible and leading to one of their sysmanagers
practically having hysterics, as I witnessed at a site which I
happened to be visiting on the day (and which of course I won't be
naming here).
But if they had been practicing safe systems of work, it wouldn't have
happened.
> Some of us are
> just writing admin scripts to help us maintain our servers or whatnot.
Security begins at home?
> Some of us are writing silly little CGI hacks
You might want to keep in mind that a CGI script is effectively an
extension to a web server. Web servers can nowadays be mission
critical services. You better be pretty sure what you're doing if you
line one of those up for the chop. Our server log has all those
entries in it from wishful thinkers who are trying to retrieve
/etc/passwd via loopholes in CGI scripts, to take just one example.
What do you suppose the -T option was meant for? Not specifically for
CGI, probably, but it sure does rate to help. I wouldn't test-fly a
CGI script without it. On the other hand I would't unthinkingly rely
on it to keep me out of trouble (one does have to use a certain degree
of intelligence in the untainting if it's to do its job).
> Some people are even actually
> rank newbies, learning to code perl
Which is why it's so upsetting to see people confidently offering them
bad examples. Especially people who failed to recognise that better
answers HAD already been posted, and by informants whom I have learned
to respect for their competence and their consideration for those who
are genuinely trying to learn.
> without being berated over security
I've never seen a beginner _question_ here berated over security;
what's going on here is that a bad _answer_ is being put under the
microscope, not because this one individual incident is such a big
deal, but because it rates to blow up into something much bigger
if/when the hon. Usenaut starts doing a project that way in earnest.
The web is littered with insecure scripts that are damaging folks'
systems day in and day out. Sometimes they're just an irritation,
somtimes they're a major incident. When there are recognised
techniques for avoiding many of those insecurities, why are you so
determined to shout-down the advice?
> because every single script they've ever written doesn't necessarily run
> with taint mode, -w and use strict.
You've got that arse-about-face as we say: the reason for those
options is not because sackcloth and ashes are good for you, but
because they are the computer's way of keeping you out of trouble.
Or would you rather switch off the smoke alarms and not call the fire
service until you could be sure the flames had really got going?
I can't read Abigail's mind, but I suspect the intended message was a
rather different one than the one you are trying to agree with. Yes,
it's true: if I've been so careless as to accept an unreviewed
executable called 'date' into my path, then I've been very foolish.
So the warning about a "false sense of security" was well taken.
But as long as I'm not wearing my wizard's hat, then even if I had
been duped into accepting a rogue executable, it won't just slink into
/bin/date under its own steam - and even if it did manage to get
itself in there, it would rate to get noticed rather soon, unless it
mysteriously worked out how the system auditing was done and managed
to subvert it before any alarms went off.
btw, I'm just an ordinary user here. Nothing stronger than an AFS
token in my hands just now.
have fun, keep taking the tablets...
------------------------------
Date: Thu, 10 May 2001 23:16:42 +0000 (UTC)
From: abigail@foad.org (Abigail)
Subject: Re: Local Time
Message-Id: <slrn9fm8aq.cp9.abigail@tsathoggua.rlyeh.net>
Alan J. Flavell (flavell@mail.cern.ch) wrote on MMDCCCIX September MCMXCIII
in <URL:news:Pine.LNX.4.30.0105102352120.27671-100000@lxplus003.cern.ch>:
-- You've got that arse-about-face as we say: the reason for those
-- options is not because sackcloth and ashes are good for you, but
-- because they are the computer's way of keeping you out of trouble.
-- Or would you rather switch off the smoke alarms and not call the fire
-- service until you could be sure the flames had really got going?
--
-- I can't read Abigail's mind, but I suspect the intended message was a
-- rather different one than the one you are trying to agree with. Yes,
-- it's true: if I've been so careless as to accept an unreviewed
-- executable called 'date' into my path, then I've been very foolish.
-- So the warning about a "false sense of security" was well taken.
--
-- But as long as I'm not wearing my wizard's hat, then even if I had
-- been duped into accepting a rogue executable, it won't just slink into
-- /bin/date under its own steam - and even if it did manage to get
-- itself in there, it would rate to get noticed rather soon, unless it
-- mysteriously worked out how the system auditing was done and managed
-- to subvert it before any alarms went off.
False sense of security.
Just a few things:
-- If one is able to install a rogue date in your PATH (and *before*
/bin), one might very well be able to alter the program calling date,
removing for instance '/bin/'. You'd be a fool to trust it can't be
done.
-- Given that the attacker has access to directories in your PATH, the
attacker might have access to other parts of your system too. (S)he
could just chroot() to you a place under her control, a place that
finds a rogue date in /bin/date.
If you work on a system where an attacker can install a rogue binary in
your PATH, the right defense isn't "use full path names when calling other
programs", nor is it "just don't use backticks".
There's only one way: Fix your security hole, and restore from a known
uncompromised backup.
Abigail
--
sub _ {$_ = shift and y/b-yB-Y/a-yB-Y/ xor !@ _?
exit print :
print and push @_ => shift and goto &{(caller (0)) [3]}}
split // => "KsvQtbuf fbsodpmu\ni flsI " xor & _
------------------------------
Date: Fri, 11 May 2001 01:55:00 +0300
From: "novastar" <root@novastar.dtdns.net>
Subject: multi thread sockets
Message-Id: <9df686$t0n$1@usenet.otenet.gr>
Hello all,
I am scannining my network with 10 threaded sockets each time. When all
these 10 threads have been terminated I have to go for the next 10 sockets
and so on. My problem is that I can not figure out if all these10 threads
have been terminated for sure in order to go for the next.
Please help.
------------------------------
Date: Thu, 10 May 2001 23:57:02 GMT
From: tadmc@augustmail.com
Subject: Posting Guidelines for comp.lang.perl.misc ($Revision: 1.1 $)
Message-Id: <iVFK6.2110$%L5.38854@insync>
[ Editor's note:
We are _still_ not ready to have the autoposting done from dfw.pm.org,
but I've waited long enough, so I am posting this from one of
my personal ISPs. It will eventually (hopefully next week) be
posted from the correct place.
tadmc
]
Outline
Before posting to comp.lang.perl.misc
Must
- Check the Perl Frequently Asked Questions (FAQ)
- Check the other standard Perl docs (*.pod)
Really Really Should
- Lurk for a while before posting
- Search a Usenet archive
If You Like
- Check Other Resources
Posting to comp.lang.perl.misc
Is there a better place to ask your question?
- Question should be about Perl, not about the application area
How to participate (post) in the clpmisc community
- Carefully choose the contents of your Subject header
- Use an effective followup style
- Speak Perl rather than English, when possible
- Do not expect people to do a machine's work
- Do not type in Perl code
- Provide enough information
- Do not provide too much information
- Do not post binaries, HTML, or MIME
Social faux pas to avoid
- Asking a Frequently Asked Question
- Asking a question easily answered by a cursory doc search
- Asking for emailed answers
- Beware of saying "doesn't work"
- Count to ten before composing a followup when you are upset
- Count to ten after composing and before posting when you are upset
-----------------------------------------------------------------
Posting Guidelines for comp.lang.perl.misc ($Revision: 1.1 $)
The comp.lang.perl.misc (clpmisc) Usenet newsgroup is for the discussion
of using the Perl programming language.
Since clpmisc is such a high-traffic newsgroup (more than 100 articles
per day), there a number of measures that we all should take to keep the
group useful for everyone.
This article describes things that you should, and should not, do to
increase your chances of getting an answer to your Perl question. It is
available in POD, HTML and plain text formats at
<URL:http://dfw.pm.org/clpmisc.shtml/>.
For more information about netiquette in general, see the "Netiquette
Guidelines" at <URL:http://andrew2.andrew.cmu.edu/rfc/rfc1855.html>.
Do *NOT* send email to the maintainer of these guidelines. It will be
discarded unread. The guidelines belong to the newsgroup so all
discussion should appear in the newsgroup. I am just the secretary that
writes down the consensus of the group.
Before posting to comp.lang.perl.misc
Must
This section describes things that you *must* do before posting to
clpmisc.
Check the Perl Frequently Asked Questions (FAQ)
Checking the FAQ before posting is required in Big 8 newsgroups in
general, there is nothing clpmisc-specific about this requirement.
You are expected to do this in nearly all newsgroups.
Check the other standard Perl docs (*.pod)
The perl distribution comes with much more documentation than is
available for most other newsgroups, so in clpmisc you should also
see if you can find an answer in the other (non-FAQ) standard docs
before posting.
It is *not* required, or even expected, that you actually *read* all of
Perl's standard docs, only that you spend a few minutes searching them
before posting.
Try doing a word-search in the standard docs for some words/phrases
taken from your problem statement or from your very carefully worded
`Subject:' header.
Really Really Should
This section describes things that you *really should* do before posting
to clpmisc.
Lurk for a while before posting
It is standard netiquette to monitor (lurk) a newsgroup for a few
days or weeks before posting. By doing so you will be able to see
what is socially acceptable in the newsgroup.
You can "power lurk" by reading 20-30 posts a day for the last
several days at a Usenet archive.
Search a Usenet archive
There are tens of thousands of Perl programmers. It is very likely
that your question has already been asked (and answered). See if you
can find where it has already been answered.
One such searchable archive is
<URL:http://www.deja.com/home_ps.shtml>.
If You Like
This section describes things that you *can* do before posting to
clpmisc.
Check Other Resources
You may want to check in books or on web sites to see if you can
find the answer to your question.
But you need to consider the source of such information, there are a
lot of very poor Perl books and web sites, and several good ones
too, of course.
Posting to comp.lang.perl.misc
There can be 200 messages in clpmisc in a single day. Nobody is going to
read every article. They must decide somehow which articles they are
going to read, and which they will skip.
Your post is in competition with 199 other posts. You need to "win"
before a person who can help you will even read your question.
These sections describe how you can help keep your article from being
one of the "skipped" ones.
Is there a better place to ask your question?
Question should be about Perl, not about the application area
It can be difficult to separate out where your problem really is,
but you should make a conscious effort to post to the most
applicable newsgroup. That is, after all, where you are the most
likely to find the people who know how to answer your question.
Being able to "partition" a problem is an essential skill for
effectively troubleshooting programming problems. If you don't get
that right, you end up looking for answers in the wrong places.
It should be understood that you may not know that the root of your
problem is not Perl-related (the two most frequent ones are CGI and
Operating System related), so off-topic postings will happen from
time to time. Be gracious when someone helps you find a better place
to ask your question by pointing you to a more applicable newsgroup.
How to participate (post) in the clpmisc community
Carefully choose the contents of your Subject header
You have 40 precious characters of Subject to win out and be one of
the posts that gets read. Don't waste them. Take care while
composing them, they are the key that opens the door to getting an
answer.
Spend them indicating what aspect of Perl others will find if they
should decide to read your article.
Do not spend them indicating "experience level" (guru, newbie...).
Do not spend them pleading (please read, urgent, help!...).
Do not spend them on non-Subjects (Perl question, one-word
Subject...)
For more information on choosing a Subject see "Choosing Good
Subject Lines"
<URL:http://www.perl.com/CPAN-local/authors/Dean_Roehrich/subjects.p
ost>
Use an effective followup style
When composing a followup, quote only enough text to establish the
context for the comments that you will add. Always indicate who
wrote the quoted material. Never quote an entire article. Never
quote a .signature (unless that is what you are commenting on).
Intersperse your comments *following* the sections of quoted text
that your comments apply to. Failure to do this is called "Jeopardy"
posting because the answer comes before the question.
Reversing the chronology of the dialog makes it much harder to
understand (some folks won't even read it if written in that style).
For more information on quoting style, see
<URL:http://www.geocities.com/nnqweb/nquote.html>.
Speak Perl rather than English, when possible
Perl is much more precise than natural language. Saying it in Perl
instead will avoid misunderstanding your question or problem.
Do not say: I have variable with "foo\tbar" in it.
Instead say: I have $var = "foo\tbar", or I have $var = 'foo\tbar',
or I have $var = <DATA> (and show the data line).
Do not expect people to do a machine's work
You can ask perl itself to help you find common programming mistakes
by doing two things: enable warnings (perldoc warnings) and enable
"strict"ures (perldoc strict).
You should not bother the hundreds/thousands of readers of the
newsgroup without first seeing if a machine can help you find your
problem. It is demeaning to be asked to do the work of a machine. It
will annoy the readers of your article.
You can look up any of the messages that perl might issue to find
out what the message means and how to resolve the potential mistake
(perldoc perldiag). If you would like perl to look them up for you,
you can put "use diagnostics;" near the top of your program.
Do not type in Perl code
Use copy/paste or your editor's "import" function or something
rather than attempting to type in your code. If you make a typo you
will get followups about your typos instead of about the question
you are trying to get answered.
Provide enough information
If you do the things in this item, you will have an Extremely Good
chance of getting people to try and help you with your problem!
These features are a really big bonus toward your question winning
out over all of the other posts that you are competing with.
First make a short (less than 20-30 lines) and *complete* program
that illustrates the problem you are having. People should be able
to run your program by copy/pasting the code from your article. (You
will find that doing this step very often reveals your problem
directly. Leading to an answer much more quickly and reliably than
posting to Usenet.)
Describe *precisely* the input to your program. Also provide example
input data for your program. If you need to show file input, use the
__DATA__ token (perldata.pod) to provide the file contents inside of
your Perl program.
Show the output (including the verbatim text of any messages) of
your program.
Describe how you want the output to be different from what you are
getting.
If you have no idea at all of how to code up your situation, be sure
to at least describe the 2 things that you *do* know: input and
desired output.
Do not provide too much information
Do not just post your entire program for debugging. Most especially
do not post someone *else's* entire program.
Do not post binaries, HTML, or MIME
clpmisc is a text only newsgroup. If you have images or binaries
that explain your question, put them in a publically accessible
place (like a Web server) and provide a pointer to that location. If
you include code, cut and paste it directly in the message body.
Don't attach anything to the message. Don't post vcards or HTML.
Many people (and even some Usenet servers) will automatically filter
out such messages. Many people will not be able to easily read your
post. Plain text is something everyone can read.
Social faux pas to avoid
The first two below are symptoms of lots of FAQ asking here in clpmisc.
It happens so often that folks will assume that it is happening yet
again. If you have looked but not found, or found but didn't understand
the docs, say so in your article.
Asking a Frequently Asked Question
It should be understood that you may have missed the applicable FAQ
when you checked, which is not a big deal. But if the Frequently
Asked Question is worded similarly to your question, folks will
assume that you did not look at all. Don't become indignant at
pointers to the FAQ, particularly if it solves your problem.
Asking a question easily answered by a cursory doc search
If folks think you have not even tried the obvious step of reading
the docs applicable to your problem, they are likely to become
annoyed.
If you are flamed for not checking when you *did* check, then just
shrug it off (and take the answer that you got).
Asking for emailed answers
Emailed answers benefit one person. Posted answers benefit the
entire community. If folks can take the time to answer your
question, then you can take the time to go get the answer in the
same place where you asked the question.
It is OK to ask for a *copy* of the answer to be emailed, but many
will ignore such requests anyway. If you munge your address, you
should never expect (or ask) to get email in response to a Usenet
post.
Ask the question here, get the answer here (maybe).
Beware of saying "doesn't work"
This is a "red flag" phrase. If you find yourself writing that,
pause and see if you can't describe what is not working without
saying "doesn't work". That is, describe how it is not what you
want.
Count to ten before composing a followup when you are upset
This is recommended in all Usenet newsgroups. Here in clpmisc, most
flaming sub-threads are not about any feature of Perl at all! They
are most often for what was seen as a breach of netiquette. If you
have lurked for a bit, then you will know what is expected and won't
make such posts in the first place.
But if you get upset, wait a while before writing your followup. I
recommend waiting at least 30 minutes.
Count to ten after composing and before posting when you are upset
After you have written your followup, wait *another* 30 minutes
before committing yourself by posting it. You cannot take it back
once it has been said.
AUTHOR
Tad McClellan <tadmc@augustmail.com>
------------------------------
Date: Thu, 10 May 2001 15:13:23 -0700
From: Vincent Granville <vincentg@datashaping.com>
Subject: proposition to webmasters
Message-Id: <3AFB1283.68D2C84D@datashaping.com>
I am interested in swapping links. Visit my web site for
details on reciprocal links, or contact me directly, if you
offer compatible contents (statistics, data mining,
computational finance, software). Thank you.
Regards,
Vincent Granville, Ph.D.
http://www.datashaping.com
------------------------------
Date: Thu, 10 May 2001 20:16:41 -0400
From: Benjamin Goldberg <goldbb2@earthlink.net>
Subject: Question about Const package
Message-Id: <3AFB2F69.63B480EC@earthlink.net>
I don't have perl on my system, so I can't test it out right now, but...
Consider the following:
use Tie::Const;
my (%h);
const \%h, { 1 => 2, 3 => 4 };
my $x = \$h{1};
$$x = 5;
Unless I'm mistaken, this works without error. Somebody please tell me
I'm wrong?
--
Shift to the left, shift to the right, mask in, mask out, BYTE, BYTE,
BYTE !!!
------------------------------
Date: Fri, 11 May 2001 09:45:44 +1000
From: "Tom Beer" <tom.beer@btfinancialgroup.spamfilter.com>
Subject: Re:[OT] RTF -> PDF
Message-Id: <9df96c$dpu$1@merki.connect.com.au>
Actually, these packages on their own will NOT do this, but there are
several ways to achieve it.
1. Purchase Adobe Acrobat (full version).
2. Print to a postscript driver (freely downloadable from www.adobe.com
amongst others). Then convert the postscript using Ghostscript.
(http://www.cs.wisc.edu/~ghost/index.html)
3. Download the Jaws 5d pdf creator (www.ctrlp.com)
Also check out Usenet groups comp.text.pdf and comp.lang.postscript
Tom.
"John W. Krahn" <krahnj@acm.org> wrote in message
news:3AFB08CA.FD0B16C9@acm.org...
> Barry Trottier wrote:
> >
> > Is there anything out there that converts from RTF to PDF?
>
> MS Word, StarOffice, WordPerfect, ...
>
> What is your Perl question?
>
>
> John
> --
> use Perl;
> program
> fulfillment
------------------------------
Date: Fri, 11 May 2001 01:55:22 +0200
From: "Mario Rizzuti" <diab.lito@usa.net>
Subject: regexp to expand variables
Message-Id: <3UFK6.3357$iC1.81725@news6.giganews.com>
Could someone please make a regexp that substitutes a variable name with its
value? there is one in the FAQ but doesn't match hashes and arrays
elements.Thanks anyone.
Mario Rizzuti
------------------------------
Date: Thu, 10 May 2001 15:12:39 -0400
From: "flash" <bop@mypad.com>
Subject: Re: setting environment variables
Message-Id: <sHBK6.6350$h%.1678288@news20.bellglobal.com>
unix or windows?
in unix try
@args = ("set", "PRINTER=printername");
system(@args);
I dont think this will work in a CGI enviroment but it should in work in
command line stuff.
"Fredrik de Vibe" <fredrik@devibe.net> wrote in message
news:3AFAD6B5.ED50CE78@devibe.net...
> Hi
>
> There's probably a simple solution to this, but I just can't find it.
> How do I set environment variables (like *nix' export, i.e. 'export
> PRINTER=printername') in perl?
> I tried $ENV{'PRINTER'} = "printername";, but that only worked while
> I was inside the script. Anybody know how to make this "permanent"?
>
>
> --Fredrik
>
------------------------------
Date: Thu, 10 May 2001 22:28:22 GMT
From: Uri Guttman <uri@sysarch.com>
Subject: Re: setting environment variables
Message-Id: <x7d79gbzyy.fsf@home.sysarch.com>
>>>>> "f" == flash <bop@mypad.com> writes:
f> unix or windows?
f> in unix try
f> @args = ("set", "PRINTER=printername");
f> system(@args);
try it all you want. it won't do much.
that will run a single shell, set the PRINTER var (and maybe not even
export it but that is moot) and then exit. bye bye any new environment.
uri
--
Uri Guttman --------- uri@sysarch.com ---------- http://www.sysarch.com
SYStems ARCHitecture and Stem Development ------ http://www.stemsystems.com
Learn Advanced Object Oriented Perl from Damian Conway - Boston, July 10-11
Class and Registration info: http://www.sysarch.com/perl/OOP_class.html
------------------------------
Date: Thu, 10 May 2001 15:31:02 -0700
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: setting environment variables
Message-Id: <3afb16a6$1@news.microsoft.com>
[Jeopardectomy performed]
flash" <bop@mypad.com> wrote in message
news:sHBK6.6350$h%.1678288@news20.bellglobal.com...> unix or windows?
> "Fredrik de Vibe" <fredrik@devibe.net> wrote in message
> news:3AFAD6B5.ED50CE78@devibe.net...
> > How do I set environment variables (like *nix' export, i.e. 'export
> > PRINTER=printername') in perl?
> > I tried $ENV{'PRINTER'} = "printername";, but that only worked while
> > I was inside the script. Anybody know how to make this "permanent"?
> in unix try
> @args = ("set", "PRINTER=printername");
> system(@args);
> I dont think this will work in a CGI enviroment but it should in work in
> command line stuff.
Why do you believe that creating a grandchild process and setting the env
variable there will do any change to the env variable in the grandparent
process?
jue
------------------------------
Date: 11 May 2001 00:09:23 GMT
From: "Paul Dembry" <pade@trifox.com>
Subject: Tuning Perl application
Message-Id: <9dfajj$sos@dispatch.concentric.net>
I need to determine where time is being spent within my application. Is
there a profiling type of function/module that I can use to do this? There
are no command line options for this nor have I found anything in several
Perl books. I would like to know which subroutines are taking the most time
to execute.
Thanks,
Paul
------------------------------
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:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
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 V10 Issue 873
**************************************
