in reply to Using Variables in Path Names

Before you get assaulted by the CGI.pm police (Update: too late! :-), here's what you should really be doing up front: 
#!/usr/local/bin/perl -wT

use strict;
use CGI;

my $q = CGI->new();

print $q->header();

# Using CGI is even easier than doing it yourself,
# so PLEASE(!) use it!
$studentid = $q->param('studentid');
$CSC = $q->param('CSC');
chomp($CSC);  
$assignment = $q->param('assignment');
$file = $q->param('file');

[download]
Now, consider constructing a path from variables, such as you are trying to do. Instead of using string interpolation, such as "$HOME/$x/$y", you should just join: 
my $path = join ('/',
                   $HOME, 'classes', $CSC,
                   $studentid, $assignment,
                   'outputfile.txt');

[download]
Of course, before you even think of doing this, you must validate your parameters to make sure they are "kosher". Using 'perl' with the '-T' parameter makes user data tainted, or icky, and your program will fail with errors unless you check them out first. 
# An example of "validated" input
my ($studentid) = $q->param('studentid') =~ /(\w+)/;

[download]
You should define your input specification as narrow as possible. For example, if you just wanted numbers, you can use '\d+'. If none of this makes any sense, a quick browse through the regular expressions reference will help immensely. This is time well spent.

You should note that CGI.pm helped you by:

Replies are listed 'Best First'.
Re: Re: Using Variables in Path Names
by dvergin (Monsignor) on Nov 28, 2001 at 03:51 UTC
    Hi, tadman. You say, "Instead of using string interpolation, such as "$HOME/$x/$y", you should just join".

    Next to doing dumb things, I hate doing wise things without knowing why.** And in this case I can't think of a reason why join would be better for this.

    What is the reason for your assertion?

    ---------------------
    **I've heard this called "Cargo Cult Correctness", i.e. (blindly) doing the right thing but not knowing the reason. ;-)

[reply]
      I think tadman ment 2 things. First of all, with the join method you only have a hard-coded separator in one place. If you want another, just replace that one, or better, define a variable for that.

      Two, you'd better assign variables, or arrays, to define the subdirectories node for node. That way, the code gets more readible (less comments needed) and better maintainable.

      Jeroen

[reply]
        This is actually an interesting discussion. Let's take a look at the code for this: 
        # Having defined $HOME, $first, $second up above somewhere...
# Using interpolation
my $dir = "$HOME/$first/$second";

# vs. Using join
my $dir = join '/', ($HOME, $first, $second);

        [download]
        Personally, I find the first to be more expressive. It tells me, the reader, that you're talking about a directory structure because that's how I'm used to seeing it.

        join, to me, talks about creating generic strings, usually for some cryptic file using comma-delimitation or as a way of printing out an array in a readable form.

        Now, this is all personal style. I guess I'm just used to seeing it that way.

        As for speed ... I haven't done the Benchmarking, but I think that interpolation might actually even be faster.

        As for usability, I will agree that it's easier to manipulate a list vs. manipulating a string, but that usually doesn't really matter. Most of the time, you're manipulating said string in a recursive fashion. So, you're just adding vs. adding & subtracting (which you'd have to do if you converted the recursion to a loop).

        ------
        We are the carpenters and bricklayers of the Information Age.

        Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

[reply]
[d/l]
Re: Re: Using Variables in Path Names
by andye (Curate) on Nov 28, 2001 at 15:46 UTC
    tainted, or icky

    heh. amused. You realise I'll now be forced to think of tainted data as 'icky'. ;)

    andy.

[reply]

In Section Seekers of Perl Wisdom