[29450] in Perl-Users-Digest
Perl-Users Digest, Issue: 694 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Jul 28 00:10:14 2007
Date: Fri, 27 Jul 2007 21: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 Fri, 27 Jul 2007 Volume: 11 Number: 694
Today's topics:
Re: @arts <tadmc@seesig.invalid>
Re: ERR: 13: Missing right $] (Alan Curry)
Re: filehandle, read lines <glex_no-spam@qwest-spam-no.invalid>
Re: Math <nospam-abuse@ilyaz.org>
Re: Math <hjp-usenet2@hjp.at>
Re: Perl with DBI <stoupa@practisoft.cz>
Re: Perl with DBI <stoupa@practisoft.cz>
Re: pid from startet process <hjp-usenet2@hjp.at>
Re: pid from startet process (Douglas Wells)
Re: Problem installing DBI <tlviewer@VISTAyahoo.com>
Re: Reading from stdin then launching a program that re <klaus03@gmail.com>
Re: Reading from stdin then launching a program that re <paduille.4061.mumia.w+nospam@earthlink.net>
Re: whether large hash might leak? <glex_no-spam@qwest-spam-no.invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 27 Jul 2007 23:29:57 GMT
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: @arts
Message-Id: <slrnfakvat.3ag.tadmc@tadmc30.sbcglobal.net>
Sherm Pendley <spamtrap@dot-app.org> wrote:
> "Mike Hartsough" <michaellhartsough@sbcglobal.net> writes:
>
>> In what way is "stick a pen up your ass" any near the same as "please
>> properly attribute your quotes" ? The latter is also in the "Posting
>> Guidelines", so why do you keep looking for
>
> Will you please give it a rest? Michele's attribution mistake may have
> been mildly annoying, but your three-day whining binge about it is far
> more so. Grow up.
It must be the "leaf" in its subthreads.
It will probably stop when there are no more followups.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Sat, 28 Jul 2007 00:24:31 +0000 (UTC)
From: pacman@TheWorld.com (Alan Curry)
Subject: Re: ERR: 13: Missing right $]
Message-Id: <f8e2bv$576$1@pcls6.std.com>
In article <5mfja35hsbkv6646k9qce9vnks11nuroj8@4ax.com>,
Michele Dondi <bik.mido@tiscalinet.it> wrote:
>On Fri, 27 Jul 2007 19:18:09 +1000, pp <pp@mm.org> wrote:
>
>>Subject: ERR: 13: Missing right $]
>
>How strange! Actually that doesn't look like a Perl error at all, if
>it's intended to be verbatim.
It appears to be the format of an error message from Embperl.
>
>>Can anyone tell me how to fix this error in perl?
>>The above error point to the following line or perl code.
>
>Sometimes errors are not reported to the *exact* they happen.
>
>>%UN_MONTH= map { lc($MONTH[$_]), $_ } 0..$#MONTH ; # look up by month
>
>This line of Perl code is syntactically fine, and I can't even see how
>could it fail at runtime.
Embperl uses [$ and $] as a matching pair of delimiters. It must have seen
the [$ and decided it wanted a $] then got upset when it didn't get one.
--
Alan Curry
pacman@world.std.com
------------------------------
Date: Fri, 27 Jul 2007 17:04:52 -0500
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: filehandle, read lines
Message-Id: <46aa6c04$0$3577$815e3792@news.qwest.net>
xhoster@gmail.com wrote:
> roy <roy.schultheiss@googlemail.com> wrote:
>> I receive a XML-File up to 1 GB full of orders every day. I have to
>> split the orders and load them into a database for further processing.
>> I share this job onto multiple processes. This runs properly now.
>
> This seems dangerous to me. Generally XML should be parsed by an XML
> parser, not by something that happens to parse some restricted subset of
[...]
> If parsing is not the bottleneck, then I'd just use something like
> XML::Twig to read this one XML file and parcel it out to 10 XML files as a
> preprocessing step. Then run each of those 10 files separately. Of
> course, if parsing is the bottleneck, then this would defeat the purpose of
> parallelizing.
Also, see xml_split, which is one of the tools included with XML::Twig.
http://search.cpan.org/~mirod/XML-Twig-3.29/tools/xml_split/xml_split
------------------------------
Date: Fri, 27 Jul 2007 20:12:45 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Math
Message-Id: <f8djjt$56u$1@agate.berkeley.edu>
[A complimentary Cc of this posting was sent to
Brian Blackmore
<blb8@po.cwru.edu>], who wrote in article <f8d43c$5ed$1@gnus01.u.washington.edu>:
> #!/usr/bin/perl
>
> $a=42.1; for (1..30) { $a+=0.1 }
> $b="$a"; print "a=",$a," b=",$b,"\n";
> $a==$b ? print "Equal\n" : print "Not equal\n" ;
>
> > > As is mentioned by perlnumber, converting from
> > > floating point to string is performed by the C compiler,
>
> > Nope, by C RT libraries. And the for these libraries, they do it
> > following instructions from perl.
>
> I would like to know for future reference if this is in the manuals
> or if I misinterpreted what's in perlnumber.
I think we discussed this already. I might have oversimplified things
when I wrote perlnumber (or [hopefully ;-] it might have been a later edit).
> Also, are these instructions discussed anywhere, or just in the
> source?
Might be in the autogenerated POD for Configure variables:
perl -V:d_Gconvert
There is also perlvar for $#, but I suspect it is erroneous.
> > > whence Perl is at the mercy of the system on which it was compiled.
>
> > And this the CHOICE made by perl. It could have done the conversion
> > itself.
>
> Is it a choice of what parameters to pass to CRTL that is causing
> the fault, or is it the choice to use the CRTL period? If it's a
> parameter issue, why haven't the parameters been changed?
There are two conflicting targets:
a) One does not want a silly semantic of number conversion (like
information loss);
b) One does not want to see silly bug reports like
why
perl -wle "$#='%.17g'; print 17.1"
prints garbage digits?
(I assume that this value of $# is the default, so setting it
would not appear in the bug report.)
c) The conversion should not be too slow.
With the current choice of $#, one STILL gets stuff as in "b". And
the precision is always always lost. But with finer $#, the bug
reports would be more frequent.
About mid-90s, there was a discussion about adding custom
stringification function, which does not has semantic of %.NNg, but
does better: it emits the minimal number of digits such that the
following conversion to a number would result in the initial number.
Somebody did a test, and found that using this custom function would
significantly slow down number-to-string conversion. So "c" was violate.
["a" would be fixed; it is not clear how this would change "b",
since fixing "a" increases number of cases where people would see
mismatch with "school arithmetic" (after performing arithmetic
operations on numbers with a few significant digits).]
However, a couple of years after this, I did some research, and found
out that perl was not caching results of number-to-string conversion.
After fixing it, the number of times perl calls number-to-string
conversion routines should have changed dramatically.
So it MIGHT be that using such a custom conversion function would not
violate "c". It also MIGHT be that it would not significantly
increase the flow of "b".
Choices, choices, choices - and shortage of time.
Hope this helps,
Ilya
------------------------------
Date: Sat, 28 Jul 2007 01:55:40 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Math
Message-Id: <slrnfal1fs.kkv.hjp-usenet2@zeno.hjp.at>
On 2007-07-27 19:05, Brian Blackmore <blb8@po.cwru.edu> wrote:
> Brian Blackmore <blb8@po.cwru.edu> wrote:
>> Is what you had in mind something like this:
>
>> #!/usr/bin/perl
>
>> $a=42.1; for (1..30) { $a+=0.1 }
$a after that is not 45.1. It is about 45.100000000000044.
>> $b="$a"; print "a=",$a," b=",$b,"\n";
>> $a==$b ? print "Equal\n" : print "Not equal\n" ;
>
>
> Sorry, I rescind my understanding because in C:
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main() {
> double a=42.1;
> char* c;
> double d;
> int i=30;
>
> for(;i>0;i--) { a+=0.1; }
> sprintf(c,"%f",a);
> d=atof(c);
>
> printf("%f\n",a);
> printf("%f\n",d);
>
> if(a!=d) { printf("Lost precision\n"); }
> else { printf("Okay\n"); }
>
> return 0;
> }
>
>
> Both report on lost precision.
For me it reports "segmentation fault (core dumped)" (well, actually the
shell reports that, the program dies before it can report anything). c
is used without being initialized.
The problem in your C program is that you are rounding a to six
fractional digits. Of course the number isn't the same when you round
it.
You need at least 16 or 17 for the 53 bits of mantissa (log10(2**53) ==
15.95). If you replace sprintf(c,"%f",a); with sprintf(c,"%.15f",a); (2
digits before the decimal point, 15 after is 17 digits total), the
program reports "Okay".
You can do the same in Perl of course. The problem in Perl is that Perl
does conversions between numeric and string values automatically and the
programmer may not be aware of it - so he may lose precision without
noticing it. In C you explicitely have to use (s)printf, and you
hopefully do think about possible loss of precision there.
hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
------------------------------
Date: Sat, 28 Jul 2007 05:47:21 +0200
From: "Petr Vileta" <stoupa@practisoft.cz>
Subject: Re: Perl with DBI
Message-Id: <f8eeji$2kou$2@ns.felk.cvut.cz>
Jason wrote:
> # Create the Table
> $dbh->do("CREATE TABLE 'Test 3' ('date' VARCHAR(14) NOT NULL,
I'm not sure but maybe the ' is the reason. I use ` (backtick) or nothing.
In other word
$dbh->do("CREATE TABLE Test3 (date VARCHAR(14) NOT NULL,
or
$dbh->do("CREATE TABLE `Test3` (`date` VARCHAR(14) NOT NULL,
Now I see that table name contain space. Hmmm ... is this allowed? I'm using
MySQL 3.x and there spaces are not allowed in database/table name.
--
Petr Vileta, Czech republic
(My server rejects all messages from Yahoo and Hotmail. Send me your mail
from another non-spammer site please.)
------------------------------
Date: Sat, 28 Jul 2007 05:49:13 +0200
From: "Petr Vileta" <stoupa@practisoft.cz>
Subject: Re: Perl with DBI
Message-Id: <f8eejj$2kou$3@ns.felk.cvut.cz>
Jason wrote:
>
> But this leads me to my next question. I want `Test 3` to be a
> variable, but using
>
> $dbh->do("CREATE TABLE param('var') (`date` VARCHAR(14)...
>
> is giving that same generic error as above. I tried it both with and
> without the quotes, and tried using a variable instead ($var =
> param('var');), but still received the same error.
>
> Ideas?
>
Yes Sir :-)
$dbh->do("CREATE TABLE " . param('var') . " (`date` VARCHAR(14)...
--
Petr Vileta, Czech republic
(My server rejects all messages from Yahoo and Hotmail. Send me your mail
from another non-spammer site please.)
------------------------------
Date: Sat, 28 Jul 2007 01:27:36 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: pid from startet process
Message-Id: <slrnfakvrc.kkv.hjp-usenet2@zeno.hjp.at>
[I'm sorry, this posting grew too long and quite repetitive. But it's
rather late and I'm too lazy now to trim it down. So bear with me or
feel free to skip it]
On 2007-07-27 17:19, Douglas Wells <see@signature.invalid> wrote:
> In article <slrnfajk31.jjr.hjp-usenet2@zeno.hjp.at>, "Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
>> On 2007-07-26 22:57, Douglas Wells <see@signature.invalid> wrote:
>> > In article <slrnfahnt5.i1m.hjp-usenet2@zeno.hjp.at>,
>> > "Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
>> >> PIDs are guessable on the majority of unix systems (the only exceptions
>> >> I know are some BSD variants) - so this is something the average unix
>> >> programmer expects.
>> >
>> > Yes, elsewhere in this thread, I acknowledged that I made a wrong
>> > declaration about "most" POSIX-like system: Many of them do
>> > generate new candidates for PIDs by incrementing a counter. I
>> > have not, however, yielded on the claim of a security threat posed
>> > by this algorithm. Instead, I supplied a scenario, based on
>> > historical security incidents, that posed a threat in the presence
>> > of this algorithm.
>>
>> Yes. If you had yielded that claim I wouldn't have had any reason to
>> answer. But since you haven't, I had to object.
>
> And I still don't. You are describing a situation where an
> application programmer makes an erroneous assumption, and that
> assumption results in a security problem.
Same as you did. The assumption that a pid is unguessable is just as
erroneous, and it is very simple to refute on almost any Unix system. So
it is a problem that the average Unix programmer should be aware of and
he can take appropriate measures (which he still has to do even if his
system uses randomized pids: a) because he cannot rely on this feature
and b) because an attacker may still guess the pid because of its
limited range (typically 30k). So I stand by my claim that sequentially
allocated PIDs are not a "major security threat", and I would even guess
that randomized pids add very little security. (The grsecurity people
seem to agree - randomized PIDs were removed again)
>> The pid has traditionally always been a simple wrap-around counter. Any
>> unix programmer should know this.
>
> That depends on your definition of "traditionally." Yes, the
> standard code base from AT&T did this, and many of the derivative
> systems also did this. However, that is irrelevant, as it was not
> guaranteed by either the system specification or a published
> standard.
You are right that the standard doesn't specify this, and the printed
docs I still have for PC/IX (which are probably quite close to those of
Version 7 Unix) don't specify it either.
However, as you say, AT&T Unix did it this way and the vast majority of
derivatives and clones followed this example. This behaviour was also
documented in text books over and over (for example in Banahan and
Rutter: UNIX - the Book (1982), which happens to be the book I learned
Unix from together with the aforementioned PC/IX manpages 20 years ago).
So if a programmer finds some behaviour documented and all systems he
has access to behave that way, why should he suspect that his books are
wrong? (Because all textbooks contain errors and should not be used as
reference, you say, and you are of course entirely correct)
> (And, I know of systems at least as far back as 1982 that
> used non-sequential PIDs.).
I don't doubt this, although the first system I was aware of using that
feature was OpenBSD (since at least 1999). I do think that these systems
were rather obscure, though, and most unix programmers were not aware of
their existence.
> A programmer may know that this is the way that things often work, but
> he/she shouldn't depend on something that isn't *documented* as a
> permanent characteristic of the system.
Unfortunately, while it certainly wasn't documented in POSIX and
probably wasn't documented in any specific system documentations
(although it is quite possible that some unixes did document their pid
generation scheme), it *was* "documented" in lots of secondary
literature, and programmers would pick up the wrong assumption from
there.
>> Using it in a context where a random
>> number (much less a cryptographically strong random number) is required
>> is just using the wrong tool for the job. Such an error may lead to a
>> security problem, but that's the fault of the programmer, not the tool.
>> (In your scenario, the real error is probably not using O_EXCL, btw, not
>> using the pid, but that depends on the intended use).
>
> Yes, *one* underlying error was not using O_EXCL -- as I implied
> by my reference to O_EXCL in that post.
>
> As decoded in a parallel sub-thread, it would appear that a real
> problem underlying your concern was a dependence on a time delay
> before reuse of PIDs.
My "concern" is not that randomized pids are somehow worse than
sequential pids. My "concern" is your claim that sequential pids are a
major security threat and that all systems using it should be trashed.
I am pointing out that unix programmers know that pids can be guessed,
so this is not a major security threat.
I am further pointing out that unix programmers very often do not know
that sequential pids are not universal. So the slight advantage of
having pids which are slightly harder to guess is offset by behaviour
which is not expected by the programmer. Of course it's the programmer's
fault if he assumes that pids are assigned sequentially. But it is also
his fault if he creates a file in /tmp without using O_EXCL and checking
the the return value. I fail to see why one should be a "major security
threat of the system" and the other the programmer's fault. Failure to
deal correctly with sequential PIDs is just as much the programmer's
fault as failure to deal with randomized PIDs. In fact one could argue
that the former is more the programmers fault, since it is the usual
case.
>> Personally, I think it's a good thing that these applications were
>> broken, because it alerted the maintainers that the assumption
>> "timestamp + pid is unique" was faulty way before it became faulty on
>> systems on which it may have been possible to systematically exploit the
>> bug (IIRC all these applications used a one-second timestamp which is
>> now getting too short).
>>
>> I'm not saying that random pids are bad /per se/. But the average unix
>> programmer probably doesn't know that they exist so he cannot consider
>> their consequences.
>
> OK, and the way to deal with that is to teach those programmers
> how to write portable applications by not depending on accidental
> characteristics.
Right. Just as we have to teach programmers to use File::Temp for
temporary files (or use lower level functions properly). The
non-existence of "/tmp/$progname.$$" is an accidental characteristic
which a programmer must not rely on. Not for portable applications and
not even for non-portable ones.
>> (As an aside: Is the randomness of the pids on BSD systems
>> cryptographically strong? If not, a programmer might assume they are and
>> make the same error as a programmer who thinks that linearly incremented
>> pids are "non-predictable". If they are, how about other systems with
>> random pids?)
>
> I don't know about those particular systems, but often such algorithms
> are pluggable and can be replaced depending upon the security
> requirements of the deployed environment. Given that the rate of
> production of PIDs is slower, and the visibility of PIDs is lower
> than communication data, the tolerable level of strength would be
> lower.
My point here is that a programmer cannot rely on PIDs being
unguessable. A program which relies on unguessable PIDs is just as buggy
on a system with random PIDs as it is on a system with sequential PIDs.
A programmer may be lured into a false sense of security by apparently
random pids which aren't. Even if the pids on his system are strong
(lets for a moment assume that the system uses 64 bit numbers from a
sufficiently large entropy pool), the program may be ported to another
system which maybe uses only 15 bit numbers from a 32-bit linear
congruental PRNG, or, worse, to a system with sequential PIDs.
hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
------------------------------
Date: Fri, 27 Jul 2007 22:12:16 -0400 (EDT)
From: see@signature.invalid (Douglas Wells)
Subject: Re: pid from startet process
Message-Id: <f8e8m0$n2n$1@flame.contek.com>
In article <slrnfakvrc.kkv.hjp-usenet2@zeno.hjp.at>,
"Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
>
> [ ... ] The assumption that a pid is unguessable is just as
> erroneous, and it is very simple to refute on almost any Unix system. So
> it is a problem that the average Unix programmer should be aware of and
> he can take appropriate measures (which he still has to do even if his
> system uses randomized pids: a) because he cannot rely on this feature
> and b) because an attacker may still guess the pid because of its
> limited range (typically 30k). So I stand by my claim that sequentially
> allocated PIDs are not a "major security threat", and I would even guess
> that randomized pids add very little security. (The grsecurity people
> seem to agree - randomized PIDs were removed again)
Ahh, I see that you were reacting to the words "major security
threat." I don't see where you made that point explicitly in the
earlier messages, and I didn't understand that it was one of your
contention points. So, let me back off on the "major" adjective.
I over-reacted to the earlier proposal that a programmer should
depend on the PID generation algorithm of a particular system.
> You are right that the standard doesn't specify this, and the printed
> docs I still have for PC/IX (which are probably quite close to those of
> Version 7 Unix) don't specify it either.
>
> However, as you say, AT&T Unix did it this way and the vast majority of
> derivatives and clones followed this example. This behaviour was also
> documented in text books over and over (for example in Banahan and
> Rutter: UNIX - the Book (1982), which happens to be the book I learned
> Unix from together with the aforementioned PC/IX manpages 20 years ago).
> So if a programmer finds some behaviour documented and all systems he
> has access to behave that way, why should he suspect that his books are
> wrong? (Because all textbooks contain errors and should not be used as
> reference, you say, and you are of course entirely correct)
OK. I think that we are in agreement on that. It seems to be a
characteristic of many humans that it's easiest to learn from an
example. Unfortunately, it also seems to be a trait that we make
assumptions and improperly extrapolate the specific to the general.
I have found 4 books in my library that explain the creation of
PIDs (Lyons; Leffler, McKusick, et al.; Bach; and Tanenbaum). All
explain the use of an incrementing counter; none provide any
assurance that the algorithm in guaranteed. However, I can
understand how someone relatively new to UNIX would assume that
this was the only way. (I'll also that there are differences in
the algorithms and none quite matches the use in current systems
that I am familiar with.)
> My "concern" is not that randomized pids are somehow worse than
> sequential pids. My "concern" is your claim that sequential pids are a
> major security threat and that all systems using it should be trashed.
I have backed off on the particular claim of a "major threat. I
also noted in my earlier explanation that programs were no vulnerable
if they properly used O_EXCL in system calls, "no clobber" in the
shell, and mkstemp in programs.
> I am pointing out that unix programmers know that pids can be guessed,
> so this is not a major security threat.
Unfortunately, I have to disagree with this assertion. As an
exemplar, I will point out that the Perl documentation for "open"
contains the faulty construct, namely: open(EXTRACT, "|sort >Tmp$$")
(Granted this example doesn't necessarily put the file into a
shared directory, but it also doesn't warn about the situation.)
> Right. Just as we have to teach programmers to use File::Temp for
> temporary files (or use lower level functions properly). The
> non-existence of "/tmp/$progname.$$" is an accidental characteristic
> which a programmer must not rely on. Not for portable applications and
> not even for non-portable ones.
I have to agree with that.
> My point here is that a programmer cannot rely on PIDs being
> unguessable. A program which relies on unguessable PIDs is just as buggy
> on a system with random PIDs as it is on a system with sequential PIDs.
> A programmer may be lured into a false sense of security by apparently
> random pids which aren't. Even if the pids on his system are strong
> (lets for a moment assume that the system uses 64 bit numbers from a
> sufficiently large entropy pool), the program may be ported to another
> system which maybe uses only 15 bit numbers from a 32-bit linear
> congruental PRNG, or, worse, to a system with sequential PIDs.
I wasn't attempting to make that point, and, if fact, I was trying
to make the same point as you are here, so I think that we agree
on this.
> hp
So, let me try a refined assertion:
- The use of guessable PIDs leads to a higher level of security
threat on a system, most notably:
- in the presence of faulty programs that create files in
shared directories where the names depend on process ids.
- in certain aspects of high-assurance systems that we haven't
discussed here.
- dmw
--
. Douglas Wells . Connection Technologies .
. Internet: -sp9804- -at - contek.com- .
------------------------------
Date: 27 Jul 2007 21:02:46 GMT
From: Mark Pryor <tlviewer@VISTAyahoo.com>
Subject: Re: Problem installing DBI
Message-Id: <46aa5d76$0$30641$4c368faf@roadrunner.com>
On Fri, 27 Jul 2007 17:19:48 +0000, John Oliver wrote:
>>> Yes, I'm aware of all that.
>>>
>>> I'm trying to install RequestTracker. It's a frickin' nightmare. Since
>>> RT is in the Fedora Extras, I installed a host with FC7 and installed RT
>>> from yum. I can't get it to work. On the RT mailing list, they keep
>>> saying "We don't know why the RPM doesn't work, you have to install from
>>> source". So that's what I'm trying to do... but RT's dependency checker
>>> wants DBI installed via CPAN. There isn't much point with my arguing
>>> with why they want to do certain things certain ways... I'm just trying
>>> to do everything their way so hopefully at some point I can wind up with
>>> a working RT installation.
>>
>> C5 is based on FC6 sources. Might this be a better bet?
>> http://fedora.kanarip.com/fedora/extras/6/i386/rt3-3.6.3-1.fc6.noarch.rpm
>
> Yes, yes, yes...
>
> I have a FC7 installation with RT installed from Extras. It does not
> work. I am trying to install from source since the people on the RT
> list insist that that's the only way it will work. If you know how to
> make the RPM install of RT work, I'd be more than happy to do it that
> way. Otherwise, could I just find out why DBI won't install from CPAN?
> Please?
>
Good news. The above version, rt3-3.6xxxx.fc6.noarch.rpm will install with
the C5 Core version of perl-DBI. You can see by doing
#rpm -ivh --test rt3-3.6.3-1.fc6.noarch.rpm
__You should not need to get DBI from CPAN__
I was missing the dependency XML::Simple. When possible grab missing
modules from the CentOS repo. I did
#yum install perl-XML-Simple
after that rpm caught that and I had one less depen..
------------ rpm test of rt3 -------------
[root@centos tlviewer]# rpm -ivh --test rt3-3.6.3-1.fc6.noarch.rpm
warning: rt3-3.6.3-1.fc6.noarch.rpm: Header V3 DSA signature: NOKEY, key ID 1ac70ce6
error: Failed dependencies:
perl(Apache::Session) is needed by rt3-3.6.3-1.fc6.noarch
perl(Cache::Simple::TimedExpiry) is needed by rt3-3.6.3-1.fc6.noarch
perl(Calendar::Simple) is needed by rt3-3.6.3-1.fc6.noarch
perl(DBIx::SearchBuilder) is needed by rt3-3.6.3-1.fc6.noarch
perl(DBIx::SearchBuilder::Record::Cachable) is needed by rt3-3.6.3-1.fc6.noarch
perl(DBIx::SearchBuilder::Union) is needed by rt3-3.6.3-1.fc6.noarch
perl(DBIx::SearchBuilder::Unique) is needed by rt3-3.6.3-1.fc6.noarch
perl(Date::Format) is needed by rt3-3.6.3-1.fc6.noarch
perl(GD::Graph::bars) is needed by rt3-3.6.3-1.fc6.noarch
perl(GD::Graph::pie) is needed by rt3-3.6.3-1.fc6.noarch
perl(GD::Text) is needed by rt3-3.6.3-1.fc6.noarch
perl(HTML::FormatText) is needed by rt3-3.6.3-1.fc6.noarch
perl(HTML::Mason) is needed by rt3-3.6.3-1.fc6.noarch
perl(HTML::Scrubber) is needed by rt3-3.6.3-1.fc6.noarch
perl(HTML::TreeBuilder) is needed by rt3-3.6.3-1.fc6.noarch
perl(HTTP::Server::Simple::Mason) is needed by rt3-3.6.3-1.fc6.noarch
perl(Locale::Maketext::Fuzzy) is needed by rt3-3.6.3-1.fc6.noarch
perl(Locale::Maketext::Lexicon) >= 0.25 is needed by rt3-3.6.3-1.fc6.noarch
perl(Log::Dispatch) >= 1.6 is needed by rt3-3.6.3-1.fc6.noarch
perl(MIME::Entity) is needed by rt3-3.6.3-1.fc6.noarch
perl(MIME::Head) is needed by rt3-3.6.3-1.fc6.noarch
perl(MIME::Parser) is needed by rt3-3.6.3-1.fc6.noarch
perl(MIME::Words) is needed by rt3-3.6.3-1.fc6.noarch
perl(Mail::Address) is needed by rt3-3.6.3-1.fc6.noarch
perl(Mail::GnuPG) is needed by rt3-3.6.3-1.fc6.noarch
perl(Module::Versions::Report) is needed by rt3-3.6.3-1.fc6.noarch
perl(Regexp::Common) is needed by rt3-3.6.3-1.fc6.noarch
perl(Term::ReadKey) is needed by rt3-3.6.3-1.fc6.noarch
perl(Text::Template) is needed by rt3-3.6.3-1.fc6.noarch
perl(Text::Wrapper) is needed by rt3-3.6.3-1.fc6.noarch
perl(Time::ParseDate) is needed by rt3-3.6.3-1.fc6.noarch
perl(Tree::Simple) is needed by rt3-3.6.3-1.fc6.noarch
perl(UNIVERSAL::require) is needed by rt3-3.6.3-1.fc6.noarch
---------------- end snip ----------------
Its a mess but one might succeed in a reasonable amount of time.
--
Mark
------------------------------
Date: Fri, 27 Jul 2007 16:45:43 -0700
From: Klaus <klaus03@gmail.com>
Subject: Re: Reading from stdin then launching a program that reads from stdin strange behaviour
Message-Id: <1185579943.421103.232330@q75g2000hsh.googlegroups.com>
On Jul 27, 12:50 pm, Stefano Sabatini <stefano.sabatini-l...@poste.it>
wrote:
> I'm writing a perl script which reads from stdin, then launch an
> interactive session of gnuplot.
> open(FH, "/dev/stdin");
> # filter stdin
> while (<FH>) {
> ;}
>
> close(FH);
So far so good, but at this point, after closing FH, you should also
close STDIN:
close STDIN;
Now, before launching an interactive application, you want to re-open
STDIN:
open STDIN, '<&1' or die "Error open STDIN: $!";
> print "Launching gnuplot...\n";
> # and now launch a gnuplot interactive session
> system "gnuplot -";
--
Klaus
------------------------------
Date: Fri, 27 Jul 2007 22:47:36 GMT
From: "Mumia W." <paduille.4061.mumia.w+nospam@earthlink.net>
Subject: Re: Reading from stdin then launching a program that reads from stdin strange behaviour
Message-Id: <cCuqi.11509$rR.2233@newsread2.news.pas.earthlink.net>
On 07/27/2007 05:50 AM, Stefano Sabatini wrote:
> Hi all perlers,
>
> I'm writing a perl script which reads from stdin, then launch an
> interactive session of gnuplot. I'm on a gnu-linux system, perl 5.8.
>
> The simplified code looks like this:
>
> #! /usr/bin/perl
>
> # reads from stdin, then lauch interactively gnuplot
>
> open(FH, "/dev/stdin");
> # filter stdin
> while (<FH>) {
> ;
> }
> close(FH);
>
> print "Launching gnuplot...\n";
> # and now launch a gnuplot interactive session
> system "gnuplot -";
>
> If I feed the script with a file, like this:
> cat file.txt | perl gnuplot-launcher.pl
>
> gnuplot exits immediately from the interactive session.
>
> If I filter a regular file (like "file.txt") or type interactively on
> stdin like this:
> cat - | gnuplot-launcher.pl
> I'm writing
> interactively
> on
> stdin
> ^D
>
> then the gnuplot interactive mode seems to work.
>
> All I want to do is to be able to access to an interactive session of
> gnuplot from perl, but I'm evidently missing something.
>
> Many thanks in advance.
> Cheers.
You don't provide enough detail about what you're trying to do, but I
suspect that you can just use 'open' to launch gnuplot:
open (GNUPLOT, "|-", "gnuplot") or die("blah blah");
print GNUPLOT "plot blah blah blah...\n";
close GNUPLOT or die("blah blah");
Read up on the open command: perldoc -f open. If you need more
complicated interactions with gnuplot (not likely), you might consider
using Expect.pm.
------------------------------
Date: Fri, 27 Jul 2007 15:32:46 -0500
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: whether large hash might leak?
Message-Id: <46aa566e$0$503$815e3792@news.qwest.net>
Kimia wrote:
> hi, girls and dudes,
>
> ....I doubt whether hash might leak when it comprises of a large
> amount of pairs.
You could also try using uniq -with the -d -c options: man uniq
------------------------------
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.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
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 V11 Issue 694
**************************************
