Re: [perl #46463] filetests sometimes do not set _ On Wed, Oct 17, 2007 at 10:22:58AM +0200, Mark Overmeer wrote: > Hum... the error report was even more right than I expected it to be... > After a long bug-hunt, I figured out that it is not '-w' itself which > is misbehaving (the file test flags), but it is the module 'filetest'. >  > The following script reports 'directory' twice: >  >    #!/usr/local/bin/perl5.10.0 >    use filetest 'access'; >  >    -d '/etc'; >    -w '/etc/passwd'; >    warn -f _ ? "file\\n" : "directory\\n"; >    warn -d _ ? "directory\\n" : "file\\n"; >  > Apparently, -r/-w/-x/-R/-W/-X implemented in filetest to not > set '_' anymore, where they did so in perl5.8.8 On Fri, Oct 19, 2007 at 02:20:26AM +0200, Andreas J. Koenig wrote: >     Change 19392 by gbl@kosh on 2003/05/03 05:33:04 >  >         Salvage 'use filetest "access"' from compiletime to runtime. It seems that Jarkko actually fixed a bug here - I'd infer that access() wasn't being called when it was expected that it would be. I don't believe that the current behaviour is a behavioural bug. The documentation could be clearer, however. It is documented that _ is set to the last stat. It is documented that under filetest, -r/-w/-x/-R/-W/-X use access() rather than the mode bits from the file. Hence one does not need to call stat(), so perl does not. *That* implementation efficiency is not documented. So I think that the current behaviour is preferable. If we changed it so that -r/-w/-x/-R/-W/-X also call stat() as well as access(), then we give everyone inefficiency that they can't avoid. Whereas the current behaviour is merely caveat emptor on anyone wishing to take advantage of the _ filehandle. I'm curious - on a modern Unix system with decent OS caching, how much does not calling stat again really save? Nicholas Clark Return-Path:  X-Original-To: jl@localhost Delivered-To: user7@gvc.ceas-challenge.cc Received: from radish.jmason.org (localhost [127.0.0.1]) 	by radish.jmason.org (Postfix) with ESMTP id 2E07B33917 	for ; Mon, 22 Oct 2007 01:51:57 +0100 (IST) X-Spam-Virus: No X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on 	soman.fdntech.com X-Spam-Relays-External: [ ip=70.85.31.216 rdns=node.waugh.id.au 	helo=node.waugh.id.au by=soman.fdntech.com ident= envfrom= intl=0 	id=1C16D2695B0 auth= msa=0 ] [ ip=127.0.0.1 rdns=localhost.localdomain 	helo=node.waugh.id.au by=node.waugh.id.au ident= envfrom= intl=0 	id=05F173C854 auth= msa=0 ] [ ip=67.19.173.84 rdns=vanadium.sabren.com 	helo=vanadium.sabren.com by=node.waugh.id.au ident= envfrom= intl=0 	id=919D73C595 auth= msa=0 ] [ ip=75.182.87.110 	rdns=cpe-075-182-087-110.nc.res.rr.com helo=!192.168.1.104! 	by=vanadium.sabren.com ident= envfrom= intl=0 id=l9M0iCXW018735 auth=Sendmail 	msa=0 ] X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_POLICY_SIGNSOME 	shortcircuit=no autolearn=ham version=3.3.0-r574664 X-Spam-Relays-Internal:  X-Spam-Relays-Untrusted: [ ip=70.85.31.216 rdns=node.waugh.id.au 	helo=node.waugh.id.au by=soman.fdntech.com ident= envfrom= intl=0 	id=1C16D2695B0 auth= msa=0 ] [ ip=127.0.0.1 rdns=localhost.localdomain 	helo=node.waugh.id.au by=node.waugh.id.au ident= envfrom= intl=0 	id=05F173C854 auth= msa=0 ] [ ip=67.19.173.84 rdns=vanadium.sabren.com 	helo=vanadium.sabren.com by=node.waugh.id.au ident= envfrom= intl=0 	id=919D73C595 auth= msa=0 ] [ ip=75.182.87.110 	rdns=cpe-075-182-087-110.nc.res.rr.com helo=!192.168.1.104! 	by=vanadium.sabren.com ident= envfrom= intl=0 id=l9M0iCXW018735 auth=Sendmail 	msa=0 ] X-Spam-Relays-Trusted:  X-Spam-Level:  X-Spam-RBL:  [70.85.31.216] 	 [127.0.0.11] X-Original-To: user7@gvc.ceas-challenge.cc Delivered-To: jl@mail.fdntech.com Received: from localhost [127.0.0.1] 	by radish.jmason.org with IMAP (fetchmail-6.3.2) 	for  (single-drop); Mon, 22 Oct 2007 01:51:57 +0100 (IST) Received: from node.waugh.id.au (node.waugh.id.au [70.85.31.216]) 	by soman.fdntech.com (Postfix) with ESMTP id 1C16D2695B0 	for ; Sun, 21 Oct 2007 19:45:09 -0500 (CDT) Received: from node.waugh.id.au (localhost.localdomain [127.0.0.1]) 	by node.waugh.id.au (Postfix) with ESMTP id 05F173C854; 	Mon, 22 Oct 2007 10:44:55 +1000 (EST) X-Original-To: kpdpo@lists.planetplanet.org Delivered-To: kpdpo@lists.planetplanet.org Received: from vanadium.sabren.com (vanadium.sabren.com [67.19.173.84]) 	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) 	(No client certificate requested) 	by node.waugh.id.au (Postfix) with ESMTP id 919D73C595 	for ; 	Mon, 22 Oct 2007 10:44:53 +1000 (EST) Received: from [192.168.1.104] (cpe-075-182-087-110.nc.res.rr.com 	[75.182.87.110]) (authenticated bits=0) 	by vanadium.sabren.com (8.12.11.20060308/8.12.11) with ESMTP id 	l9M0iCXW018735; Sun, 21 Oct 2007 20:44:52 -0400 Message-ID: <471BF256.9040302@intertwingly.net> Date: Sun, 21 Oct 2007 20:44:06 -0400 From: Sam Ruby  User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: James Holderness  References:  In-Reply-To:  Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kpdpo@lists.planetplanet.org Subject: Re: Planet venus decode error X-BeenThere: kpdpo@lists.planetplanet.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Planet development discussion \\(and user support\\)" 	 List-Unsubscribe: , 	 List-Archive:  List-Post:  List-Help:  List-Subscribe: , 	 Sender: iufkn-ohamcst@lists.planetplanet.org Errors-To: iufkn-ohamcst@lists.planetplanet.org James Holderness wrote: >  > Does that mean there is an error in the feed, or is the problem  > somewhere else? According to the feed validator the feed is valid, so I  > didn't think the feed was the problem. You managed to break the Universal Feed Parser.  Congratulations.  :-) A (possibly partial) fix has been committed, but in order to exhibit  these symptoms I suspect that there are more.  Continuing to investigate... - Sam Ruby --  devel mailing list kpdpo@lists.planetplanet.org http://lists.planetplanet.org/mailman/listinfo/devel