Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!jarthur!uunet!etnibsd!vsh
From: vsh@etnibsd.UUCP (Steve Harris)
Newsgroups: comp.lang.perl
Subject: Re: (repost, and possible fix):  is ( -e _ ) always true??
Message-ID: <1183@etnibsd.UUCP>
Date: 29 Oct 90 18:29:32 GMT
References: <1180@etnibsd.UUCP> <10136@jpl-devvax.JPL.NASA.GOV>
Reply-To: vsh@etnibsd.UUCP (Steve Harris)
Organization: Eaton Corp, Semiconductor Equipment Div., Beverly, MA
Lines: 120

In article <10136@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes:
>In article <1180@etnibsd.UUCP> vsh@etnibsd.UUCP (Steve Harris) writes:
>: Bug:  the -e operator (test for file existence) always returns 1 (true)
>: 	when applied to the magic argument _
>
>Okay, I'll fix it, but why anyone would test for the existence of a file after
>testing for something more particular is beyond my meager reasoning ability.
>
>But thanks for the patch.  Being a lazy critter, I appreciate it when people
>save me some time.
>
>Larry

Don't be too lazy, Larry.  Your observation, plus some email from
Raymond Chen (reproduced below), led me to re-evaluate my "fix".

As to:
>... why anyone would test for the existence of a file after
>testing for something more particular ...

My script reads a list of files read from STDIN, and then duplicates
them in a target directory tree.  Normally I would do a (-e $filename)
test first, but a symlink may point to a nonexistant file.  So I do:

while ($filename = <STDIN>) {
	chop $filename;
	if (-l $filename) { symlink(); next; }
	# Since $filename is not a symlink, lstat() and stat() return
	# the same info -- no need to do another stat system call.
	# Now do the existence test:
	next unless -e _;		# BUT -- this is a no-op!!
	if (-b _) { mknod(); next; }
	if (-c _) { mknod(); next; }
	if (-d _) { mkdir(); next; }
	# regular file, just copy it
} continue {
	# set file ownership, permissions, timestamps, etc.
}

To test the (-e _) operation, I wrote a four-line script which,
unfortunately, does not consider the -l test.  Consequently, my "fix"
only looks at the mystat() function, which calls fstat, not lstat.
Clearly the "fix" is incomplete, at best.


Raymond Chen writes (slightly out of context):

>... if a stat test fails, the "current contents of the
>stat structure" should be considered undefined ...

I think this is the "logically correct" way to address the problem.
Then any filetest operation after a failed test would return false.

	****** WARNING: INCOMING ENHANCEMENT REQUEST ******

Perhaps there could be a predefined array name, @STAT, which would hold the
contents of the last filetest or stat operation, and which would become
undefined if the stat test fails.  Initially, @STAT would be undefined.
Filetest operations on _ would be simply be applied to this array.
Then, (dramatic pause), the filetest operators could be extended to
work with any "stat array", e.g.:

	@s1 = stat("foo")
	@s2 = stat("bar")
	if (-w @s1 && -r @s2) { whatever; }

Gee, Larry, you must love us users volunteering you to make all
these enhancements ;-)

In the meantime, I think it would suffice to document the current
behavior, i.e.:

	A stat/filetest on _ is applied to the stat buffer from the
	most recent successful stat/filetest.  A side-effect of this
	behavior is that the filetest '-e _' always returns 1 (true).

and, while you're at it:

	An explicit filename (i.e., not _) must be supplied with
	the lstat() function and the -l filetest.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Raymond Chen's letter:

>From: uunet!math.berkeley.edu!raymond (Raymond Chen)
>To: vsh@etnibsd
>Subject: Re: (repost, and possible fix):  is ( -e _ ) always true??
>Newsgroups: comp.lang.perl
>In-Reply-To: <1180@etnibsd.UUCP>
>Organization: U.C. Berkeley
>
>The problem is a misunderstanding between you and the manual.
>
>The manual says
>
>	... no stat is done, but the current contents of the stat
>	structure from the last stat or filetest are returned.
>
>whereas you think it says
>
>	... no stat is done, but it behaves as if the stat were
>	actually performed with the same argument as the previous
>	call to stat.
>
>The problem is that a failed stat (e.g., -r on a nonexistent file)
>does not affect the "current contents of the stat structure", so the
>results of stat tests on "_" return, not the result of the most recent
>stat, but rather the result of the most recent *successful* stat.
>
>Consequently, if a stat test fails, the "current contents of the
>stat structure" should be considered undefined (unless you know
>a priori what its prior contents were *and* you know that the
>stat failed due to "file not found".)
>
>It is arguable whether your implementation or Larry's implementation
>should be considered the more desireable.  I side with you on this
>issue.

-- 
Steve Harris - Eaton Corp. - Beverly, MA - uunet!etnibsd!vsh