Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!jpl-devvax!lwall
From: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Newsgroups: comp.lang.perl
Subject: Re: Rudeness on -l _
Message-ID: <11714@jpl-devvax.JPL.NASA.GOV>
Date: 7 Mar 91 17:34:56 GMT
References: <124842@uunet.UU.NET>
Reply-To: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Organization: Jet Propulsion Laboratory, Pasadena, CA
Lines: 28

In article <124842@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes:
: I was just treated to what I consider a bogus error message:
: 
: 	"You must supply explicit filename with -l"
: 
: The Book says (pg 85) "Likewise, -l _ will always be false
: after a normal stat". Actually, tis fatal.
: 
: I am writing a recursive compare and remove script.
: I only want to stat each file once. I need to know
: what it is, so I was lstat'ing it, saving the results,
: and later doing -f _, -d _, -l _.
: 
: It now looks like I'll have to -l it first, then do
: -f _, -d _, etc later. I will also have to lstat(_),
: as I need other info for optimizing equality tests.

Oddly enough, I just worked on this yesterday after I ran into the same
problem.  The new behavior is to allow -l _ but not -l FILEHANDLE.
And -l _ will work correctly after lstat, but will now give a fatal error
after a stat, so that we prevent people from making that particular
stupid logical error before they've torn all their hair out.

I also made readlink non-fatal on systems that don't support it--it now
just returns undef, which is exactly what it would return on a non-link
file anyway, so why blow it out of the water?

Larry