Re: Detecting lchown and falling back to chown

Probably could get away with just one eval (the one checking for lchown (untested):

eval( 'use POSIX qw( lchown )' );
if( defined &lchown ) {
  *best_chown = sub ($$$) { lchown( @_ ) };
} else {
  *best_chown = sub ($$$) { chown( @_ ) };
}
[download]

Update: And I don't think your prototype for chown looks right; CORE::chown is (@) . . .

The cake is a lie.
The cake is a lie.
The cake is a lie.

Comment on Re: Detecting lchown and falling back to chown Select or Download Code

Replies are listed 'Best First'.
Re^2: Detecting lchown and falling back to chown by andy314 (Initiate) on Feb 01, 2008 at 16:40 UTC
I am new enough to perl to not even know how to find the right prototype ... I guessed that it takes 3 parameters, so $$$ made sense. I guess RTFM would help .. Thank you for info. Any speed/functionality differences between your code and the eval version? Or just code cleanliness?	[reply]
Re^3: Detecting lchown and falling back to chown by Fletch (Bishop) on Feb 01, 2008 at 17:32 UTC
Primarily cleanliness (don't do more string evals than you absolutely have to); and given that you'll probably only run this chunk of code once per invocation anyway it's premature optimization to really worry whether 3 string evals is killing your performance (hint: it's probably not going to be even measurable). The cake is a lie. The cake is a lie. The cake is a lie.	[reply]