When you say "pre-defined" record type, are you looking for something like a C struct or an Object?

perldoc perlfaq4 might have what you are looking for, under "How-can-I-make-the-Perl-equivalent-of-a-C-structure C++-class hash-or-array-of-hashes-or-arrays". Also, perldoc perldsc is the best place to go to see examples of simple compound data structures in use in Perl. perldoc perltoot, besides having a cute name, is also a good "objects in Perl" starter kit.

Is there something pre-built to do your work for you? In general, it depends on how standard your input and output are. I'm thinking for this (And I think they might be core, they come with my distro of ActivePerl, at least) that you can use one of the CSV modules set to use the pipe as the delimiter to slurp your data in.

If you are totally sure your data will not contain any pipe characters, you can feed each line to the split built-in, which can return a list of each pipe-delimited value.

Hi amarquis. Thanks for the response. I've been browsing that sinse you pointed it out. Great help!

This is sort of what I am looking for. What I would do if I was doing this inside of Oracle (PL/SQL) (which is where my background is) would be to create a record type such as:

 type example_rec is record ( 
         IP varchar2(10), 
         Username vachar2(56), 
         get_files varchar2(15));
[download]

and subsequently create a table of those records such as:

ex_table is TABLE of example_rec index by binary_integer;
[download]

Subsequently opening the text file, looping through it and filling the table with the rows in the text file.

I hope this gives you a better understanding of what I'm trying to do.

I'm certain my data won't contain any pipes, I'm the only one that will be using it. I'm trying to create multiple ftp transfers for various files that need to be moved around here. So it was either multiple scripts, or try and create one to do all using a configuration file.

Eventually, my plan is to use an Oracle external table to allow users to access it, but that's further down the road.

Parse::CSV would really fit the bill, I even demonstrated using a pipe sep over here.

But if you're stuck without using modules, you could probably rig sub up to do what you want easily. This just reads a text file of values in the form of:

some_key_param=value
[download]

my $config = read_config({ filename => 'some_config_file' });

# {{{ read_config
#

sub read_config {

    my $args = shift;

    die "No configuration file specified\n"
        unless defined $args->{filename};

    open my $conf_fh, '<', $args->{filename}
        or die "Error opening conf file...$!\n\n";

    my $conf = {};

    for (<$conf_fh>) {

        chomp;
        
        # use '=' as the separator
        if ( $_ =~ m/[=]/ ) {

            # skip these lines
            s/#.*//;
            s/^\s+//;
            s/\s+$//;
            next unless length $_;

            my ( $key, $value ) = split( /\s*=\s*/, $_, 2 );

            $config->{$key} = $value;

        }
    }

    close $conf_fh;

    return $conf;

} # }}}
[download]

my $data = `grep -i $account_name /config/data.file`;
my @parms = split /|/, $data;
[download]

unless ( -d $parms[3] ) {
#
# do some ftp stuff here.
#
}
[download]

Hi dwm.

Config::Simple looks like an ideal solution for me.

Thanks for your suggestion!

Why not just:

use constant FILE_NAME => 3;

# ...

unless ( -d $parms[FILE_NAME] ) {
#
# do some ftp stuff here.
#
}
[download]

Gives you compile-time checks and has all the advantages of the hash solution.

plobsing, your suggestion improves readability, but the code is still directly tied to the data file and its internal representation. Consider this scenario:

1. You write a piece of code tied to the data representation.

2. You leave the company.

3. It becomes very popular.

4. Dozens of people want to use it, but they want to each make lots of small changes to the data representation. Rather than rewriting the code to handle all cases, they cut and paste unique versions of the code and change the constant mapping to fit their unique cases.

And all I'll say is, I've been there, at step 5, when someone gets asked to refactor all those scripts into 1 script.

So I beg to differ: as long as your code is tied directly to data representation, it isn't as good as indirect solutions, where the representation can be modified without affecting running code.

Update: typo fix

If all you want is to assign names to columns the type could be as easy as:

my $c = 0;
our @Columns = qw(field1 field2 ...);
our %Column_numbers = map { $_ => $c++ } @Columns;
[download]

Any utility subs (like parsing the input file) can go in the same module, so they can be re-used.

As for existing CPAN modules, you should be aware that you can generally install perl modules locally (i.e. in a sub directory of your choice, so no root permissions necessary), That also usually means you can distribute them with the rest of the program tree without any issues. The most common drawback is that this won't work for XS/C based modules across architectures.

Text::CSV and Text::xSV can take some work out of your hands for this specific problem.