Strange behaviour with unlink

[Bill H]

I dont have the original code with me (its on a pc I have shut down
for the night) but a few days ago I came upon a strange behaviour with
unlink.

The routine basically did the following (I will post real code
tomorrow):

$somevar = &getsomevalue();

sub getsomevalue
{
my $results = "";
my @scratch = ();
open(FILE,"somefile");
@scratch = <FILE>;
close(FILE);
$results = $scratch[0];
# unlink("somefile");
return($results);
}

The above works fine as expected and gets me the value I want in
$somevar. But if I uncomment the unlink, $somevar is always blank! And
yes, the file does exist before I open it (real code checks that).

Can the the value being returned somehow still be linked to that file?
I thought maybe cause I was in the subroutine and put the unlink after
the "$somevar = &getsomevalue()" outside of the subroutine and it
still made $somevar blank???

Bill H

 

[Ben Morrow]

I dont have the original code with me (its on a pc I have shut down
for the night) but a few days ago I came upon a strange behaviour with
unlink.

The routine basically did the following (I will post real code
tomorrow):

$somevar = &getsomevalue();

Don't call subs with & unless you know what it does.

sub getsomevalue
{
my $results = "";
my @scratch = ();

You don't need to initialize variables like this. Perl isn't C:
variables get perfectly well-defined[0] initial values on their own.

[0] 'defined' in the C sense, not the Perl sense, of course...

open(FILE,"somefile");

The usual... (you may know all this already, but it's good to get into
the habit. Even in example code.)

Use lexical filehandles.

Check the return value of open.

Use three-arg open: I know it can't make a difference when the
filename is a string literal like this, but in a minute you'll
change it to a variable, and then you'll end up with that variable
containing '|rm -rf /'...

@scratch = <FILE>;

Don't declare variables before you need to. In this case, you can
declare @scratch right here:

close(FILE);
$results = $scratch[0];

Err... you're reading the whole file, just to trow most of it away and
only keep the first line? What's wrong with

my $results = <$FILE>;

?

# unlink("somefile");
return($results);
}

The above works fine as expected and gets me the value I want in
$somevar. But if I uncomment the unlink, $somevar is always blank! And
yes, the file does exist before I open it (real code checks that).

I don't believe you . Post some real code that exhibits this
behaviour, and include details about your OS, the file you were
reading, &c.

Can the the value being returned somehow still be linked to that file?

Nope. (Well, not unless you'd used Tie::File, or something similar...)

I thought maybe cause I was in the subroutine and put the unlink after
the "$somevar = &getsomevalue()" outside of the subroutine and it
still made $somevar blank???

I suspect your code didn't say what you thought it did, and you weren't
returning from the sub where you thought. Check it again, and post some
real code if you still can't figure it out.

Ben

 

[sisyphus]

.
.

Can the the value being returned somehow still be linked to that file?

No ... at least not with the code you posted.
Wrt the code you supplied, if the file is either empty or non-
existent, $somevar would be blank (and undef).
Otherwise $somevar would have to contain something.

Cheers,
Rob

 

[Bill H]

I dont have the original code with me (its on a pc I have shut down
for the night) but a few days ago I came upon a strange behaviour with
unlink.

The routine basically did the following (I will post real code
tomorrow):

$somevar = &getsomevalue();

Don't call subs with & unless you know what it does.

sub getsomevalue
{
my $results = "";
my @scratch = ();

You don't need to initialize variables like this. Perl isn't C:
variables get perfectly well-defined[0] initial values on their own.

[0] 'defined' in the C sense, not the Perl sense, of course...

open(FILE,"somefile");

The usual... (you may know all this already, but it's good to get into
the habit. Even in example code.)

    Use lexical filehandles.

    Check the return value of open.

    Use three-arg open: I know it can't make a difference when the
    filename is a string literal like this, but in a minute you'll
    change it to a variable, and then you'll end up with that variable
    containing '|rm -rf /'...

@scratch = <FILE>;

Don't declare variables before you need to. In this case, you can
declare @scratch right here:

close(FILE);
$results = $scratch[0];

Err... you're reading the whole file, just to trow most of it away and
only keep the first line? What's wrong with

    my $results = <$FILE>;

?

# unlink("somefile");
return($results);
}

The above works fine as expected and gets me the value I want in
$somevar. But if I uncomment the unlink, $somevar is always blank! And
yes, the file does exist before I open it (real code checks that).

I don't believe you . Post some real code that exhibits this
behaviour, and include details about your OS, the file you were
reading, &c.

Can the the value being returned somehow still be linked to that file?

Nope. (Well, not unless you'd used Tie::File, or something similar...)

I thought maybe cause I was in the subroutine and put the unlink after
the "$somevar = &getsomevalue()" outside of the subroutine and it
still made $somevar blank???

I suspect your code didn't say what you thought it did, and you weren't
returning from the sub where you thought. Check it again, and post some
real code if you still can't figure it out.

Ben

--
For far more marvellous is the truth than any artists of the past imagined!
Why do the poets of the present not speak of it? What men are poets who can
speak of Jupiter if he were like a man, but if he is an immense spinning
sphere of methane and ammonia must be silent? [Feynmann]     (e-mail address removed)

Ben

I have to assume you are right. I just took the code, cut out the
relevant parts and made a small program to duplicate it and it works
as expected, unlink doesn't change the value. I'm not sure why it was
doing it before, but I was able to make it do it on command back then
(a few days ago) by just removing the # in front of the unlink (and
unfortunately I deleted that line and said screw it, I'll just remove
these old maintenance files in a cron job).

Bill H