[26078] in Perl-Users-Digest
Perl-Users Digest, Issue: 8279 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Jul 26 14:05:22 2005
Date: Tue, 26 Jul 2005 11:05:07 -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 Tue, 26 Jul 2005 Volume: 10 Number: 8279
Today's topics:
Re: Argument list too long (keep reading, it's not the (Anno Siegel)
Re: Argument list too long (keep reading, it's not the <pasdepub.Hugues.de-Mazancourt@lingway.com>
Re: Argument list too long (keep reading, it's not the (Anno Siegel)
baking cookies <dhxyz2010@yahoo.com>
calcule date <""alexjaquet\"@[no spam]msn.com">
Re: From number to clearer string <jgibson@mail.arc.nasa.gov>
kill 0 <bmetcalf@nortel.com>
Re: kill 0 xhoster@gmail.com
Re: kill 0 <bmetcalf@nortel.com>
Re: kill 0 <jgibson@mail.arc.nasa.gov>
Re: kill 0 <bmetcalf@nortel.com>
Re: Linux distribs lacking perldoc axel@white-eagle.invalid.uk
OT: Social responsibility when writing HTML <spam-block-@-SEE-MY-SIG.com>
pattern match <mail@nomail.no.com>
Re: pattern match <jurgenex@hotmail.com>
Re: trouble with Archive::Tar : Can not read compressed <Paul.Marquess@btinternet.com>
Re: trouble with Archive::Tar : Can not read compressed <REMOVEMEbguyon1@gfi.frREMOVEME>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 26 Jul 2005 12:01:39 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Argument list too long (keep reading, it's not the FAQ)
Message-Id: <dc58n3$4d2$1@mamenchi.zrz.TU-Berlin.DE>
Hugues de Mazancourt <pasdepub.Hugues.de-Mazancourt@lingway.com> wrote in comp.lang.perl.misc:
> > Are you sure your commands aren't collecting some garbage that adds to
> > their length without changing their function?
>
> As I log the commands (see below), I can check that there is no garbage
> collected among usage
> >
> > Show a minimal code example that exhibits the problem.
>
> Here is - roughly - how my code behaves. The "else" part is taken verbatim
> from my source (with some repeatingly code removed). I fork, then prepare
> wget's argument and start crawling. It runs every night, with the same data
> in $source (which is a loaded from a record in MySQL).
>
> $pid=fork();
> if($pid)
> {
> push(@pids_to_wait4, $pid);
> }
> else
> {
> my $wget=$self->{wgetpath}?$self->{wgetpath}."/":"";
> $wget.="wget -r --timestamping";
> $wget.=" --level=".$source->intval('level') if($source->param('level'));
> $wget.=" --span-hosts" if($source->true('spanhosts'));
> $wget.=" --domains=".$source->param('domains')
> if($source->true('spanhosts') && $source->param('domains'));
> $wget.=" --quota=".$source->param('quota') if($source->param('quota'));
> $wget.=" --wait=1 --random-wait" if($source->true('randomwait'));
> $wget.=" --no-parent" if($source->true('noparent'));
> # ... several lines removed, all looking like
> $wget.="--option=".$source->param('option') if($source->param('option'));
> my $wgetdir=$self->{srcdir};
> $wget.=" --directory-prefix=$wgetdir";
> my $wgetlog=$self->my_tmpfile($source->name(), '.wgetlog');
> $wget.=" -nv --html-extension --output-file=$wgetlog";
> $wget.=" --cookies=on --load-cookies=".$source->param('cookiefile')
> if($source->param('cookiefile'));
> $wget.=" \"".$source->param('url')."\"";
> $self->logger()->message("Crawler", "Starting WGET: $wget");
> system($wget); # And here, sometimes (...) I get "Argument list too
> long"
> }
It would be interesting to see samples of the actual wget-commands.
Since "system( $wget)" calls a shell to expand the command, shell
metacharacters ( "*", "{...}", others) may render the actual command
longer than it appears to be.
Anno
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
------------------------------
Date: Tue, 26 Jul 2005 15:14:52 +0200
From: "Hugues de Mazancourt" <pasdepub.Hugues.de-Mazancourt@lingway.com>
Subject: Re: Argument list too long (keep reading, it's not the FAQ)
Message-Id: <dc5d8q$1uj$1@s1.news.oleane.net>
> It would be interesting to see samples of the actual wget-commands.
> Since "system( $wget)" calls a shell to expand the command, shell
> metacharacters ( "*", "{...}", others) may render the actual command
> longer than it appears to be.
Here you are:
Starting WGET:
/usr/bin/wget -r --timestamping --level=20 --no-parent --reject=.gif,.jpg,.z
ip --directory-prefix=/usr/local/lingway/lkm/UI/Data/cg06/src -nv --html-ext
ension --output-file=/usr/local/lingway/lkm/UI/Data/cg06/work/Agriculture307
60k2zZHI.wgetlog "http://www.cg06.fr/agriculture/agriculture.html"
Starting WGET:
/usr/bin/wget -r --timestamping --level=50 --no-parent --reject=.gif,.jpg,.z
ip --directory-prefix=/usr/local/lingway/lkm/UI/Data/cg06/src -nv --html-ext
ension --output-file=/usr/local/lingway/lkm/UI/Data/cg06/work/Economie316806
iPtae.wgetlog "http://www.cg06.fr/economie/economie.html"
Starting WGET:
/usr/bin/wget -r --timestamping --level=50 --no-parent --reject=.gif,.jpg,.z
ip --directory-prefix=/usr/local/lingway/lkm/UI/Data/cg06/src -nv --html-ext
ension --output-file=/usr/local/lingway/lkm/UI/Data/cg06/work/Environnement3
16986iPtae.wgetlog "http://www.cg06.fr/environnement/environnement.html"
Starting WGET:
/usr/bin/wget -r --timestamping --level=20 --no-parent --reject=.gif,.jpg,.z
ip --directory-prefix=/usr/local/lingway/lkm/UI/Data/cg06/src -nv --html-ext
ension --output-file=/usr/local/lingway/lkm/UI/Data/cg06/work/Agriculture203
58jof3Ug.wgetlog "http://www.cg06.fr/agriculture/agriculture.html"
Starting WGET:
/usr/bin/wget -r --timestamping --level=20 --no-parent --reject=.gif,.jpg,.z
ip --directory-prefix=/usr/local/lingway/lkm/UI/Data/cg06/src -nv --html-ext
ension --output-file=/usr/local/lingway/lkm/UI/Data/cg06/work/Agriculture240
42JlLJ2Y.wgetlog "http://www.cg06.fr/agriculture/agriculture.html"
The different lines with "Agriculture" show (at least me!) that the system
retried several times to download. The successfull one (the last one) was
after restarting the script.
I'm quite sure that the problem has nothing to do with the command line
itself. What I can suspect is the multplication of fork/system in the script
or interference with DBI::MySQL (connexions left open? dunno)
Hugues
------------------------------
Date: 26 Jul 2005 13:46:50 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Argument list too long (keep reading, it's not the FAQ)
Message-Id: <dc5esa$8rp$1@mamenchi.zrz.TU-Berlin.DE>
Hugues de Mazancourt <pasdepub.Hugues.de-Mazancourt@lingway.com> wrote in comp.lang.perl.misc:
> > It would be interesting to see samples of the actual wget-commands.
> > Since "system( $wget)" calls a shell to expand the command, shell
> > metacharacters ( "*", "{...}", others) may render the actual command
> > longer than it appears to be.
>
> Here you are:
> Starting WGET:
> /usr/bin/wget -r --timestamping --level=20 --no-parent --reject=.gif,.jpg,.z
> ip --directory-prefix=/usr/local/lingway/lkm/UI/Data/cg06/src -nv --html-ext
> ension --output-file=/usr/local/lingway/lkm/UI/Data/cg06/work/Agriculture307
> 60k2zZHI.wgetlog "http://www.cg06.fr/agriculture/agriculture.html"
>
> Starting WGET:
> /usr/bin/wget -r --timestamping --level=50 --no-parent --reject=.gif,.jpg,.z
> ip --directory-prefix=/usr/local/lingway/lkm/UI/Data/cg06/src -nv --html-ext
> ension --output-file=/usr/local/lingway/lkm/UI/Data/cg06/work/Economie316806
> iPtae.wgetlog "http://www.cg06.fr/economie/economie.html"
[more like that]
No metacharacters (except ") that I could see -- so much about that
theory.
None of these commands should raise "Argument list too long". Standard
limits allow several kB at least, usually much more. It looks more
like an OS problem but a Perl problem to me.
I don't see ho we can help more without being able to reproduce the
problem. Pare it down until it's a self-contained script (that doesn't
depend on /usr/local being configured in a particular way). If the
process doesn't lead to a solution (it often does), post the script and
we shall see.
Anno
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
------------------------------
Date: Tue, 26 Jul 2005 15:47:56 GMT
From: "Dean A. Hoover" <dhxyz2010@yahoo.com>
Subject: baking cookies
Message-Id: <MWsFe.177051$g5.71653@twister.nyroc.rr.com>
In CGI.pm there is a function for making a cookie
from a scalar, hash, or array. It apparentley does
not support lists of lists, hashes of lists, etc.
Is there existing code that will do that?
Thanks.
Dean
------------------------------
Date: Tue, 26 Jul 2005 15:58:27 +0200
From: Alexandre Jaquet <""alexjaquet\"@[no spam]msn.com">
Subject: calcule date
Message-Id: <42e64185$0$1152$5402220f@news.sunrise.ch>
Hi I need to determine the a date based on calculation
exemple I want to return what's the date when adding
n day to an another date
2005-07-26 15:47:56
+ 31 day = ?
------------------------------
Date: Tue, 26 Jul 2005 09:34:12 -0700
From: Jim Gibson <jgibson@mail.arc.nasa.gov>
Subject: Re: From number to clearer string
Message-Id: <260720050934121399%jgibson@mail.arc.nasa.gov>
In article <pan.2005.07.25.19.18.43.119862@users.sourceforge.net>, *
Tong * <sun_tong@users.sourceforge.net> wrote:
> Hi,
>
> Is any Perl modules that can translate number like 10987654321 into
> clearer to read string 10,987,654,321? and back?
>
> I don't know what this kind of transformation called, so I don't know how
> to search. thanks.
This is a Frequently Asked Question, and the answer may be found with:
perldoc -q commas
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= East/West-Coast Server Farms - Total Privacy via Encryption =---
------------------------------
Date: Tue, 26 Jul 2005 15:17:03 +0000 (UTC)
From: Brandon Metcalf <bmetcalf@nortel.com>
Subject: kill 0
Message-Id: <slrndechqp.6bh.bmetcalf@cash.rhiamet.com>
I'm seeing a behavior with using "kill 0,$pid" to determine if a
process is running that I didn't expect. It seems that only root can
correctly get the status on processes that root or another user that
is different from the one calling kill() owns. For example,
$ whoami
bmetcalf
$ ps -ef|grep gdm
root 965 1 0 Jul19 ? 00:00:00 /usr/bin/gdm
root 978 965 0 Jul19 ? 00:00:00 /usr/bin/gdm
root 979 978 0 Jul19 ? 00:37:20 /usr/X11R6/bin/X :0 -deferglyphs 16 -nolisten tcp -audit 0 -auth /var/lib/gdm/:0.Xauth -nolisten tcp vt7
bmetcalf 24443 23845 0 09:19 pts/5 00:00:00 grep gdm
$ perl -le '$a = kill 0,965;print $a'
0
$ su
Password:
# perl -le '$a = kill 0,965;print $a'
1
Is this the expected behavior? I'm sure it is since every platform
and version of Perl I've tried behave the same way.
--
Brandon
------------------------------
Date: 26 Jul 2005 15:34:48 GMT
From: xhoster@gmail.com
Subject: Re: kill 0
Message-Id: <20050726113448.218$FQ@newsreader.com>
Brandon Metcalf <bmetcalf@nortel.com> wrote:
> I'm seeing a behavior with using "kill 0,$pid" to determine if a
> process is running that I didn't expect. It seems that only root can
> correctly get the status on processes that root or another user that
> is different from the one calling kill() owns. For example,
>
...
>
> Is this the expected behavior? I'm sure it is since every platform
> and version of Perl I've tried behave the same way.
Given the docs for kill, it is the behavior I would expect (** mine):
If SIGNAL is zero, no signal is sent to the process. This
is a useful way to check that the process is alive and
**hasn't changed its UID.** See perlport for notes on the
portability of this construct.
And by all means, do see perlport.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Tue, 26 Jul 2005 16:25:01 +0000 (UTC)
From: Brandon Metcalf <bmetcalf@nortel.com>
Subject: Re: kill 0
Message-Id: <slrndecoss.6bh.bmetcalf@cash.rhiamet.com>
On 2005-07-26, xhoster@gmail.com <xhoster@gmail.com> wrote:
> Brandon Metcalf <bmetcalf@nortel.com> wrote:
>> I'm seeing a behavior with using "kill 0,$pid" to determine if a
>> process is running that I didn't expect. It seems that only root can
>> correctly get the status on processes that root or another user that
>> is different from the one calling kill() owns. For example,
>>
> ...
>>
>> Is this the expected behavior? I'm sure it is since every platform
>> and version of Perl I've tried behave the same way.
>
> Given the docs for kill, it is the behavior I would expect (** mine):
>
> If SIGNAL is zero, no signal is sent to the process. This
> is a useful way to check that the process is alive and
> **hasn't changed its UID.** See perlport for notes on the
> portability of this construct.
>
> And by all means, do see perlport.
Sure, I looked at perlport but didn't see anything that explained what
I'm seeing. Also, I don't see anything in the documentation for
kill() what would explain this behavior. You highlighted "hasn't
changed its UID", but I don't understand what that has to do with the
problem.
--
Brandon
------------------------------
Date: Tue, 26 Jul 2005 09:37:02 -0700
From: Jim Gibson <jgibson@mail.arc.nasa.gov>
Subject: Re: kill 0
Message-Id: <260720050937021572%jgibson@mail.arc.nasa.gov>
In article <20050726113448.218$FQ@newsreader.com>, <xhoster@gmail.com>
wrote:
> Brandon Metcalf <bmetcalf@nortel.com> wrote:
> > I'm seeing a behavior with using "kill 0,$pid" to determine if a
> > process is running that I didn't expect. It seems that only root can
> > correctly get the status on processes that root or another user that
> > is different from the one calling kill() owns. For example,
> >
> ...
> >
> > Is this the expected behavior? I'm sure it is since every platform
> > and version of Perl I've tried behave the same way.
>
> Given the docs for kill, it is the behavior I would expect (** mine):
>
> If SIGNAL is zero, no signal is sent to the process. This
> is a useful way to check that the process is alive and
> **hasn't changed its UID.** See perlport for notes on the
> portability of this construct.
And from the 'man kill' page:
"Only the super-user may send signals to other users' processes."
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= East/West-Coast Server Farms - Total Privacy via Encryption =---
------------------------------
Date: Tue, 26 Jul 2005 17:17:03 +0000 (UTC)
From: Brandon Metcalf <bmetcalf@nortel.com>
Subject: Re: kill 0
Message-Id: <slrndecqqp.6bh.bmetcalf@cash.rhiamet.com>
On 2005-07-26, Brandon Metcalf <bmetcalf@nortel.com> wrote:
> On 2005-07-26, xhoster@gmail.com <xhoster@gmail.com> wrote:
>> Brandon Metcalf <bmetcalf@nortel.com> wrote:
>>> I'm seeing a behavior with using "kill 0,$pid" to determine if a
>>> process is running that I didn't expect. It seems that only root can
>>> correctly get the status on processes that root or another user that
>>> is different from the one calling kill() owns. For example,
>>>
>> ...
>>>
>>> Is this the expected behavior? I'm sure it is since every platform
>>> and version of Perl I've tried behave the same way.
>>
>> Given the docs for kill, it is the behavior I would expect (** mine):
>>
>> If SIGNAL is zero, no signal is sent to the process. This
>> is a useful way to check that the process is alive and
>> **hasn't changed its UID.** See perlport for notes on the
>> portability of this construct.
>>
>> And by all means, do see perlport.
>
> Sure, I looked at perlport but didn't see anything that explained what
> I'm seeing. Also, I don't see anything in the documentation for
> kill() what would explain this behavior. You highlighted "hasn't
> changed its UID", but I don't understand what that has to do with the
> problem.
OK. This explains it:
$ ps -ef|grep gdm
root 965 1 0 Jul19 ? 00:00:00 /usr/bin/gdm
root 978 965 0 Jul19 ? 00:00:00 /usr/bin/gdm
root 979 978 0 Jul19 ? 00:40:01 /usr/X11R6/bin/X :0 -deferglyphs 16 -nolisten tcp -audit 0 -auth /var/lib/gdm/:0.Xauth -nolisten tcp vt7
bmetcalf 25710 25677 0 11:45 pts/13 00:00:00 grep gdm
$ perl -le 'kill 0,965 or print $!'
Operation not permitted
So, one has to have permission to actually send a signal 0.
--
Brandon
------------------------------
Date: Tue, 26 Jul 2005 12:10:09 GMT
From: axel@white-eagle.invalid.uk
Subject: Re: Linux distribs lacking perldoc
Message-Id: <BKpFe.18129$dN6.17423@fe1.news.blueyonder.co.uk>
gargoyle <gargoyle@no.spam> wrote:
> FWIW, OpenBSD ships with a complete Perl environment in the base system.
> Despite that, it's a very minimalist system, which tries to remain true
> to its Unix roots. You may wish to give it a shot. If you know Linux,
> making the jump is a piece of cake. And the man pages are most
> excellent, much better than anything I've seen elsewhere. It's a really
> friendly environment for developpers and sysadmins.
Thanks. I'll probably do that if and when I get a new machine,
unless I can convert an old laptop that I have sitting around. I
like the look of BSD in general but have not had much chance to
use it (except for the variant shipped with MAC OS X). It reminds
me very much of SunOS before Solaris.
> Incidentally the package system has just recently been overhauled and
> now the tools are written in Perl instead of C. More info here:
> http://mongers.org/openbsd/interview-espie-ports
> After using Linux (slackware then debian) for nearly a decade, I
> switched to OpenBSD and found it a dream to deal with. No way I'll ever
> go back. The only thing I find myself wishing for is that CPAN get
> integraged with the packages/ports system, so that you could install
> Perl modules in either of 3 ways and have version tracking, dependancies,
> etc. be resolved correctly. Then I will have reached nirvana. ;-)
Actually I think I will have a bash with that laptop later today.
Axel
------------------------------
Date: Tue, 26 Jul 2005 17:33:46 +0100
From: James Taylor <spam-block-@-SEE-MY-SIG.com>
Subject: OT: Social responsibility when writing HTML
Message-Id: <ant2616467d6fNdQ@riscpc.jtnet>
Warning: This thread is seriously off-topic now.
In fact, I'll change the subject to reflect this.
In article <slrndeat4j.7fo.abigail@alexandra.abigail.nl>,
Abigail <abigail@abigail.nl> wrote:
>
> Furthermore, I cannot imagine a "good, anticiapting programmer"
> writing < instead of '<' inside quotes for the "difficulties"
> someone might have parsing HTML, and then leaving off the quotes.
Perhaps, but the parser has to cope with HTML from both experts
*and* amateurs. To cope with missing quotes from amateurs,
it might choose to treat the first > as the tag terminator
then look to see if it can make sense of the tag contents.
It occurs to me that you may be confusing this hypothetical
parser with one that I would write, but that's not my point.
You may also be confusing the poor HTML that the parser is
trying to defend against as something I might write, but
that isn't my point either.
My point is that anyone writing HTML for public consumption
must be mindful of the fact that it will be interpreted by
all manner of parsers; some good, some bad, some good but old,
some new but poor, and some that for pragmatic reasons are
operating in quirks mode to defend against poor HTML. So,
as long as the HTML author doesn't produce invalid HTML,
they should make sensible choices to guard against likely
faults in HTML parsers (unless they don't give a damn about
the web in the first place, of course).
In article <slrndeathe.7fo.abigail@alexandra.abigail.nl>,
Abigail <abigail@abigail.nl> wrote:
>
> I really hate that attitude. Instead of blaming the people
> writing buggy browsers, or other bad parsers, you blame the
> people writing HTML!
That's because web developers should know better and anyway
can make corrections easily, whereas on many minority
computing platforms there is no choice of web browser. The
user has to use what's available, or write their own which
is usually not practical or even possible.
Given that the standards allow a free choice of whether to
write angle brackets in attribute values either raw or as
character entities, it doesn't make sense to mindlessly
choose the technique that will cause *more* problems rather
than less for those receiving your HTML. This is just one
example of where a socially conscious choice can improve the
web for everyone. There are plenty of other areas where
careful selection of the correct technique can make a big
difference to accessibility and usability, but it requires
the HTML author to have reasonable clue about the chronology
of the introduction of new technologies, how widespread
support for them is, and how well older browsers degrade.
Which of the following techniques would *you* choose:
1. Encode smart quotes as:
a) unicode entities like ’ etc.
b) Windows codepage 1252 entities ’
c) convert them to ascii ' and "
2. Site navigation:
a) superkewl Flash app the user has to learn first
b) javascripted rollover images with no alt text
c) static images with alt text and plain href links
d) normal textual links
3. Links that you want the user to open in another window:
a) using a javascript: scheme so you can position the
window and strip it of the normal controls
b) using <a href="whatever" target="_blank">
c) normal href links so the user can make their
own choice about whether they want a new window
4. Glossy company branding to impress people:
a) a Flash splash page with wizzy animations (after all nobody
still uses dial-up, and who wants to get indexed anyway)
b) an animated GIF that constantly draws the eye
c) a static image of the company logo in one corner
5. Named anchors within a page:
a) use <div id="name"> and to hell with older browsers
b) use <a name="name"> which works everywhere
6. Headings, subheadings, and bold:
a) use <div class="head">, <div class="subhead">
and <span class="emphasis">
b) use <h1 class="head">, <h2 class="head">
and <b class="emphasis">
7. Multimap.com style application where the positional
relationship between page elements is important:
a) use positional CSS for everything
b) use HTML tables
8. An HTML form:
a) with a javascript button to submit it
b) with a real submit button
I could probably go on to fill a book with a list of these
sort of choices, but then I'm an experienced web developer
with sufficient clue. The vast majority of kiddie web
deeziners out there would be completely oblivious to the
existence of a choice, and anyway would pick (a) from every
selection just because it's the newest wizzy technology that
gives them the maximum scope for creativity, "so it *has* to
be the right choice doesn't it". It would never even occur
to them that using minimal new technology to achieve their
goals is better than using the maximally new and fragile
technique. Such deeziners have little understanding of what
they're doing (beyond the use of whatever wysiwyg editor
they're using) and they care even less about social niceties,
such as ensuring accessibility to the widest audience,
keeping their HTML and graphics small, neat and efficient
for the benefit dial-up modem users, web caches, etc, or
allowing people to view the site on any browser, at any font
size, or in any window size. They don't care about allowing
people (or bots) to automatically crawl and scrape the site,
in fact they probably think that's a *bad* thing and would
prefer everyone to enter their site only from the front page
so they can throw the right combination of popup advertising
at the hapless suckers!
Not only does the appallingly fragile construction of most
websites reduce the general quality of the web, but it also
imposes a pressure of extinction on minority browsers and
platforms that don't have sufficient market share and
financial muscle to keep up with the grubby complexity that
results from this. Furthermore, it raises the barrier for
entry to anyone wishing to write their own browser, crawler,
or other web client. Despite being a competent Linux user
and fan, I still do the majority of my work on an alternative
platform (RISC OS) because its GUI usability *completely*
outclasses anything available on Linux. (Of course, I have
it networked to my Linux box for the best of both worlds.)
Alternative platforms have much to offer and, just as we
should look after the bio-diversity of the rainforest, we
should avoid needlessly killing off computing platforms in a
mindless lust for the latest kewl thing, otherwise we'll
look back and wonder why we didn't see it coming when some
megacorp owns the world and there are no freedoms left.
So you see, you might think it's a small thing, but when I
see someone advocating the use of fragile markup (needlessly)
in the full knowledge that some browsers won't cope with it
and suggesting that browsers should just get fixed and
upgraded, I hope you now see why I oppose this socially
harmful and myopic attitude as a matter of utmost principle.
--
James Taylor, London, UK PGP key: 3FBE1BF9
To protect against spam, the address in the "From:" header is not valid.
In any case, you should reply to the group so that everyone can benefit.
If you must send me a private email, use james at oakseed demon co uk.
------------------------------
Date: Tue, 26 Jul 2005 15:42:18 +0100
From: Geezer From The Freezer <mail@nomail.no.com>
Subject: pattern match
Message-Id: <42E64BCA.BC0BF561@nomail.no.com>
@a contains:-
abcdefg1234
1234 this is a test
test
test 1234
I want to print everything with 1234 so:-
$list = @a =~ /1234/ ;
chomp($list);
print ($list);
Why doesn't this work? :(
Be grateful if someone can point me in the right direction.
------------------------------
Date: Tue, 26 Jul 2005 15:28:26 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: pattern match
Message-Id: <uEsFe.3227$Eo3.376@trnddc08>
Geezer From The Freezer wrote:
> @a contains:-
>
> abcdefg1234
> 1234 this is a test
> test
> test 1234
>
> I want to print everything with 1234 so:-
>
>
>
> $list = @a =~ /1234/ ;
> chomp($list);
> print ($list);
>
> Why doesn't this work? :(
"it doesn't work" is about the worst possible description of a problem.
What _does_ it do? Print something you didn't expect? Fail with an error
message? Hang in a loop? ...?
Well, at least you sort of told us what you did expect.
If you would have "use warnings;" then perl would have told you already what
is probably wrong (see output of warnings enabled).
Another hint can be found in the man page for m// (perldoc perlop, section
Regexp Quote-Like Operators):
If the "/g" option is not used, "m//" in list context returns a
list consisting of the subexpressions matched by the parentheses
in the pattern, i.e., ("$1", "$2", "$3"...). [...]
I don't see any capturing parathesis in your code.
When there are no parentheses in the pattern, the
return value is the list "(1)" for success.
Well, guess that's not what you are looking for, either. Seems like m// is
the wrong tool for the job.
> Be grateful if someone can point me in the right direction.
From your description it seems you are looking for a plain old grep()?
jue
------------------------------
Date: Tue, 26 Jul 2005 11:37:19 +0100
From: "Paul Marquess" <Paul.Marquess@btinternet.com>
Subject: Re: trouble with Archive::Tar : Can not read compressed format in tar-mode
Message-Id: <42e61261$0$6482$ed9e5944@reading.news.pipex.net>
Archive::Tar can optionally make use of IO::Zlib to access compressed tar
files that have been compressed with gzip. The problem is your tar file has
been compressed with something different, namely the Unix compress program.
Try opening Archive::Tar like this
my $arch_name_tar_Z = 'myfile.tar.Z';
open F, "uncompress -c $arch_name_tar_Z |";
my $tar = Archive::Tar->new(*F);
Paul
"benoit Guyon" <REMOVEMEbguyon1@gfi.frREMOVEME> wrote in message
news:dc4tta$u5k$1@news1.completel.net...
> hello,
>
> i have a problem when reading a tar.Z file :
>
> the code is :
>
> # ----------------------------------------------------
> #!/usr/local/bin/perl -w
>
> use strict;
> use warnings;
> use Archive::Tar;
>
> my $arch_name_tar_Z = 'myfile.tar.Z';
>
> my $tar = Archive::Tar->new;
> $tar->read($arch_name_tar_Z, 1)
> or die("*** ERROR read Archive::Tar: $!");
> # ----------------------------------------------------
>
> and the error is :
> Can not read compressed format in tar-mode
>
> i tried the commands :
> tar -xzvf myfile.tar.Z -> OK (i get valid files)
> uncompress myfile.tar.Z -> OK (i get a valid myfile.tar file)
> gunzip myfile.tar.Z -> OK (i get a valid myfile.tar file)
>
> i checked the code in Tar.pm, and found
>
> unless( $read++ ) {
> my $gzip = GZIP_MAGIC_NUM;
> if( $chunk =~ /$gzip/ ) {
> $self->_error( qq[Can not read compressed format in tar-mode] );
> return;
> }
> }
>
> is my archive compressed with an exotic compressor ? why can the batch
> tar command successfully do the job ?
>
> does somebody have an idea to help me ?
>
> best regards
>
> benoit
>
> PS : i tried to build a IO::Zlib Handle on the file (success) and then
> to pass it to the Archive::Tar->read function, but i get the same error
> message.
>
> PS 2 : Archive::Tar->can_handle_compressed_files gives true
------------------------------
Date: Tue, 26 Jul 2005 15:53:55 +0200
From: benoit Guyon <REMOVEMEbguyon1@gfi.frREMOVEME>
Subject: Re: trouble with Archive::Tar : Can not read compressed format in tar-mode
Message-Id: <dc5fek$d7$1@news1.completel.net>
thank you for the response
i used that code to correct my problem :
qx{gunzip $arch_name_tar_z};
and then sent the new file to Archive::Tar (with success)
oddly, the archive must have been compressed with "compress", but gunzip
does the job well
Benoit
Paul Marquess a écrit :
> Archive::Tar can optionally make use of IO::Zlib to access compressed tar
> files that have been compressed with gzip. The problem is your tar file has
> been compressed with something different, namely the Unix compress program.
>
> Try opening Archive::Tar like this
>
> my $arch_name_tar_Z = 'myfile.tar.Z';
> open F, "uncompress -c $arch_name_tar_Z |";
> my $tar = Archive::Tar->new(*F);
>
> Paul
>
> "benoit Guyon" <REMOVEMEbguyon1@gfi.frREMOVEME> wrote in message
> news:dc4tta$u5k$1@news1.completel.net...
>
>>hello,
>>
>>i have a problem when reading a tar.Z file :
>>
>>the code is :
>>
>># ----------------------------------------------------
>>#!/usr/local/bin/perl -w
>>
>>use strict;
>>use warnings;
>>use Archive::Tar;
>>
>>my $arch_name_tar_Z = 'myfile.tar.Z';
>>
>>my $tar = Archive::Tar->new;
>>$tar->read($arch_name_tar_Z, 1)
>> or die("*** ERROR read Archive::Tar: $!");
>># ----------------------------------------------------
>>
>>and the error is :
>>Can not read compressed format in tar-mode
>>
>>i tried the commands :
>>tar -xzvf myfile.tar.Z -> OK (i get valid files)
>>uncompress myfile.tar.Z -> OK (i get a valid myfile.tar file)
>>gunzip myfile.tar.Z -> OK (i get a valid myfile.tar file)
>>
>>i checked the code in Tar.pm, and found
>>
>>unless( $read++ ) {
>> my $gzip = GZIP_MAGIC_NUM;
>> if( $chunk =~ /$gzip/ ) {
>> $self->_error( qq[Can not read compressed format in tar-mode] );
>> return;
>> }
>>}
>>
>>is my archive compressed with an exotic compressor ? why can the batch
>>tar command successfully do the job ?
>>
>>does somebody have an idea to help me ?
>>
>>best regards
>>
>>benoit
>>
>>PS : i tried to build a IO::Zlib Handle on the file (success) and then
>>to pass it to the Archive::Tar->read function, but i get the same error
>>message.
>>
>>PS 2 : Archive::Tar->can_handle_compressed_files gives true
>
>
>
------------------------------
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 V10 Issue 8279
***************************************
