You should always check for success of your operations:

unlink($ful) or die "Can't delete '$ful': $!";
[download]

From the looks of the param function it looks like you are writing a CGI script, which means it probably runs under the user www or something similar, and might not have the privileges to delete the file anyway.

BTW I hope you're aware that what you do might be a security risk.

Sorry, but I don't know what the first remark means. Yes I am uploading this to my website and to test it, running it from my browser's address bar. So I type in www.mydomain.com/.../test.pl?f=sdfkjkkk which is then supposed to delete the file (the file name will not be immediately what f= as I realise this would be a major security risk, but it is at the moment until I can get this thing to work)! The reason I said it wasn't a priveleges problem is that when my uploaded script contains the filepath typed directly "../../alpha/abcde" it does delete but when I use $ful it does not - so they both have been run the same way. I am grateful for any help.

The important point is that your code should check whether the file deletion has succeeded, and that if it has failed it should print an error message.

$thef=param('f');
$ful="../../alpha/tempf/".$thef;
unlink($ful)  or die "Couldn't unlink($ful): $!";
[download]

The error message will show up in your webserver's error log. If the filename printed is what you expect it to be, and you can't work out from the error message what the actual problem is, we can help you with that. But you will have to tell us what the error message is.

• Posts may use any of the Perl Monks Approved HTML tags: a, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul.
• See Writeup Formatting Tips and other pages linked from there for more info.

I type in www.mydomain.com/.../test.pl?f=sdfkjkkk to my browser. I then pick up this filename in my script via $thef=param('f');
I tried chomping it as you suggested, but no difference and I had tried absolute paths. If you see my replies above, it clearly has to do with this picking up using param()
Thanks for the reply and any further suggestions!

First: Being able to do something from the command line doesn't prove that it isn't a file permissions issue. As someone else has already pointed out, web server's run as different users and therefore with different permissions.

And B: Print an error message if you can't delete so you get an idea of what happened.
unlink($ful) or die "Unable to delete [$ful] : $!";
I usually put variable names inside some type of enclosure, like brackets or braces so that if there is an extra newline or something, you'll see it on the screen when the error prints.

#!/usr/bin/perl

use strict;
use warnings;
my $thef = "f";
my $ful="../../../".$thef;
print "$ful\n";
unlink($ful) or die "unable to delete $ful: $!\n"
[download]

No - that works fine for me if "f" was the name of the file. The name of the file is passed to the script from the browser:www.mydomain.com/..../ dfil?f=abcde
In the script I then pick up the name of the file with
$thef=param('f');
when I print $thef everything appears the same abcde as if I had written $thef="abcde"; printing $ful gives the path exactly as it should be - it can even be recognised by -e $ful but it is not recognised by unlink($ful)
So although they appear identical strings unlink recognises it when $thef was manually set $thef="abcde" but not when set using the parameter $thef=param('f'); even though they look identical and behave identically for -e
I even tried chomp($thef);

Thanks again for any help!

Did you try printing them? Can you post more of the code itself?

also adding

  use CGI::Carp qw(fatalsToBrowser);

to the top of your program may prove useful.

update

And then in your code: die unless param('f');


Ted
--
"That which we persist in doing becomes easier, not that the task itself has become easier, but that our ability to perform it has improved."
  --Ralph Waldo Emerson

Also I can test if the file exists, using the variable, -e $fnmi and I get true.
Sorry that was a mistake
Should have been -e $ful
I believed that this was testing the existence of a file whose path is contained as a string in the variable.
As a matter of interest what is the significance of this construction:
( $fnmi =~ /^someword$/ )?
Thanks

As a matter of interest what is the significance of this construction: ( $fnmi =~ /^someword$/ )?

 ( $fnmi =~ /^someword$/ ) is a pattern match, which happens to be equivalent to  ( $fnmi eq 'someword' ).

To understand why so, start reading about regular expressions and matching in perlrequick, and read more in perlretut and perlre.

Rudif

Have a look at:

File::Temp

This module creates temporary files (using templates, temp directories, etc.) which are then unlinked/deleted when the programs exits

I haven't used it in a web setting though...

njcodewarrior

Thanks. As I said up above, the problem turned out to be the fact that I had -T switch at the top of the code and the parameter was not being validated in the script. The short-term solution was to remove the switch. Now I will put in the validation!